Kesilapan biasa dibuat dalam Reka Bentuk Pangkalan Data

Sama ada anda bekerja dengan pangkalan data yang memegang beratus-ratus rekod atau jutaan rekod, reka bentuk pangkalan data yang betul selalu penting. Bukan sahaja ia akan membuat pengambilan maklumat lebih mudah, ia juga memudahkan penyebaran pangkalan data pada masa akan datang. Sayangnya, mudah untuk jatuh ke dalam beberapa perangkap yang boleh membuat sesuatu sukar di masa depan.

Terdapat keseluruhan buku yang ditulis mengenai subjek menormalkan pangkalan data, tetapi jika anda hanya mengelakkan kesilapan yang biasa ini, anda akan berada di landasan yang betul untuk reka bentuk pangkalan data yang baik.

Kesilapan Pangkalan Data # 1: Mengulangi Medan dalam Jadual

Peraturan asas ibu jari untuk reka bentuk pangkalan data yang baik adalah untuk mengiktiraf data mengulang dan meletakkan mereka yang mengulangi lajur dalam jadual mereka sendiri. Bidang mengulangi dalam jadual adalah perkara biasa bagi mereka yang datang dari dunia spreadsheet, tetapi ketika spreadsheet cenderung datar oleh reka bentuk, pangkalan data haruslah relasi. Ia seperti pergi dari 2D ke 3D.

Nasib baik, bidang berulang biasanya mudah dilihat. Lihat saja jadual ini:

OrderID Product1 Product2 Product3
1 Patung beruang Jelly Beans
2 Jelly Beans

Apa yang berlaku apabila pesanan mengandungi empat produk? Kami perlu menambah medan lain ke meja untuk menyokong lebih daripada tiga produk. Dan jika kami telah membina aplikasi klien di sekitar meja untuk membantu kami memasukkan data, kami mungkin perlu mengubahnya dengan medan produk baru. Dan bagaimana kita mencari semua pesanan dengan Jellybeans dalam perintah itu? Kami akan dipaksa untuk menanyakan setiap bidang produk dalam jadual dengan penyataan SQL yang mungkin kelihatan seperti: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OR Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'.

Daripada mempunyai satu jadual yang menggabungkan semua maklumat bersama-sama, kita harus mempunyai tiga jadual yang masing-masing memegang sekeping maklumat yang berbeza. Dalam contoh ini, kami ingin meja Pesanan dengan maklumat tentang pesanan itu sendiri, jadual Produk dengan semua produk kami dan tablet ProductOrders yang menghubungkan produk dengan pesanan.

OrderID ID pelanggan Tarikh pesanan Jumlah
1 7 1/24/17 19.99
2 9 1/25/17 24.99
ProductID Produk Kira
1 Patung beruang 1
2 Jelly Beans 100
ProductOrderID ProductID OrderID
101 1 1
102 2 1

Perhatikan bagaimana setiap jadual mempunyai bidang ID unik. Ini adalah kunci utama. Kami menghubungkan jadual dengan menggunakan nilai utama utama sebagai kunci asing dalam jadual lain. Baca lebih lanjut mengenai kunci utama dan kekunci asing.

Kesilapan Pangkalan Data # 2: Memasukkan Jadual dalam Jadual

Ini adalah satu lagi kesilapan yang biasa, tetapi ia tidak selalu menonjolkan medan berulang. Apabila mereka bentuk pangkalan data, anda ingin memastikan semua data dalam jadual berkaitan dengan dirinya sendiri. Ia seperti permainan kanak-kanak tentang apa yang berbeza. Jika anda mempunyai pisang, strawberi, pic dan set televisyen, set televisyen mungkin dimiliki di tempat lain.

Sepanjang baris yang sama, jika anda mempunyai jadual orang jualan, semua maklumat di dalam jadual itu sepatutnya berkaitan dengan orang jualan itu. Apa-apa maklumat tambahan yang tidak unik untuk orang jualan itu boleh dimiliki di tempat lain dalam pangkalan data anda.

SalesID Pertama Terakhir Alamat Nombor telefon Pejabat OfficeNumber
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 Austin Downtown (212) 421-2412
2 Alice Smith 504 2nd Street, New York, NY (211) 122-1821 New York (Timur) (211) 855-4541
3 Joe Parish 428 Aker St, Austin, TX (215) 545-5545 Austin Downtown (212) 421-2412

Walaupun jadual ini kelihatan seperti ia berkaitan dengan jurujual individu, ia sebenarnya mempunyai jadual yang tertanam di dalam jadual. Perhatikan bagaimana Office dan OfficeNumber berulang dengan "Austin Downtown". Bagaimana jika nombor telefon pejabat berubah? Anda perlu mengemas kini satu set keseluruhan data untuk satu perubahan maklumat yang tidak pernah menjadi perkara yang baik. Bidang ini harus dipindahkan ke meja mereka sendiri.

SalesID Pertama Terakhir Alamat Nombor telefon OfficeID
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 1
2 Alice Smith 504 2nd Street, New York, NY (211) 122-1821 2
3 Joe Parish 428 Aker St, Austin, TX (215) 545-5545 1
OfficeID Pejabat OfficeNumber
1 Austin Downtown (212) 421-2412
2 New York (Timur) (211) 855-4541

Reka bentuk jenis ini juga memberikan anda keupayaan untuk menambah maklumat tambahan ke meja Pejabat tanpa membuat mimpi buruk kekacauan dalam jadual orang jualan. Bayangkan berapa banyak kerja yang akan dilakukan untuk hanya menjejaki alamat jalan, kota, negeri dan kod zip sekiranya semua maklumat itu berada dalam jadual jualan orang!

Kesilapan Pangkalan Data # 3: Meletakkan Dua atau Lebih Banyak Maklumat Ke Dalam Bidang Tunggal

Memasukkan maklumat pejabat ke dalam jadual orang jualan bukan satu-satunya masalah dengan pangkalan data tersebut. Medan alamat mengandungi tiga maklumat: alamat jalan, kota dan negara. Setiap medan dalam pangkalan data hanya perlu mengandungi satu maklumat. Apabila anda mempunyai banyak maklumat dalam satu bidang, dapat menjadi lebih sulit untuk menanyakan pangkalan data untuk informasi.

Sebagai contoh, bagaimana jika kami mahu membuat pertanyaan mengenai semua orang jualan dari Austin? Kita perlu mencari dalam bidang alamat, yang bukan hanya tidak cekap, tetapi dapat mengembalikan maklumat yang buruk. Lagipun, apa yang berlaku jika seseorang tinggal di jalan Austin di Portland, Oregon?

Inilah yang sepatutnya kelihatan seperti jadual:

SalesID Pertama Terakhir Alamat 1 Alamat 2 City Negeri Zip Telefon
1 Sam Elliot 118 Main St Austin TX 78720 2155555858
2 Alice Smith 504 2nd St New York NY 10022 2111221821
3 Joe Parish 428 Aker St Apt 304 Austin TX 78716 2155455545

Terdapat beberapa perkara yang perlu diperhatikan di sini. Pertama, "Address1" dan "Address2" nampaknya berada di bawah kesilapan medan berulang.

Walau bagaimanapun, dalam kes ini, mereka merujuk kepada kepingan data yang berasingan yang berkaitan langsung dengan orang jualan dan bukannya kumpulan data yang berulang yang harus masuk dalam jadualnya sendiri.

Juga, sebagai kesilapan bonus untuk dielakkan, perhatikan bagaimana pemformatan untuk nombor telefon telah dilucutkan dari jadual. Anda harus mengelakkan menyimpan format bidang apabila mungkin. Dalam kes nombor telefon, terdapat beberapa cara orang menulis nombor telefon: 215-555-5858 atau (215) 555-5858. Ini akan membuat mencari orang jualan melalui nombor telefon mereka atau melakukan pencarian orang jualan dalam kod kawasan yang sama lebih sukar.

Kesilapan Pangkalan Data # 4: Tidak Menggunakan Kunci Utama yang Betul

Dalam kebanyakan kes, anda akan mahu menggunakan nombor penambahan secara automatik atau beberapa nombor yang dijana atau alfanumerik untuk kunci utama anda. Anda harus mengelakkan menggunakan maklumat sebenar untuk kunci utama walaupun ia kelihatan seperti ia akan menjadi pengenal yang baik.

Sebagai contoh, kita masing-masing mempunyai nombor keselamatan sosial kita sendiri, jadi dengan menggunakan nombor keselamatan sosial untuk pangkalan data pekerja mungkin terdengar seperti idea yang baik. Tetapi sementara yang jarang berlaku, mungkin juga nombor keselamatan sosial berubah, dan kami tidak mahu kunci utama kami berubah.

Dan itu adalah masalah dengan menggunakan maklumat sebenar sebagai nilai utama. Ia boleh berubah.

Kesilapan Pangkalan Data # 5: Tidak Menggunakan Konvensyen Penamaan

Ini mungkin tidak terdengar seperti masalah besar apabila anda mula membuat pangkalan data anda terlebih dahulu, tetapi sebaik sahaja anda sampai ke titik menulis pertanyaan terhadap pangkalan data untuk mendapatkan maklumat, mempunyai konvensyen penamaan akan membantu anda menghafal nama lapangan.

Bayangkan betapa banyak proses yang lebih sukar jika nama disimpan sebagai FirstName, LastName dalam satu jadual dan first_name, last_name dalam jadual lain.

Kedua-dua konvensyen penamaan yang paling popular memanfaatkan huruf pertama setiap perkataan dalam bidang atau memisahkan kata-kata menggunakan garis bawah. Anda juga mungkin melihat beberapa pemaju memanfaatkan huruf pertama setiap perkataan kecuali perkataan pertama: firstName, lastName.

Anda juga akan memutuskan untuk menggunakan nama jadual tunggal atau nama jadual jamak. Adakah jadual Pesanan atau jadual Pesanan? Adakah jadual Pelanggan atau meja Pelanggan? Sekali lagi, anda tidak mahu terjebak dengan jadual Pesanan dan jadual Pelanggan.

Konvensyen penamaan yang anda pilih tidaklah sama pentingnya dengan proses memilih dan melekat pada suatu konvensyen penamaan.

Kesilapan Pangkalan Data # 6: Pengindeksan Tidak Sihat

Pengindeksan adalah salah satu perkara paling sukar untuk mendapatkan hak, terutama bagi mereka yang baru dalam reka bentuk pangkalan data. Semua kekunci utama dan kunci asing harus diindeks. Ini adalah jadual pautan bersama, jadi tanpa indeks, anda akan melihat prestasi yang sangat lemah daripada pangkalan data anda.

Tetapi apa yang terlalu sering ditinggalkan adalah bidang lain. Ini adalah medan "WHERE". Sekiranya anda sering menyempitkan carian dengan menggunakan medan dalam klausa WHERE, anda ingin berfikir tentang meletakkan indeks di medan itu. Walau bagaimanapun, anda tidak mahu terlalu indeks jadual, yang juga boleh menyakiti prestasi.

Bagaimana untuk membuat keputusan? Ini adalah sebahagian daripada reka bentuk pangkalan data seni. Tiada batasan keras untuk berapa banyak indeks yang perlu anda letakkan di atas meja. Terutamanya, anda mahu indeks mana-mana medan yang sering digunakan dalam klausa WHERE. Baca lebih lanjut mengenai mengindeks pangkalan data anda dengan betul.