it-swarm.asia

Apakah akan membuat tabel terpisah atau tidak untuk berbagai jenis produk?

Saya sedang dalam proses merancang database dan saya memiliki pemikiran kedua tentang keputusan desain awal saya ...

Jenis produk adalah sebagai berikut ... Model, suku cadang, kit dan opsi suku cadang.

Opsi A (desain pertama): Saya berencana memiliki tabel terpisah untuk jenis produk di atas. Saya akan mengatakan sekitar 75% dari bidang akan sama di setiap tabel.

Saya membuat setiap jenis produk sebagai tabel terpisah karena asosiasi yang saya perlu buat di antara mereka. Misalnya, Model dapat memiliki banyak opsi dan opsi dapat memiliki banyak model. Opsi juga dapat memiliki banyak bagian dan sebagian dapat memiliki banyak opsi ... dan seterusnya ...

Opsi B: Alih-alih memiliki tabel terpisah, saya dapat membuat tabel yang disebut Produk yang mencakup model, komponen, kit pengganti, dan opsi. Saya dapat memiliki satu jenis bidang yang disebut untuk membedakan antara model, opsi, dll. Saya kira sisi bawah adalah beberapa bidang tidak akan pernah digunakan (nol kiri) untuk jenis produk tertentu. Saya menduga ini adalah di mana "bukan praktik terbaik" akan ikut bermain ..

Opsi B akan sangat mengurangi kompleksitas desain db. Saya juga tidak perlu khawatir tentang referensi banyak tabel ketika mengeluarkan data untuk permintaan ...

25
payling

Jika ini adalah keputusan desain saya, saya mungkin akan memilih 'Opsi C' yang lebih banyak (opsi yang dimodifikasi a).

Pertama, mengapa tidak 'Opsi B':

Untuk satu hal, saya suka kejelasan bahwa setiap produk memiliki tabel sendiri. Jika itu semua adalah satu tabel besar dengan bidang untuk menentukan jenisnya, hubungannya tidak jelas.

Untuk yang lain, strategi pengindeksan akan selalu mengharuskan bidang jenis itu didaftar. Karena hanya 4 jenis, kardinalitas indeks sangat rendah (SELECT * FROM product_table WHERE type='X' pada dasarnya melakukan pemindaian tabel penuh)

Opsi C

  • Buat tabel induk yang hanya memegang kolom yang berbagi semua jenis
  • Buat setiap jenis produk sebagai tabel tersendiri dengan kolomnya masing-masing, dengan satu tambahan: Tautan ke tabel induk
  • Buat setiap tabel 'tautan': Product_Option, Model_option, dll dengan tautan ke masing-masing kunci.
  • Bagi mereka yang memiliki tautan timbal balik (MODEL_OPTION, OPTION_MODEL) lanjutkan dan buat tabel itu juga. Ini akan menambah kejelasan dalam gabungan Anda untuk siapa pun yang melihatnya.

The downside adalah kompleksitas memastikan untuk menghindari anak yatim ketika hal-hal diperbarui/dihapus, dan awalnya merancang pertanyaan yang menggunakan tabel ini.

8
Derek Downey

Saya sarankan Anda mulai dengan model relasional yang "benar", opsi Anda A. Jika penggunaan tipikal dari model itu mengarahkan Anda untuk melakukan denormalisasi di beberapa area, jangan takut untuk melakukannya.

Saya sedang berdiskusi dengan seorang kolega minggu lalu bagaimana desain skema sering dianggap sebagai sesuatu yang dibuat mati-matian dan tidak pernah bisa berubah. Aneh, mengingat bagaimana refactoring dalam praktik yang diterima di setiap lapisan aplikasi, bahwa refactoring skema database masih dipandang tidak praktis.

Jika antarmuka ke database dirancang dengan baik, tidak ada yang menghentikan Anda dari mengadaptasi skema saat Anda mempelajari lebih lanjut tentang pola penggunaan sistem.

7

Ini terdengar sangat mirip dengan Bills of material/multiple kardinalities heirarcy yang dijelaskan Paul Neilsen di Bab 17 of SQL Server 2008 Bible .

Seluruh bab adalah bacaan yang sangat baik dan bagian spesifik yang membahas masalah banyak-ke-banyak Anda dapat ditemukan di halaman 416-419.

Ini adalah diskusi terbaik yang saya lihat mengenai bagian yang meledak jenis desain data.

Jika Anda dapat membayangkan skenario yang mungkin terjadi di mana akan sering terjadi kueri yang melintasi keempat jenis produk (dan itu tampaknya bagi saya), maka pilihan B Anda adalah yang terbaik.

Alih-alih meninggalkan banyak bidang nullable yang tidak terpakai dalam tabel Produk, mengapa tidak menambahkan tabel ModelProduct, tabel PartProduct, tabel ReplacementPartKitProduct, dan hanya memiliki bidang yang berbeda untuk jenis-jenis dalam tabel tersebut? Gunakan kunci utama yang sama pada tabel tersebut sebagai tabel Produk Anda. Bergabunglah dengan tabel Product and ModelProduct ketika Anda ingin bekerja dengan Model. Perlu menentukan apakah catatan Produk yang Anda miliki adalah Bagian? Lakukan saja gabungan kiri dari Produk ke PartProduct, dan jika PartProduct. [PrimaryKey] bukan nol, Anda memiliki Bagian. Jika itu nol, itu bukan Bagian. Sebagai alternatif, Anda bisa menambahkan bidang ProductType ke tabel Produk.

0
Alan McBee