Primary Key Dilemma (Numeric or Character)

[tesla]

so........

it's better to choose numeric

and better more to autonumber

semua depend on condition

[hatRed]

so........

it's better to choose numeric

and better more to autonumber

semua depend on condition

kondisi seperti apa saja yang menjadikan kedua hal demikian tidak lebih baik?

[tesla]

so........

it's better to choose numeric

and better more to autonumber

semua depend on condition

kondisi seperti apa saja yang menjadikan kedua hal demikian tidak lebih baik?

ada kalanya value primary key diserahkan langsung ke user, disini saya pakai char atau varchar

pada kode transaksi misalnya, saya sering pakai (var)char walaupun key tsb digenerate oleh programming logic dg parameter seperti taun bulan tanggal.

[hatRed]

bukankah tadi masalah tersebut diatasi dengan unique field

jadi

prim key   uniq key    otherfield

 int               yyyymmdd##0        field


jadi user sebenarnya input uniq key. tetapi tetap prim keynya numeric.

gmana

[tesla]

bukankah tadi masalah tersebut diatasi dengan unique field

jadi

prim key   uniq key    otherfield

int               yyyymmdd##0        field


jadi user sebenarnya input uniq key. tetapi tetap prim keynya numeric.

gmana

itu dia...  kalau saya, lihat masalah di kenyataan lapangan dulu

1. kalau valuenya tetap (tidak akan berubah di kemudian hari)
saya pakai format: PK = userId

2. tapi kalau ada kemungkinan mengubah valuenya, saya menggeser value tsb ke unique column & menambahkan PK dg type unsigned int auto increment
format: PK = auto inc, unique col = userId

seperti yg bro hatred jelaskan kelebihan & kekurangan sebelumnya...
bahwa solusi ke2 itu membebankan 'memory size'
jadi saya pakai pada saat dibutuhkan saja.

mengenai kecepatan pencarian, saya agak ragu...
soalnya kriteria pencarian sering tidak berdasarkan primary key.
bisa berdasarkan kolom lain yg bahkan tidak unique sekalipun.
demikian jg utk nested join...
nested join tidak selalu menggunakan hubungan antar PK & FK,
dalam kejadian nyata yg complex malah sering dipakai kolom lainnya...

tambah lagi, berhubung ada fasilitas indexing dari database yg sebenarnya mungkin kerjanya mirip dg mentranslasi format #1 ke format #2 tanpa perlu dipusingkan oleh programmer...
& indexing mereka itu idealnya sudah terurut berdasarkan value di PK, jadi perbedaan pencarian,
saya rasa tidak signifikan jg... (walau perbedaan space memory jg tidak terlalu signifikan jg)