Jangan Pake UUID di Database? | PZN Reaction

Jangan Pake UUID di Database? | PZN Reaction
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
TH-cam : / programmerzamannow

[@mukhlimkurowo]

memang uuid lebih boros tp jg solusi praktis kalo id harus digenerate di sisi client, misal untuk offline-first web app atau distributed system yg tidak mengharuskan full online

[@baskarapatria3961]

Akhirnya ada yg bahas ini juga, kuncinya di:
- Pilih algoritma index yg cocok dengan pola query yg akan dipakai (umumnya B-tree vs Hash vs Full text)
- Kalau ga butuh urutan + B-tree, UUID v4 seharusnya ga masalah tapi mending by default selalu UUID v7 aja
- Opsi lainnya di self-defined smart ID, jadinya ID nggak bener2 meaningless dan bisa nyimpan beberapa informasi tanpa perlu lookup ke DB

[@tryoasnafi4340]

UUID secara underlying itu integer panjangnya 128 bit, yang ditampilkan itu 32 hex char nya.
Jadi udah sangat optimize UUID di database, syaratnya jangan simpan sebagai varchar tapi bener-bener tipe khusus UUID

[@putridefa2819]

jika di mysql versi 5 itu gimana tidak ada tipe data uuid? apa harus pakai auto increment?

[@tryoasnafi4340]

@@putridefa2819 saya di production jarang pakai MySQL, tapi menurut docs resmi mysql disarankan pakai BINARY(16), select pakai BIN_TO_UUID(), insert pakai UUID_TO_BIN()

[@MrKeliv]

Saya tetap menggunakan ID int sbg primary key, sedangkan UUID itu hanya sbg attribute. Jadi ga kena indexing yang membuat performance turun.
UUID saya gunakan hanya mengkamuflase URL contoh /data/uuid-abc-eqwewqe
Jadi id aslinya terlindungi dari user yang ingin coba2.
Positipnya saat develop, querynya lebih cepat menggunakan ID daripada UUID

[@dewigesrek5651]

kenapa ga main encrypt decrypt aja a?

[@b0ysb3]

Saya baru mau adaptasi menggunakan cara mu juga @MrKeliv, minus nya yang kerasa apa ya bro selain memakan extra disk space karena ada 2 kolom?

[@uyosuryo629]

kamuflase url ya mending pake kolom url_token generate string bisa 36 space 0-Z

[@LatenightDev]

@@uyosuryo629 akan jadi masalah kalo ada keperluan share link ke user lain

[@LatenightDev]

bener primary key memang seharusnya jangan pernah diekspose demi keamanan data, jadi keberadaan primary key ini lebih untuk keperluan relasi antar table

[@juvan.nayoan]

untuk laravel ^9.0 alternatif nya bisa dipakai ULID karena algoritma generate nya hampir sama dengan UUIDv7, dan bisa juga untuk di transform dari ULID (laravel) ke UUIDv7 (database)

[@LatenightDev]

Bener bang, kalo alasannya memberatkan database toh kolom kolom lain seperti username, email juga ga berurutan dan harus sering dilakukan balancing. Jadi kalo alasanya bikin berat database karena boros gak relevant. Saya pake UUID untuk menyembunyikan primary key bukan sebagai index. Karena idealnya primary key tidak untuk diekspose.
Untuk aplikasi offline, UUID sangat membantu ketika harus menggabungkan beberapa data dari device offline yang berbeda tanpa harus khawatir akan terjadi konflik dan saling klaim ID.

[@slingingslasher7427]

Waktu pertama belajar laravel , saya make kolom id dengan tipe data int sebagai primary key , namun data yang disebar ke luar itu menggunakan semacam slug,
Misalnya saya punya tabel animals
Kolomnya
1. Id int sebagai primary key
2. Slug text
3. Name varchar(255)
Nah misal saya punya halaman yang menampilkan informasi animals tertentu di halaman /animals/id akan diganti menjadi /animals/slug.

[@lobataros]

IMHO, slug tuh bagus buat SEO, untuk data-data seperti contoh artikel yang membutuhkan indexing di search engine. Tapi, kalau untuk case ini table animals atau table master lain seperti user, dll. ini kurang cocok untuk pakai slug. Efeknya juga karena ini random, seperti yang mas eko jelasin, storage juga lebih boros karena penggunaannya kurang cocok.
CMIIW

[@bellawankusuma]

@@lobataros kayanya beda konteks deh, kalo di artikel casenya kolom sebagai primary key untuk index data di database. kalo slug biasanya cuma unique key. concern nya untuk store data pake UUIDv4 dibanding auto increment integer performance lebih lambat, dan kapasitas storage makan lebih banyak. perkara pake slug untuk url nya tetep bisa pakai query

[@friedec3622]

Artikel nya hanya membicarakan kerugian UUID, gk bahas keuntungan UUID.
Point 2 sebenernya bukan kerugian, tapi trade-off.
Integer hanya support insert 2 triliun baris data, lebih dari itu bakal error.
UUID itu base16 (0-9, A-F), slotnya lebih banyak 60% daripada integer base10 (0-9) di size yang sama, kalo kamu somehow pengen 32-bit UUID.
Yang kedua, auto increment itu rawan mining data.
Item apa setelah id=10? Ya, id=11, dan selanjutnya pasti id=12.
Kalo pake UUID, satu data ketebak id-nya belum tentu data selanjutnya kena.

[@fahrigunadi]

Kalau di laravel ada key bawaan alternatif dari uuid yaitu ulid, dan ulid mirip uuidv7 dapat di urutkan

[@lyrihkaesa]

Baru tahu ada ulid, kukira uuid saja di laravel. Itu include semenjak laravel berapa?
Edited: setelah saya cek ada di laravel 9. Didalamnya inlcude package symfony/uid.

[@masipul99]

Bknnya ulid itu sebutan klo ada org yg suka asal komenin kehidupan org lain ya?

[@fikronmaulana6723]

Itu sih julid, bisa aja lu bg wk​@@masipul99

[@andreyanugrahputra3222]

@@masipul99 julid itu bang hehehe

[@Rhidayah]

@@masipul99asik lu banh,,,
Asik sndiri

[@HendroID7]

Problem dari tidak menerapkan UUID ini banyak aplikasi yg saya temui tidak secure, contoh nya rentan dari serangan IDOR, ditambah tidak ada validasi saat pengguna mengakses data tsb

[@prochild4844]

10:44 saya tunggu videonya pak eko

[@haiffy]

Aku pake uuid cuma untuk field yang strukturnya array of objects, jadi cuma dipake untuk accessor key, juga dipake untuk generate id di sisi client jika ada form yg dynamic

[@muhammadbudiawan7889]

saya pake uuid buat primkey di tabel sensitif kayak user, item dan transaction misalnya. selain itu masih okelah pake auto increament.

[@bambanggunawanid163]

Saya udh berhenti pakai UUID v4 pak. Skrng sudah ada UUID v7 dimana id nya urut. Kalau di sort juga sesuai data keluar masuk. Udh tidak se random v4. Khusus postgres setau saya udh di optimal karena sortable

[@bambanggunawanid163]

Malesnya pake auto increment raw adalah inconsistency length id pak. Kadang kita perlu convert id ke string. Kadang frondend lbih nyaman lempar uuid ktimbang id

[@happyday2912]

@@bambanggunawanid163 bener bgt

[@avgjoe3869]

​@@bambanggunawanid163 kadang FE lebih nyaman lempar uuid ketimbang int id. Maksudnya gimana pak?

[@bambanggunawanid163]

@@avgjoe3869 biasanya frontend ada validasi id json. Banyak yg pake zod type gitu. Klo pake id bisa di pasang uuid pasti 48 karakter misal. Dan string gitu. Instead auto inc pke number

[@yogapratama90s]

Untuk urusan ID saya pakai TSID, kalau yg pakai java pasti udah familiar. Kalau yg pakai PHP bisa cobain odan TSID 👍

[@ButaNgamuk]

Kuncinya adalah apakah sistem yang akan dibangun itu distributed atau nggak? kalo nggak distributed, regardles database nya pake apa, jangan pake UUID. Opsi lain bisa pake ULID.

[@xsanjidev]

baru aja kemarin baca itu eh udah di bahas disini, mantap panutan

[@ttaqinmu707]

pakai sequential uuid, store di db sebagai tipe uuid, jgn char / text

[@kodeka-team]

pernah baca soal problem UUID ini. kalo backend dipegang sama beberapa pihak misalnya, memungkinkan UUID akan ada kesamaan dengan yang di local-server yang ada di kita. solusi simplenya, jangan store mentah" UUID yang kita kirim ke db (perlu adanya validasi). solusi selebihnya bisa pake cara kita sendiri yang lain

[@ProgrammerZamanNow]

kalo uuid versi 4 harusnya dijamin unique walaupun di generate sama beda2 komputer dan waktu yang sama

[@BramandaSuwandi]

13:38 Mantap pak eko. baru sadar selama ini pake BTree karena bawaan ketika save dan baru tau ada Hash. hehehe

[@raincodemyid]

Pantesan waktu saya buat aplkasi pakai MERN itu nilai balikan cepet banget keluar. Saya pakai logic yg sama dengan Laravel dan MySQL UUIDv4 itu agak jauh time response nya.

[@lemarikaca4805]

terimakasih pak eko, mantap pembahasan nya

[@bimarizqyramadhan126]

loh cons nya ga disebut kah? kayak auto-increment lebih predicted sedangkan uuid lebih secure

[@masadamsahid]

kalau kebutuhannya aman dan performa bagus, bukannya bisa dengan pakai auto increment terus bikin logic backend-nya yg secure aja gitu ya?
Emang beresiko banget kah kalau kita pakai auto increment? Soalnya kalau aku liat Stackoverflow itu mereka pakai ID usernya juga angka dan kayaknya auto-increment juga.

[@adawam4891]

aku biasa backend nya di hash / encript dengan key sendiri

[@rizkyanfasafarrasmada7225]

@@masadamsahid nah bener tinggal pasang logic di BE nya

[@iheckinloveurmom]

@@adawam4891 ya tapi kan yg kegenerate tetap random dan ga ngurut kan? kalo iya, berarti masih masuk cons yg disebut

[@tstech5202]

Gua kurang setuju si, kalo mau aman mah tinggal maenin logic,seperti Komen diatas,biasa pas lakuin pentest Gini kita nyiapin 2 akun juga,meskipun make uuid yang ga keprediksi ya tetep itungannya vulnerability

[@didi_abdillah]

Kalaus saya pakai UUID untuk data yang sensitif banget seperti data user apalagi kalau primary keynya sering muncul di URL parameter, sisanya untuk data-data yang gak terlalu critical apalagi cuma jadi dependency doang pakenya auto increment.

[@deantevin2350]

kalo pake URL param bagusnya di encrypt juga pas ngirim IDnya biar ga kena Indirect Object Reference.

[@muhammadrizalrizkynaufal4559]

contoh encrptnya pake algo apa ya mas contohnya? dan bukannya nantinya dari sisi be harus decrypt yg akan mempengaruhi performance juga? dan kalo udh uuid seharusnya kan juga sudah susah ditebak karena characternya sangat random?

[@friedec3622]

@@muhammadrizalrizkynaufal4559 UUID itu meskipun random tapi bisa kena langsung ke data reference.
Kalo mau di encrypt, table refresh_token tambah field 'url key' berupa symmetric encryption yang nanti dikasih ke client ketika mereka minta token, jadinya tiap JWT session key nya beda2.
Kalo mau lebih ribet lagi, pake double asymmetric key encryption.
1 set key untuk arah request (client -> server), 1 set key untuk arah responses (server -> client)

[@dzalhaqi]

Pak eko, bahas2 tentang ml engineering dong pak dalam pengembangan software yg udh di production

[@winartoit]

kl pake integer, bisa ditebak2 dunk ID nya, tinggal diganti2 aja angka ny di url

[@RizkySamPratama]

pernah case untuk bikin cron sync data ternyata primarynya pake UUID nah perlu disorting dulu, ternyata bisa di sorting, entah itu uuidv4 atau v7.
nanti saya coba pakai uuidv7 kalau ada case pake uuid lagi

[@ProgrammerZamanNow]

kalo si sorting, pasti bisa, tapi maksudnya datanya unpredictable kalo uuidv4, bisa lebih besar, terus lebih kecil, jadi gak berurut kalo generate2 data

[@RizkySamPratama]

@@ProgrammerZamanNow oohh i see.. makasih kang

[@zain-adam]

judul artikel click bait. conclusion-nya tidak selaras dengan judul 😁 thanks for sharing pak eko.

[@Nopalxha]

ULID dong bang

[@ardhikaryzha317]

seminggu kemarin baru baca article ini wkwkw

[@mastikaketut9923]

gimana dgn penggunaan CUID bang?

[@agunbuhori]

Pak eko, tolong bahas pake ULID Laravel dong

[@yanpay]

Sekarang diproject saya pakai nanoid, bahas juga nanoid pak .

[@ProgrammerZamanNow]

menarik

[@abazure69]

sudah waktunya id pake decimal/float

[@ProgrammerZamanNow]

Gak juga, masih ada opsi uuid yang berurut

[@misakamikoto8312]

⁠kalau uuid dibuat berurutan mjd sequence, apa bedanya sama tipe data int atau big int?

[@abazure69]

@@misakamikoto8312 uuid masih gak terprediksi karena generate string random..

[@scaffold.s]

Tetap susah ditebak sih klo mau ngakal"in, ga kek delete/1​@@misakamikoto8312

[@iheckinloveurmom]

@@misakamikoto8312 jadi point yang di bahas kan masalah peforma. Semakin banyak data di db, lalu saat ada proses insertion, itu jadi degradasi peforma karena algoritma yang digunakan b+ tree, karna ya emang dasarnya algoritma tersebut ga di desain untuk randomness kayak UUID v4. Kalo UUID v7 kan udh udh ngurut, walaupun dia generate key unique (random), tetapi ngurut (contoh sederhana: aa, ab, ac) begindang brodi

[@reeechart]

Tapi kalo pake auto-increment performancenya lebih lambat gak ya dari sisi RDBMS? Karena DBMSnya harus make sure supaya ngga race condition gak sih? (mutex di variable sequencenya in case ada banyak connection ke DB yang melakukan operasi insert) Just wondering :/

[@ProgrammerZamanNow]

kalo masih single master harusnya sama aja, tapi yang distributed db, kayaknya mereka gak punya fitur auto increment

[@azizyogo9084]

Buat algo indexing emang bisa milih ya?

[@hooyah]

kalo kaya pembahasan ini, inituh namanya pembelajaran apasih? aku pgn cari tau di google best practice lainya pake metode2 selain btree dan cara jalan metode2 tersebut

[@ProgrammerZamanNow]

itu struktur data

[@nurfirdaus328]

Pake time unix nano aja

[@farham_harvianto]

saya sering pake UUID tpi gk di jadikan primary key, cuma kalo pengen nyari data ke uuid

[@ProgrammerZamanNow]

selama nyari pake operator equals, gak masalah harusnya

[@misakamikoto8312]

@@ProgrammerZamanNowklo ga dijadikan primary key atau tdk di index, bukannya akan scanning ke db nya perlu waktu khususnya yg sdh besar database nya?

[@yogasetiawan5881]

nah iya, jadi si database bakal nyari line by line
jadi solusi nya gimana ya?

[@LatenightDev]

justru kalo ga jadi primarykey malah lebih lama querynya. Fungsi primarykey kan buat searching.

[@DizitoRogue]

Setuju, ngapain uuid pakai btree kan ada hash

[@MFSidqi-fy7cj]

pak eko kapan update materi kelas android

[@ProgrammerZamanNow]

doakan biar cepet selesai materinya

[@MFSidqi-fy7cj]

@@ProgrammerZamanNow aamiin pak😍

[@maiing1144]

a' kalo pake ulid gimana ?

[@isengiseng7669]

bagaimana dengan ULID?

[@JomilaHosan]

Walker Jennifer Thomas Mary Miller Eric

[@hexranox]

gmn kalo pake Snowflake ID pak eko? soalnya snowflake id ini bentuknya integer

[@ProgrammerZamanNow]

bisa banget

[@adypanegara]

Salah memang karena menjadikan uuid sebagai key

[@glowiever]

pake bigint masih cukup :p, klo utk unique unpredictability pake slug

[@gunadAgp]

Programen india sering gunakan UUID

[@andiksetyawan6608]

uuid v7 solusinya hehe

[@yahyaadinugraha1058]

Kalo ga pake id tapi gabungan beberapa kolom yang dijadiin primary key? Boleh gak pak?

[@ProgrammerZamanNow]

tetep id kan, cuma composite id jadinya

[@tieduprightnowprcls]

kalau kasusnya di data lake kayak S3 (parquet, dll) pake UUID masih aman berarti ya, soalnya ga ada kendala insert performance.

[@ProgrammerZamanNow]

harusnya itu cuma append aja kalo ke S3

[@devijv1441]

Gue pke id biasa sama uuid di route key fine2 aja
Soal nya pas pake uuid hanya di route key aja
Kalo relasi ttp pake id auto increment

[@thaitea5399]

kalo di route pake auto increment id gak aman ya? harus di acak id nya agar aman kalo pake di route soalnya keliatan di url. begitu kah?

[@devijv1441]

@@thaitea5399 iya supaya ga ketebak aja sih

[@cloudstrife335]

gw banget

[@normadanirisdiandita1937]

klo UUID ganti jadi hash aja deh

[@agungmandala5864]

Bagaimana kalau CUID bang?

[@rioanugrah6721]

Selain menggunakan UUID, ada cara lain untuk mengamankan biar tidak diketahui oleh org lain?

[@dewigesrek5651]

encrypt id

[@SalmanAlfarisi-iy4jt]

@@dewigesrek5651 pake hashids harusnya juga bisa

[@muhammadhaniffahyuananto2815]

hampir salah bacang kang
jangan pake database

[@akhmadsubkhi5100]

Kereen donk.. wkwk

[@first_namelast_name3760]

uuid 45

[@mariogunawan5844]

Artikelnya kurang nyampein alternatifnya, jadi bingung maksud authornya apa wkwk

[@ProgrammerZamanNow]

mungkin emang pengen mencari keributan aja #eh

[@cloudstrife335]

itu dia.

[@mankben]

Saya pake uuid supaya id data berikutnya ga mudah ditebak sama user.

[@ProgrammerZamanNow]

emang kalo bisa ditebak kenapa? yang penting gak bisa diakses kan

[@djamaatul]

@@ProgrammerZamanNow jadi meski pake autoincrement yang sequence yang mudah di tebak, yang penting harus di protect ya pak, jadi aman dan performa index oke

[@mankben]

@@ProgrammerZamanNow iya sih. Hehe

[@Kevin-yj7sc]

kalo untuk aplikasi yang public itu emang harus concern ke penyajian dan security data yang dapat diakses tanpa auth. Gw pernah ngedump situs jual beli konten digital gitu, dimana file hosting yg mereka buat is just plain public endpoint with incremental id wkwk

[@kucingoyen1]

​@@ProgrammerZamanNowbetter safe than sorry, apalagi untuk sektor keuangan

[@Arsobar]

UUID bukanlah sebuah database, tetapi sebuah jenis pengidentifikasi unik yang sering digunakan di dalam database dan sistem lainnya. Mari kita perjelas perannya dalam konteks database dan data secara umum.

[@aryaadinulfadlan8998]

siapa yg bilang uuid sebuah database?

[@yofiyonadio]

wkwk mak gw pun tau kalo uuid bukan database lol

[@aryaadinulfadlan8998]

@@yofiyonadio laahh mak lo kenapa jadi ngurusin uuid ?

[@hariardi]

kalo untuk replikasi berarti perlu di akalin ya mas? pernah kejadian pake autoincrement di replikasi master to master dan akhirnya kena race condition, apa strategi replikasinya yang salah ya mas?

[@ProgrammerZamanNow]

biasanya sih replica cuma nerima data dari master, agak aneh kalo replica nya malah bikin auto increment sendiri

[@hariardi]

@@ProgrammerZamanNow iya mas, jadi ada data yang di input dari beberapa region (karena ada policy yang mengharuskan servernya di region tertentu), karena autoincrementnya sering bentrok jadi diubah ke uuid tambah serverid biar masing2 ada indicator lokasi insert datanya

[@mokalovesoulmate]

uuidv7: what

[@VictorMongi]

kalau cuid?

[@poporochannel3058]

Kalo ga pk uuid jait datanya bakal sulit

[@vnoygotriz4877]

maksudnya jait apa ka? join table maksudnya ka?

[@riandas8723]

​@@vnoygotriz4877merger

[@MikoMeysaBima]

:v

[@jefrandamodjo5129]

nonton doang like kagak

[@ProgrammerZamanNow]

gak subscribe juga? parah

[@sinda4012]

@@ProgrammerZamanNow wkwkwk

[@cloudstrife335]

udah gw like itu.

[@boysitorus2386]

Numpang nanya dong, terus kalau semisal kita nih sudah ngedevelop sebuah aplikasi dengan menggunakan UUID pada databasenya, dan semisal app nya sudah terlanjur ramai dan butuh scaling lagi, bisakah data data yang ada pada database tersebut kita migrasi ke database yang support auto increment, atau tidak bisa?

[@dewigesrek5651]

bisa

[@muhammadwafa7786]

aku sering pakainya cuid, secara jumlah karakter lebih singkat.