which one is better? index / primary key with integer or varchar?
Achmad Mardiansyah
ada sebuah tabel user yang dipakai untuk nyimpan data.
langsung aja, mana yang lebih baik membuat Primary key/index dengan
varchar (e.g. email address) atau dengan cara konvensional menggunakan
integer?
kriteria lebih baik:
- dari sisi performance
- manajemen data / perubahan data / coding
- dll
Silahkan komentarnya
salam,
Achmad Mardiansyah
aris suryadi
--
Untuk memposting, silakan reply email ini atau kirim email baru ke alamat: mysql-i...@googlegroups.com
Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat: mysql-indones...@googlegroups.com
Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi alamat: http://groups.google.com/group/mysql-indonesia?hl=id
semoga berguna
Achmad Mardiansyah
> Hallo mas Achmad
>
> Walaupun baru menggunakan MySQL
>
> Selama ini penggunaan primary key ga pernah pakai tipe data selain
> integer yang dikasih autoincrement
> biasanya field istimewa ini kami percayakan sebagai "ID" atau
> "namatableID"
>
> dari segi perform penggunaan tipe data varchar ataupun
> int(autoincrement) tidak terlalu berpengaruh signifikan,
> hanya saja kita ga perlu ribet2 kebingungan bakalan terjadi bentrok
> data di field yang dikasih primary
> karena field ID yang biasa dikasih autoincrement otomatis mengisi
> valuenya secara berurut.
primarykey-nya adalah email, dimana user sendiri yang mengetik emailnya.
saya tidak membutuhkan autoincrement karena memang tidak perlu.
>
> Dalam management data
> Jikalau program mengizinkan user mengubah username, maka penggunaan
> teknik ini cukup memudahkan
email barunya sudah ada disystem, maka ngak boleh pake email baru
tersebut toh? (contoh: facebook)
>
> Dalam segi codingpun
> penggunaan tipe ini bisa dibilang sama aja, karena filter hanya diubah
> ke field ID bukan field username sbg parameter utama
yang bikin repot adalah jika saya menggunakan int(auto increment)
sebagai primary key (field name = id), kemudian dalam tabel tersebut
juga ada field "email" yang sifatnya UNIQUE. tebel tersebut jadi punya 2
index (int & "email")
maka menurut saya adalah lebih baik langsung pake field "email" saja
supaya TIDAK memboroskan index.
dimana semakin banyak index yang kita buat, maka semakin banyak
resources yang kita pakai. RAM & CPU akan dialokasikan untuk index-index
ini. (lihat reference: tuning mysql)
field dengan flag: primary-key, secondary-key, UNIQUE akan langsung
dibuat sebagai index.
sehingga dalam tabel saya:
- saya menggunakan field "email" sebagai primary key
- saya menggunakan field "email" sebagai basis query
- saya tidak menggunakan field "id" (int-auto_increment)
yang yang sekarang jadi pertanyaan: ada komentar lain untuk desain ini?
>
> CMIWW
> semoga berguna
>
> 2010/12/27 Achmad Mardiansyah <a.mard...@gmail.com
> <mailto:a.mard...@gmail.com>>
basri sangadji
| Penggunaan primary key pada type data bisa menggunakan type data mana aja selain int tergantung pada kondisi tabel yg ada. jika tabel yg kita buat adalah tabel barang maka type data char mungkin akan di set menjadi primary key. kembali pada kasus diatas. email bisa dijadikan field uniqe dengan type data varchar. krn tidak smua org punya kesamaan email. Basri Sangadji --- Pada Sen, 27/12/10, Achmad Mardiansyah <a.mard...@gmail.com> menulis: |
|
|
Achmad Mardiansyah
tujuan: kita mau buat tabel yang menampung data user:
design1:
field1 = id (INTEGER,PRIMARY_KEY - auto increment)
field2 = email (VARCHAR,UNIQUE)
field3,4,5 dst --> data lainnya
design2:
field1 = email (VARCHAR,PRIMARY_KEY)
field 2,3,4,5 dst --> data lainnya
mana yang lebih baik: design1 atau design2?
minta tolong dijelaskan juga tentang pilihannya.
saat ini saya pribadi cenderung ke design2 karena menggunakan index yang
lebih sedikit.
namun saya belum tahu tentang performancenya.
udah googling, namun masih samar...
Aris Setyawan
menurut saya dari sisi manajemen data / perubahan data / coding akan sama.
tetapi jika dilihat dari sisi performa (jika kita memilih salah satu
index diatas), auto increment index akan memiliki performa lebih baik
dalam insert data dan select data.
kenapa? jawabannya adalah bahwa lokalitas data index b-tree pada index
auto increment akan lebih baik daripada index varchar.
lokalitas data dikatakan lebih baik, jika kita meng-insert data yang
berurutan, maka data tersebut akan disimpan pada block hardisk yang
sama jika muat dalam 1 block. dan jika tidak muat dalam 1 block, maka
akan disimpan pada block selanjutnya yang berurutan.
jika kita menggunakan index varchar (misalnya email), maka data index
kita akan disebar sesuai urutan abjad, artinya data akan tersebar
dalam block-block hardisk yang tersebar atau tidak sequensial. karena
terdapat random IO, maka jumlah disk IO-nya akan tinggi.
jika kita menggunakan index auto increment, data index kita akan
tersimpan dalam hardisk secara berurutan, sehingga hanya terjadi
maksimal sequential IO, sehingga jumlah IO-nya kecil.
jika IO yang terjadi lebih banyak, maka peforma otomatis akan lebih lambat.
jika mas ahmad berencana membuat sistem yang memiliki user banyak dan
traffic tinggi (seperti facebook atau twitter), maka auto increment
index lebih tepat untuk digunakan. jadi tergantung kebutuhan.
untuk jenis sistem tertentu, desain mas dapat dikatakan sudah tepat.
-aris
Aris Setyawan
> kalo pertanyaan di modifikasi dikit:
>
> tujuan: kita mau buat tabel yang menampung data user:
>
> design1:
> field1 = id (INTEGER,PRIMARY_KEY - auto increment)
> field2 = email (VARCHAR,UNIQUE)
> field3,4,5 dst --> data lainnya
>
> design2:
> field1 = email (VARCHAR,PRIMARY_KEY)
> field 2,3,4,5 dst --> data lainnya
>
> mana yang lebih baik: design1 atau design2?
> minta tolong dijelaskan juga tentang pilihannya.
>
> saat ini saya pribadi cenderung ke design2 karena menggunakan index yang
> lebih sedikit.
> namun saya belum tahu tentang performancenya.
> udah googling, namun masih samar...
anda perlu melakukan benchmark dulu, karena pada desain 1, memang
menggunakan auto increment, tetapi disitu adan UNIQUE constraint.
misalnya melakukan benchmark insert 10000 row random, dan mencatat
waktu eksekusinya.
Achmad Mardiansyah
kalo ada yang mau share tentang implementasi dilapangan silahkan.
On 12/27/2010 05:29 PM, Aris Setyawan wrote:
>> pribadi cenderung ke design2 karena menggunakan index yang
>> > lebih sedikit.
>> > namun saya belum tahu tentang performancenya.
>> > udah googling, namun masih samar...
> anda perlu melakukan benchmark dulu, karena pada desain 1, memang
> menggunakan auto increment, tetapi disitu adan UNIQUE constraint.
> misalnya melakukan benchmark insert 10000 row random, dan mencatat
> waktu eksekusinya.
right... benchmark.
Endy Muhardin
> thanks banyak buat replynya.
>
> kalo ada yang mau share tentang implementasi dilapangan silahkan.
>
Prinsip saya dalam membuat aplikasi : paling penting adalah correctness.
Performance urusan belakangan.
Kode program yang correct akan mudah dituning.
Sedangkan kode program yang nyeleneh, *mungkin* di awal memberikan
performance yang sedikit lebih tinggi.
Tapi akan menyulitkan untuk dituning lebih jauh lagi.
Jangan mikir performance tuning dulu pada fase desain.
Fokus aja ke correctness.
Selalu ingat aturan performance tuning
Rule 1 : don't do it
Rule 2 (expert only) : don't do it yet
Tuning performance hampir selalu akan membuat source code jadi jelek,
struktur tabel jadi aneh, dsb.
Ini akan menyulitkan maintenance (bugfix, tambah fitur, refactoring)
Kalo saya sih, tuning itu lebih baik di parameter konfigurasi, bukan
di source code apalagi di skema db.
Kalo parameter konfig tidak memungkinkan, lebih baik upgrade hardware,
clustering,
atau solusi2 lainnya yang bersifat non-coding.
Saya menempatkan correctness dan maintainability source code di atas segalanya.
Mengenai primary key, SELALU gunakan surrogate key.
Surrogate key adalah field yang nilainya digenerate dan tidak memiliki
business meaning.
Bisa bertipe integer dan autoincrement, atau bisa juga bertipe varchar
yang diisi dengan GUID.
Sekali lagi, jangan dulu mikir tambahan satu kolom akan berpengaruh
terhadap size, index, dan performance.
Jaman sekarang, harddisk murah, CPU makin kenceng, memori harganya
terjun bebas.
Jauh lebih gampang beli harddisk tambahan daripada mengubah seluruh
aplikasi pada saat ada perubahan requirement.
Contohnya : email dijadikan PK.
Suatu hari nanti, ada perubahan business requirement, user boleh ganti email.
Nah lho, itu email sudah jadi FK di mana2. Gimana cara gantinya?
--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --
Aris Setyawan
Terdapat banyak kondisi yang membuat kita tidak bisa dengan mudah
untuk mengupgrade hardware. Tidak dipungkiri juga, bahwa upgrade
hardware bisa menjadi solusi untuk meningkatkan performa.
Dalam basisdata "time" akan berkebalikan dengan "space", "performance
tunning" akan bertentangan dengan "normalisasi data". Terkadang kita
harus masuk ke dalamnya.
Semuanya tergantung problem yang dihadapi.
Feris Thia
Mengenai primary key, SELALU gunakan surrogate key.
Surrogate key adalah field yang nilainya digenerate dan tidak memiliki
business meaning.
Bisa bertipe integer dan autoincrement, atau bisa juga bertipe varchar
yang diisi dengan GUID.
Sekali lagi, jangan dulu mikir tambahan satu kolom akan berpengaruh
terhadap size, index, dan performance.
Jaman sekarang, harddisk murah, CPU makin kenceng, memori harganya
terjun bebas.
Jauh lebih gampang beli harddisk tambahan daripada mengubah seluruh
aplikasi pada saat ada perubahan requirement.
Contohnya : email dijadikan PK.
Suatu hari nanti, ada perubahan business requirement, user boleh ganti email.
Nah lho, itu email sudah jadi FK di mana2. Gimana cara gantinya?
Sekali lagi setuju... casenya sangat terkenal sebagai SCD di data warehouse :
--
Thanks & Best Regards,
Feris Thia
Business Intelligence Consultant
PT. Putera Handal Indotama
Phone : +6221-30119353
Fax : +6221-5513483
Mobile : +628176-474-525
http://www.phi-integration.com
http://pentaho.phi-integration.com
http://sqlserver-tips.phi-integration.com
Endy Muhardin
>
> Dalam basisdata "time" akan berkebalikan dengan "space", "performance
> tunning" akan bertentangan dengan "normalisasi data". Terkadang kita
> harus masuk ke dalamnya.
>
> Semuanya tergantung problem yang dihadapi.
Setuju, ada kalanya kita harus mengorbankan normalisasi dan
konsistensi data demi performance.
Walaupun demikian, performance tuning itu waktunya adalah SETELAH
aplikasi dibuat dengan prinsip correctness.
Bukan pada waktu desain skema database, dengan kata lain SEBELUM coding.
didino...@gmail.com
Sent from my BlackBerry® smartphone from Sinyal Bagus XL, Nyambung Teruuusss...!
-----Original Message-----
From: Endy Muhardin <endy.m...@gmail.com>
Sender: mysql-i...@googlegroups.com
Date: Tue, 28 Dec 2010 10:32:24
To: <mysql-i...@googlegroups.com>
Reply-To: mysql-i...@googlegroups.com
Subject: Re: [MySQL-Indonesia] which one is better? index / primary key with
integer or varchar?
Untuk memposting, silakan reply email ini atau kirim email baru ke alamat: mysql-i...@googlegroups.com
Endy Muhardin
> Mengorbankan konsistensi data? Maksudnya bagaimana pak?
Coba pelajari istilah CAP theorem
http://en.wikipedia.org/wiki/CAP_theorem
Natali Ardianto
1. What if the user changes his email?
2. index size dan column size:
char: nat...@ardianto.com = 19 bytes.
int: 5,708990770823839524233143877798e+45 = 19 bytes. (actually ngga ada yg 19 bytes :P)
3. Kalau pakai email sebagai PK, maka semua table harus pakai email sebagai foreign key joinnya, dan di index pula.
--
Natali Ardianto
nat...@ardianto.com
@nataliardianto
--
Untuk memposting, silakan reply email ini atau kirim email baru ke alamat: mysql-i...@googlegroups.com
Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat: mysql-indones...@googlegroups.com
Achmad Mardiansyah
tak jawab yah, hehehe
On 12/28/2010 07:34 PM, Natali Ardianto wrote:
Please help me answer this:
1. What if the user changes his email?
please explain your comments instead of write a question.
2. index size dan column size:
char: nat...@ardianto.com = 19 bytes.
int: 5,708990770823839524233143877798e+45 = 19 bytes. (actually ngga ada yg 19 bytes :P)
3. Kalau pakai email sebagai PK, maka semua table harus pakai email sebagai foreign key joinnya, dan di index pula.
thanks buat yang udah comment.
sejauh ini, kedua design sama2 dapat berjalan dengan baik.
namun dari sisi performance & maintainability perlu banyak masukan.
usulan2 yang masuk akan dipertimbangkan.
dari komentar yang masuk, saya setuju dengan komentar bung endy tentang surrogates key.
bisa untuk antisipasi masa depan kalau2 ada kebijakan yang membolehkan email ganda.