Primary Key Dilemma (Numeric or Character)

[hatRed]

Pilih mana ya?

[Forte]

Tergantung style programming seh.. kalau style gw Saya cenderung pilih char.. karena saya lebih suka 00001 daripada 1

[tesla]

tergantung kebutuhan...

utk primary key yg dihandle oleh end-user, baiknya pakai (var)char...
namun perlu pertimbangan bahwa end-user sering sekali "ingin" mengubah primary keynya,
oleh karena itu, utk mencegah update yg berentetan ke-mana2, ada baiknya
buat primary key hidden dari end-user dalam type mis integer, dan utk end-user hanya diberi unique column...

mis: kalau user id di forum dc ini adalah pk, tentu yg ubah2 id dah bikin beban update lumayan...
untungnya pk nya pakai int yah

[hatRed]

nah itu dia

penggunaan char, memudahkan dalam format dan masking

penggunaan numeric, memudahkan dalam pencarian

keduanya bertolak belakang, ada kerugian dan keuntungan,

kalo pake numeric (mis sql server)

bigint = 8 bytes
int = 4 bytes
small = 2 bytes
tiny = 1 byte

charachter = n char * 1 bytes

kalo pake metode tesla kerugiannya adalah space penyimpanan yg bertambah,

kalo pake metode forte kerugiaanya adalah pencarian yg agak lama, apalagi kalo pake query yg nested join.

keuntungan metode forte, formatting lebih mudah dan kombinasi kunci yg lebih besar

keuntungan metode tesla, dalam nested join kecepatannya tentu lebih cepat.

[Forte]

Yup.. agree.. bro hatred udah mengerti..

Jadi solusinya.. udah tau kelemahan dan kelebihan masing2 style..
Tinggal lihat kondisi lapangan saja..
Kondisi lapangan kenapa gw menggunakan char.. kebetulan spec komputer client waktu itu juga gw minta standar tinggi dan disetujui..

Jadi sebagai developer waktu itu.. gw berasumsi tidak akan masalah kalau menggunakan primary key karena gw membutuhkan kombinasi kunci yang benar2 unique (biasa combine datetime dan fungsi random dari VFP)

[hatRed]

begini om

kalo i juga sama saat ini, pake key yyyymmdd##0 misalnya tuk transaksi, namun kalo pake metode tesla katanya bakal lebih cepat dalam join. walau harus dikorbankan space yg digunakan tuk key yg baru misal angka 1,2,3,....,n

jadi untuk itu perlu dua informasi yg disimpan, yaitu prim key numeric dan unique field yyyymmdd##0
nah kalo menimbang2 besaran keuntungan dan kerugian, sepertinya pemakaian numeric yg lebih unggul.

saya pake kata "sepertinya" soalnya masih belum yakin neh.

dimanakah letak kerugian dari pemakaian prim key numeric?

kalo dari space, sepertiya gak terlalu terasa mengingat harga space sekarang murah banget.

tetapi menurut teori i sih kalo ada prim key dan unique key yg dipakai dalam tabel tertentu, maka dalam proses insert misalnya akan 2 kali kerja karena engine akan 2 kali cek keberadaan value field tersebut.

sedangkan pengecekan distinction pada char string tentu saja lebih lama dibanding numeric. (menurut i penyimpanan char string seperti array bytes, jadi pada saat pembandingan akan membandingkan satu persatu byte tergantung banyaknya character, hal ini yg membuat lebih lama dibanding numeric yg hanya satu kali pembandingan)

[Forte]

Gw kurang tahu ya..

Cuma yang gw khawatirkan anggap kita berdua user.. mengakses database dan file yang sama, lagi input faktur yang berbeda, namun ada gak kemungkinan nge-klik "SAVE" untuk simpan faktur pada waktu yang tepat sama.. tentu nantinya akan menghasilkan nomer primary key yang sama ? padahal transaksinya berbeda.. takutnya konflik primary..

Gimana tanggapan bro hatred?

[hatRed]

dengan manual numbering format.

biasanya sih i pake double transaction,

satu di stored procedure (fungsinya buat insert)

dan satu lagi di program (client mode)
strukturnya kek gini

dlm program

Begin trans
     newKey = getNewKey (<== getNewKey memanggil stored procedure di Server buat cari newKey)
     
     succes = insert (newkey,...,field) (<== insert ini juga manggil stored proc)
     
     if succes then
              goto commit
     else
              goto roolback

     endif

Commit
......
roolback
...........



at Server

insertProc

Begin Trans
   insert.........
Commit

RollBack

[tesla]

keuntungan metode tesla, dalam nested join kecepatannya tentu lebih cepat.

sebenarnya saya tidak yakin bisa (signifikan) lebih cepat 

yg jadi bahan pertimbangan adalah apakah kolom tsb "mungkin" dikemudian hari diubah oleh user.
akan menjadi "nightmare" bagi programmer jika tiba2 user meminta kita utk membuat fasilitas pengubahan primary key padahal primary key itu adalah foreign key bagi puluhan atau ratusan table lainnya.
contoh kasus yg umum adalah: perubahan kode barang (atau kode data master lainnya)... jika kode barang adalah primary key yg sudah menjadi reference bagi byk table lainnya, akan menjadi pekerjaan sulit (bukan tak mungkin) utk programmer.

utk table transaksi, pada saya melihat sangat kecil kemungkinan utk dirubah dikemudian hari shg saya jg biasa pakai kode transaksi langsung sebagai primary key...

[tesla]

Gw kurang tahu ya..

Cuma yang gw khawatirkan anggap kita berdua user.. mengakses database dan file yang sama, lagi input faktur yang berbeda, namun ada gak kemungkinan nge-klik "SAVE" untuk simpan faktur pada waktu yang tepat sama.. tentu nantinya akan menghasilkan nomer primary key yang sama ? padahal transaksinya berbeda.. takutnya konflik primary..

Gimana tanggapan bro hatred?

dg mendeklarasi kolom tsb adalah "unique" (primary key otomatis unique) maka duplicate value bisa terhindari (maksudnya kalau terjadi jg, maka gagal insert)

[hatRed]

keuntungan metode tesla, dalam nested join kecepatannya tentu lebih cepat.

sebenarnya saya tidak yakin bisa (signifikan) lebih cepat 

yg jadi bahan pertimbangan adalah apakah kolom tsb "mungkin" dikemudian hari diubah oleh user.
akan menjadi "nightmare" bagi programmer jika tiba2 user meminta kita utk membuat fasilitas pengubahan primary key padahal primary key itu adalah foreign key bagi puluhan atau ratusan table lainnya.
contoh kasus yg umum adalah: perubahan kode barang (atau kode data master lainnya)... jika kode barang adalah primary key yg sudah menjadi reference bagi byk table lainnya, akan menjadi pekerjaan sulit (bukan tak mungkin) utk programmer.

utk table transaksi, pada saya melihat sangat kecil kemungkinan utk dirubah dikemudian hari shg saya jg biasa pakai kode transaksi langsung sebagai primary key...

pertimbangan itu kan gak mempermasalahkan numeric atau char string

Gw kurang tahu ya..

Cuma yang gw khawatirkan anggap kita berdua user.. mengakses database dan file yang sama, lagi input faktur yang berbeda, namun ada gak kemungkinan nge-klik "SAVE" untuk simpan faktur pada waktu yang tepat sama.. tentu nantinya akan menghasilkan nomer primary key yang sama ? padahal transaksinya berbeda.. takutnya konflik primary..

Gimana tanggapan bro hatred?

dg mendeklarasi kolom tsb adalah "unique" (primary key otomatis unique) maka duplicate value bisa terhindari (maksudnya kalau terjadi jg, maka gagal insert)

 [at] Forte

maksudnya kemungkinan dobel prim key nya atau unique fielnya ?

 [at] tesla
nah ini juga menjadi masalah soale db enginge bakal 2 kali kerja.

[Sukma Kemenyan]

primary_key adalah key yang seharusnya autogenerate...
baik itu char maupun numeric...

char... lebih acceptable di mesin manapun...
int... kalao udah bigint++ (more than 8bytes) bener2x bikin gila mesin...

Code: [Select]

0xffffffffffffffff (8 bytes)
18446744073709551615

<?php 
  echo 0xffffffffffffffff;
  //result: 1.84467440737E+19
?>nagh... coba dipikir... where id=1.84467440737E+19;
gila kaga tuh sql elo ntar jadinya...?

laen crita kalao elo ngirim ke SQL dalem bentuk where id=0xffffffffffffffff;
tapi... auk ah... belon pernah urusan sama numeric 4bytes++

[tesla]

keuntungan metode tesla, dalam nested join kecepatannya tentu lebih cepat.

sebenarnya saya tidak yakin bisa (signifikan) lebih cepat 

yg jadi bahan pertimbangan adalah apakah kolom tsb "mungkin" dikemudian hari diubah oleh user.
akan menjadi "nightmare" bagi programmer jika tiba2 user meminta kita utk membuat fasilitas pengubahan primary key padahal primary key itu adalah foreign key bagi puluhan atau ratusan table lainnya.
contoh kasus yg umum adalah: perubahan kode barang (atau kode data master lainnya)... jika kode barang adalah primary key yg sudah menjadi reference bagi byk table lainnya, akan menjadi pekerjaan sulit (bukan tak mungkin) utk programmer.

utk table transaksi, pada saya melihat sangat kecil kemungkinan utk dirubah dikemudian hari shg saya jg biasa pakai kode transaksi langsung sebagai primary key...

pertimbangan itu kan gak mempermasalahkan numeric atau char string

tentu donk,
soalnya utk primary key type begitu pasti pakai, unsigned integer auto increment hehehe

[hatRed]

di cast dunk ini nya 1.84467440737E+19 

[hatRed]

so........

it's better to choose numeric

and better more to autonumber