Praktik Buruk dalam Desain Basis Data: Apakah Anda Membuat Kesalahan Ini?

Setiap kali Anda sebagai pengembang diberi tugas berdasarkan kode yang ada, Anda harus menghadapi banyak tantangan. Salah satu tantangan tersebut—lebih sering yang paling menuntut—melibatkan pemahaman model data aplikasi.

Anda biasanya dihadapkan dengan tabel, tampilan, kolom, nilai, prosedur tersimpan, fungsi, batasan, dan pemicu yang membingungkan yang membutuhkan waktu lama untuk masuk akal bagi Anda. Dan, begitu mereka melakukannya, Anda mulai memperhatikan banyak cara untuk meningkatkan dan memanfaatkan informasi yang tersimpan.

Jika Anda seorang pengembang berpengalaman, kemungkinan besar Anda juga akan melihat hal-hal yang seharusnya bisa dilakukan dengan lebih baik di awal, yaitu kekurangan desain.

Dalam artikel ini, Anda akan belajar tentang beberapa praktik buruk desain database yang umum, mengapa itu buruk, dan bagaimana Anda bisa menghindarinya.

Praktik Buruk No. 1: Mengabaikan Tujuan Data

Data disimpan untuk dikonsumsi kemudian, dan tujuannya selalu untuk menyimpan dan mengambilnya dengan cara yang paling efisien. Untuk mencapai hal ini, perancang basis data harus mengetahui terlebih dahulu apa yang akan diwakili oleh data, bagaimana data itu akan diperoleh dan pada tingkat berapa, berapa volume operasionalnya (yaitu, berapa banyak data yang diharapkan), dan, akhirnya. , bagaimana itu akan digunakan.

Misalnya, sistem informasi industri di mana data dikumpulkan secara manual setiap hari tidak akan memiliki model data yang sama dengan sistem industri di mana informasi dihasilkan secara real time. Mengapa? Karena sangat berbeda menangani beberapa ratus atau ribuan catatan per bulan dibandingkan dengan mengelola jutaan catatan dalam periode yang sama. Pertimbangan khusus harus dibuat oleh perancang untuk menjaga efisiensi dan kegunaan database, jika volume data ingin besar.

Namun, tentu saja, volume data bukan satu-satunya aspek yang perlu dipertimbangkan, karena tujuan data juga mempengaruhi tingkat normalisasi, struktur data, ukuran record, dan implementasi umum dari keseluruhan sistem.

Oleh karena itu, mengetahui secara menyeluruh tujuan sistem data yang akan Anda buat mengarah pada pertimbangan dalam pemilihan mesin basis data, entitas yang akan dirancang, ukuran dan format catatan, dan kebijakan manajemen mesin basis data.

Mengabaikan tujuan ini akan menyebabkan desain yang cacat pada dasarnya, meskipun secara struktural dan matematis benar.

Praktik Buruk No. 2: Normalisasi Buruk

Merancang database bukanlah tugas deterministik; dua perancang basis data dapat mengikuti semua aturan dan prinsip normalisasi untuk masalah tertentu, dan dalam banyak kasus mereka akan menghasilkan tata letak data yang berbeda. Ini melekat pada sifat kreatif rekayasa perangkat lunak. Namun, ada beberapa teknik analisis yang masuk akal dalam setiap contoh, dan mengikutinya adalah cara terbaik untuk mendapatkan database yang berkinerja terbaik.

Meskipun demikian, kita sering dihadapkan dengan database yang dirancang dengan cepat tanpa mengikuti aturan normalisasi yang paling dasar. Kami harus menjelaskan bahwa: Setiap database harus, setidaknya, dinormalisasi ke bentuk normal ketiga, karena tata letak yang paling mewakili entitas Anda, dan yang kinerjanya akan paling seimbang antara kueri dan penyisipan-perbaruan-hapus catatan .

Jika Anda menemukan tabel yang tidak sesuai dengan 3NF, 2NF, atau bahkan 1NF, pertimbangkan untuk mendesain ulang tabel ini. Upaya yang Anda investasikan untuk melakukannya akan terbayar dalam jangka pendek.

Praktik Buruk No. 3: Redundansi

Sangat terkait dengan poin sebelumnya, karena salah satu tujuan normalisasi adalah untuk menguranginya, redundansi adalah praktik buruk lain yang cukup sering muncul.

Bidang dan tabel yang berlebihan adalah mimpi buruk bagi pengembang, karena mereka memerlukan logika bisnis untuk menjaga agar banyak versi dari informasi yang sama tetap mutakhir. Ini adalah overhead yang dapat dihindari jika aturan normalisasi diikuti secara menyeluruh. Meskipun terkadang redundansi mungkin tampak perlu, itu harus digunakan hanya dalam kasus yang sangat spesifik dan didokumentasikan dengan jelas untuk dipertimbangkan dalam pengembangan di masa mendatang.

Efek buruk khas dari redundansi adalah peningkatan ukuran database yang tidak perlu, data rentan terhadap inkonsistensi, dan penurunan efisiensi database, tetapi—yang lebih penting—dapat menyebabkan korupsi data.

Praktik Buruk No. 4: Integritas Referensial Buruk (Kendala)

Integritas referensial adalah salah satu alat paling berharga yang disediakan mesin basis data untuk menjaga kualitas data sebaik mungkin. Jika tidak ada kendala atau sangat sedikit kendala yang diimplementasikan dari tahap desain, integritas data harus bergantung sepenuhnya pada logika bisnis, sehingga rentan terhadap kesalahan manusia.

Praktik Buruk No. 5: Tidak Memanfaatkan Fitur DB Engine

Saat Anda menggunakan mesin database (DBE), Anda memiliki perangkat lunak yang kuat untuk tugas penanganan data Anda yang akan menyederhanakan pengembangan perangkat lunak dan menjamin bahwa informasi selalu benar, aman, dan dapat digunakan. DBE menyediakan layanan seperti:

• Tampilan yang menyediakan cara cepat dan efisien untuk melihat data Anda, biasanya denormalisasi untuk tujuan kueri tanpa kehilangan kebenaran data.
• Indeks yang membantu mempercepat kueri pada tabel.
• Fungsi agregat yang membantu menganalisis informasi tanpa pemrograman.
• Transaksi atau blok kalimat pengubah data yang semuanya dieksekusi dan dilakukan atau dibatalkan (digulung kembali) jika sesuatu yang tidak terduga terjadi, sehingga menjaga informasi dalam keadaan benar selamanya.
• Kunci yang menjaga keamanan dan kebenaran data saat transaksi dijalankan.
• Prosedur tersimpan yang menyediakan fitur pemrograman untuk memungkinkan tugas manajemen data yang kompleks.
• Fungsi yang memungkinkan perhitungan canggih dan transformasi data.
• Batasan yang membantu menjamin kebenaran data dan menghindari kesalahan.
• Pemicu yang membantu mengotomatiskan tindakan saat peristiwa terjadi pada data.
• Pengoptimal perintah (perencana eksekusi) yang berjalan di bawah kap, memastikan bahwa setiap kalimat dieksekusi dengan sebaik-baiknya dan menjaga rencana eksekusi untuk kesempatan mendatang. Ini adalah salah satu alasan terbaik untuk menggunakan tampilan, prosedur tersimpan, dan fungsi, karena rencana eksekusinya disimpan secara permanen di DBE.

Tidak mengetahui atau mengabaikan kemampuan ini akan membawa pengembangan ke jalur yang sangat tidak pasti dan tentunya untuk bug dan masalah di masa depan.

Praktik Buruk No. 6: Kunci Primer Gabungan

Ini adalah poin yang kontroversial, karena banyak perancang basis data saat ini berbicara tentang menggunakan bidang yang dibuat secara otomatis dengan ID bilangan bulat sebagai kunci utama, bukan gabungan yang ditentukan oleh kombinasi dua atau lebih bidang. Ini saat ini didefinisikan sebagai "praktik terbaik" dan, secara pribadi, saya cenderung setuju dengannya.

Namun, ini hanya konvensi dan, tentu saja, DBE memungkinkan definisi kunci primer komposit, yang menurut banyak desainer tidak dapat dihindari. Oleh karena itu, seperti halnya redundansi, kunci primer komposit adalah keputusan desain.

Namun, berhati-hatilah, jika tabel Anda dengan kunci primer komposit diharapkan memiliki jutaan baris, indeks yang mengontrol kunci komposit dapat tumbuh hingga titik di mana kinerja operasi CRUD sangat menurun. Dalam hal ini, jauh lebih baik untuk menggunakan kunci utama ID integer sederhana yang indeksnya akan cukup kompak dan menetapkan batasan DBE yang diperlukan untuk mempertahankan keunikan.

Praktik Buruk No. 7: Pengindeksan Buruk

Terkadang, Anda akan memiliki tabel yang perlu Anda kueri menurut banyak kolom. Saat tabel bertambah, Anda akan melihat bahwa SELECT pada kolom ini melambat. Jika tabel cukup besar, Anda akan berpikir, secara logis, untuk membuat indeks pada setiap kolom yang Anda gunakan untuk mengakses tabel ini hanya untuk segera menemukan bahwa kinerja SELECT meningkat tetapi INSERT, UPDATE, dan DELETE turun. Ini, tentu saja, karena fakta bahwa indeks harus tetap disinkronkan dengan tabel, yang berarti biaya besar untuk DBE. Ini adalah kasus tipikal pengindeksan berlebih yang dapat Anda selesaikan dengan banyak cara; misalnya, hanya memiliki satu indeks pada semua kolom yang berbeda dari kunci utama yang Anda gunakan untuk menanyakan tabel, mengurutkan kolom ini dari yang paling sering digunakan hingga yang paling sedikit dapat menawarkan kinerja yang lebih baik di semua operasi CRUD daripada satu indeks per kolom.

Di sisi lain, memiliki tabel tanpa indeks pada kolom yang digunakan untuk kueri, seperti yang kita semua tahu, akan menyebabkan kinerja yang buruk pada SELECT.

Juga, efisiensi indeks terkadang bergantung pada jenis kolom; indeks pada kolom INT menunjukkan kinerja terbaik, tetapi indeks pada VARCHAR, DATE atau DECIMAL (jika masuk akal) tidak seefisien itu. Pertimbangan ini bahkan dapat menyebabkan mendesain ulang tabel yang perlu diakses dengan efisiensi terbaik.

Oleh karena itu, pengindeksan selalu merupakan keputusan yang rumit, karena terlalu banyak pengindeksan bisa sama buruknya dengan terlalu sedikit dan karena tipe data kolom yang akan diindeks memiliki pengaruh besar pada hasil akhir.

Praktik Buruk No. 8: Konvensi Penamaan yang Buruk

Ini adalah sesuatu yang selalu dihadapi oleh programmer ketika menghadapi database yang ada: memahami informasi apa yang disimpan di dalamnya dengan nama tabel dan kolom karena, seringkali, tidak ada cara lain.

Nama tabel harus menjelaskan entitas apa yang dipegangnya, dan setiap nama kolom harus menjelaskan bagian informasi apa yang diwakilinya. Ini mudah, tetapi mulai rumit ketika tabel harus berhubungan satu sama lain. Nama mulai menjadi berantakan dan, lebih buruk lagi, jika ada konvensi penamaan yang membingungkan dengan norma yang tidak logis (seperti, misalnya, "nama kolom harus 8 karakter atau kurang"). Konsekuensi terakhir adalah database menjadi tidak terbaca.

Oleh karena itu, konvensi penamaan selalu diperlukan jika database diharapkan bertahan dan berkembang dengan aplikasi yang didukungnya, dan berikut adalah beberapa panduan untuk membuat database yang ringkas, sederhana, dan mudah dibaca:

• Tidak ada batasan pada ukuran nama tabel atau kolom. Lebih baik memiliki nama deskriptif daripada akronim yang tidak ada yang ingat atau mengerti.
• Nama yang sederajat memiliki arti yang sama. Hindari memiliki bidang yang memiliki nama yang sama tetapi dengan jenis atau arti yang berbeda; ini akan membingungkan cepat atau lambat.
• Kecuali perlu, jangan berlebihan. Misalnya, dalam tabel “Item”, tidak perlu ada kolom seperti “ItemName”, “PriceOfItem”, atau nama yang serupa; "Nama" dan "Harga" sudah cukup.
• Waspadalah terhadap kata-kata yang dicadangkan DBE. Jika kolom akan disebut "Index," yang merupakan kata yang dicadangkan SQL, coba gunakan yang berbeda seperti "IndexNumber."
• Jika berpegang pada aturan kunci utama sederhana (bilangan bulat tunggal dibuat secara otomatis), beri nama "Id" di setiap tabel.
• Jika bergabung ke tabel lain, tentukan kunci asing yang diperlukan sebagai bilangan bulat, bernama "Id" diikuti dengan nama tabel yang digabungkan (misalnya, IdItem).
• Jika penamaan kendala, gunakan awalan yang menjelaskan kendala (misalnya, "PK" atau "FK"), diikuti dengan nama tabel atau tabel yang terlibat. Tentu saja, menggunakan garis bawah (“_”) dengan hemat membantu membuat segalanya lebih mudah dibaca.
• Untuk memberi nama indeks, gunakan awalan “BEI” diikuti dengan nama tabel dan kolom atau kolom indeks. Juga, gunakan "UNIQUE" sebagai awalan atau akhiran jika indeksnya unik, dan garis bawahi jika perlu.

Ada banyak pedoman penamaan database di internet yang akan menyoroti aspek yang sangat penting dari desain database ini, tetapi dengan yang dasar ini, Anda setidaknya bisa mendapatkan database yang dapat dibaca. Yang penting di sini bukanlah ukuran atau kerumitan pedoman penamaan Anda, tetapi konsistensi Anda dalam mengikutinya!

Beberapa Catatan Akhir

Desain database adalah kombinasi dari pengetahuan dan pengalaman; industri perangkat lunak telah banyak berkembang sejak awal. Untungnya, ada cukup pengetahuan yang tersedia untuk membantu perancang basis data mencapai hasil terbaik.

Ada pedoman desain database yang baik di seluruh internet serta praktik buruk dan hal-hal yang harus dihindari dalam desain database. Pilih saja dan patuhi itu.

Dan, jangan lupa, hanya melalui eksperimen, kesalahan, dan kesuksesan yang Anda pelajari, jadi lanjutkan dan mulai sekarang.