Pilih mana ya????
Tergantung style programming seh.. kalau style gw Saya cenderung pilih char.. karena saya lebih suka 00001 daripada 1
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 ;D
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.
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)
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)
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?
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
Quote from: hatRed on 15 January 2009, 09:02:23 AM
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...
Quote from: Forte on 15 January 2009, 10:04:20 AM
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)
Quote from: tesla on 15 January 2009, 10:38:42 AM
Quote from: hatRed on 15 January 2009, 09:02:23 AM
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 :hammer:
Quote from: tesla on 15 January 2009, 10:44:34 AM
Quote from: Forte on 15 January 2009, 10:04:20 AM
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.
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...
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++
Quote from: hatRed on 15 January 2009, 10:50:53 AM
Quote from: tesla on 15 January 2009, 10:38:42 AM
Quote from: hatRed on 15 January 2009, 09:02:23 AM
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 :hammer:
tentu donk,
soalnya utk primary key type begitu pasti pakai, unsigned integer auto increment hehehe
di cast dunk ini nya 1.84467440737E+19 :D
so........
it's better to choose numeric :)
and better more to autonumber :)
Quote from: hatRed on 15 January 2009, 11:08:58 AM
so........
it's better to choose numeric :)
and better more to autonumber :)
semua depend on condition :)
Quote from: tesla on 15 January 2009, 11:30:16 AM
Quote from: hatRed on 15 January 2009, 11:08:58 AM
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?
Quote from: hatRed on 15 January 2009, 11:39:34 AM
Quote from: tesla on 15 January 2009, 11:30:16 AM
Quote from: hatRed on 15 January 2009, 11:08:58 AM
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.
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. :D
gmana :-?
Quote from: hatRed on 15 January 2009, 12:49:15 PM
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. :D
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 = userId2. 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)