sekilas my sql
1 Tipe Data
Berbeda
dengan PHP dan bahasa-bahasa skripting yang mengizinkan kita menaruh apa saja
dalam sebuah $variable tanpa
deklarasi tipe terlebih dahulu, di MySQL kita perlu mendeklarasikan tipe-tipe
data semua field yang ada pada saat membuat sebuah tabel. Seorang programer PHP
yang tidak kenal MySQL kadang-kadang cenderung memilih jenis data yang salah
(umumnya: memilih VARCHAR() padahal ada tipe data yang lebih tepat) dikarenakan
tidak mengenal jenis-jenis data yang tersedia.
Berikut
beberapa contoh kurang tepatnya pemilihan tipe data: 1) memilih CHAR(8) atau VARCHAR(10) dan bukannya DATE
untuk menyimpan tanggal; kerugiannya, lebih boros tempat dan tidak bisa
memanfaatkan fungsi-fungsi khusus tanggal; 2) memilih CHAR(3) atau CHAR(6) ketimbang TINYINT
UNSIGNED untuk menyimpan data boolean (“YES” dan “NO”; atau “TRUE”
dan “FALSE”; padahal jauh lebih irit dinyatakan dengan 1 dan 0 yang hanya
menempati 1 byte); 3) memilih FLOAT atau DOUBLE dan bukannya DECIMAL untuk
menyimpan jumlah uang; kerugiannya, FLOAT dan DOUBLE adalah berbasis biner dan
seringkali tidak eksak dalam menyimpan pecahan desimal.
Nomor
3 sering terjadi karena programer biasanya hanya mengenal single/double
floating point number yang tersedia di bahasa pemrograman. Padahal database
umumnya menyediakan angka pecahan berbasis desimal yang bisa eksak menyimpan
pecahan desimal.
Manual
MySQL amat membantu di sini; di subbab tentang Column Types dijelaskan dengan rinci jenis-jenis data yang ada,
termasuk rentang nilai yang dapat ditampung, berapa byte yang ditempati tipe
data tersebut, dsb.
2 Normalisasi dan Pemodelan
Normalisasi,
skema, entiti-atribut, primary key (PK) dan foreign key (FK), tabel entiti,
tabel relasi, OLTP & OLAP… semuanya adalah istilah-istilah yang umum
dijumpai dalam pemodelan fisik database. Sayangnya, banyak programer pemula
tidak memiliki kemampuan modeling. Sehingga jika disuruh mendesain skema
database (sekumpulan tabel-tabel beserta nama field dan tipenya) hasilnya tidak
optimal bahkan berantakan. Skema yang buruk berakibat terjadinya duplikasi
data, tidak scalable, performance yang buruk, tidak memenuhi requirements, dsb.
Modeling
tentunya tidak bisa diajarkan dalam 1–2 hari, apalagi dalam artikel yang
singkat ini. Anda perlu membaca buku-buku mengenai pemodelan database dan
belajar dari pengalaman maupun dari model-model yang sudah ada. Tapi beberapa
nasihat yang mungkin bisa saya berikan di sini adalah sbb.
Satu, langkah pertama dalam pemodelan
adalah menemukan entiti-entiti. Entiti bisa dibilang “objek” yang akan kita
gelluti. Misalnya, customer, produk, dan transaksi. Setiap entiti umumnya
ditaruh dalam satu tabel, tabel ini disebut tabel entiti. Langkah kedua adalah
mencari atribut-atribut entiti tersebut. Misalnya tabel customers memiliki
atribut sapaan, nama, alamat (jalan + kota
+ kodepos + propinsi + negara), tanggal record ini ditambahkan, dsb. Langkah
ketiga adalah mencari relasi di antara entiti-entiti. Umumnya relasi adalah
satu dari: 1-1, 1-many, many-many. Misalnya, relasi antara transaksi dan produk
adalah many-many, artinya sebuah transaksi pembelian dapat berisi banyak produk
dan sebuah produk tentu saja dapat dibeli dalam lebih dari satu transaksi.
Setiap relasi juga akan ditempatkan pada tabel, yaitu tabel relasi.
Dua, dalam pemodelan tidak ada istilah
model yang benar atau salah. Yang ada adalah model yang tepat dan tidak tepat
untuk keperluan tertentu. Misalnya, untuk aplikasi sederhana modelnya
sederhana. Semakin kompleks aplikasi, model pun semakin rumit (jumlah entiti,
relasi, dan atribut akan bertambah). Pada umumnya, seiring kompleksitas
bertambah, yang tadinya atribut akan
berubah menjadi entiti dikarenakan adanya kenyataan hubungan
1-many/many-many antara atribut. Contohnya, tabel customers memiliki atribut
alamat. Jika kita ingin mendukung banyak alamat untuk satu customers, maka
alamat akan menjadi entiti dan menempati tabel sendiri. Lalu kita membuat tabel
relasi customers-alamat.
3 Indeks
Indeks
adalah sesuatu yang berkaitan erat dengan implementasi, bukan modeling. Kita
seringkali perlu menambahkan indeks pada sebuah field atau banyak field
dikarenakan jika tidak ditambahkan maka performance database tidak menjadi
praktis. Serba-serbi indexing juga mungkin terlalu panjang untuk bisa
dijelaskan dalam artikel pendek ini, tapi intinya setiap kolom yang: 1)
memiliki rentang nilai cukup banyak; 2) terletak pada tabel yang berisi banyak
record; 3) seringkali disebutkan di klausa WHERE
dan/atau ORDER BY dan/atau GROUP BY; perlu diberi indeks. Ini
dikarenakan indeks membantu mencari
secara cepat sebuah nilai dari banyak nilai yang ada. Beberapa contoh:
*
Setiap primary key umumnya otomatis diberi indeks oleh database server,
meskipun tabelnya masih berisi sedikit record atau bahkan kosong. Ini
dikarenakan database perlu selalu mengecek keberadaan sebuah nilai field ini
manakala ada sebuah record yang ditambahkan (ingat, PK artinya tak boleh ada dua
record yang mengandung nilai field ini yang sama). Tanpa indexing, pengecekan
akan linear dan memakan waktu lama.
*
Field tanggal lahir dalam tabel customers kemungkinan besar harus diindeks.
Bahkan dayofyear() field ini
juga mungkin perlu diindeks. Mengapa? Karena: 1) rentang nilai cukup besar (365
hari dalam setahun x +- 60 jumlah tahun); 2) tabel customers potensial
ukurannya besar; 3) sering disebutkan di klausa WHERE (misalnya mencari customer yang ultah hari ini).
*
Field memo/notes kemungkinan besar tidak perlu diindeks (secara biasa).
Mengapa? Karena meskipun 1) rentang nilai cukup besar; dan 2) tabel customers
bisa besar; tapi 3) field ini tidak pernah disebutkan di klausa WHERE secara langsung (mis: Anda tidak
pernah menyebutkan: … WHERE notes='nilai
catatan tertentu' atau WHERE
notes > 'nilai tertentu'). [Catatan: ada indeks lain yang “tidak
biasa” di MySQL, yaitu FULLTEXT. Tapi ini di luar cakupan artikel kita kali
ini.]
*
Field jenis kelamin mungkin tidak perlu diindeks, kecuali jika perbandingan
pria:wanita amat drastis bedanya. Mengapa? Sebab: 1) rentang nilai yang ada
hanyalah dua: L (lelaki) dan P (perempuan). Meskipun Anda beri indeks, tidak
akan memperbaiki kinerja.

Tidak ada komentar:
Posting Komentar