Apakah perlu membuat database dengan tabel sesedikit mungkin

52

Haruskah kita membuat struktur database dengan jumlah minimum tabel?

Haruskah itu dirancang sedemikian rupa sehingga semuanya tetap di satu tempat atau tidak apa-apa untuk memiliki lebih banyak meja?

Apakah hal itu akan memengaruhi apa pun?

Saya mengajukan pertanyaan ini karena seorang teman saya memodifikasi beberapa struktur basis data di mediaWiki. Pada akhirnya, alih-alih 20 meja, dia hanya menggunakan 8 meja, dan butuh 8 bulan untuk melakukan itu (itu adalah tugas kuliahnya).

SUNTING

Saya menyimpulkan jawabannya sebagai: ukuran tabel TIDAK masalah, sampai kasusnya luar biasa; dalam hal ini denasionalisasi dapat membantu.

Terima kasih untuk semua orang atas jawabannya.

database  database-design 
— Shaheer
sumber
15
Jumlah minimum tabel itu mudah, hanya membuat serial keseluruhan untuk master_table (table_name, col_name, col_type, row_id, value).
— Inca
apa? saya tidak mengerti
— Shaheer
12
Karena setiap bidang dalam database ditentukan oleh kombinasi nama tabel, nama kolom, kunci utama dan nilai, Anda selalu dapat mengurangi jumlah tabel dengan melakukan denormalisasi menjadi satu tabel yang menyimpan hal itu. Tidak terlalu bermanfaat, tetapi sepenuhnya mungkin.
— Inca
nah saya minta demi mengetahuinya, dan jika ada sesuatu yang kurang bermanfaat dari yang sudah ada, kenapa repot-repot mengubahnya? maksud saya apakah akan memberikan perbaikan dalam hal apa pun? kinerja misalnya?
— Shaheer
1
@ Hamza: Ini mungkin memberikan peningkatan kinerja. Itu benar-benar tergantung pada keadaan spesifik. Tidak ada hampir cukup informasi di sini untuk kita untuk memberikan jawaban konkret.
— FrustratedWithFormsDesigner

Jawaban:

155

Berikan jumlah tabel yang lebih besar. Lebih khawatir tentang mendapatkan desain yang benar. Jika perhatian utama Anda adalah jumlah tabel, Anda mungkin tidak boleh merancang sistem basis data.

Jika teman Anda hanya membutuhkan 8 tabel, dan sistem berfungsi dengan baik, maka 8 adalah angka yang benar, dan 12 sisanya mungkin tidak diperlukan untuk apa pun yang ia lakukan.

Kemungkinan pengecualian mungkin adalah lingkungan khusus yang memiliki batasan keras pada nomor tabel, tapi saya tidak bisa memikirkan contoh konkret sistem seperti itu di luar kepala saya.

— FrustratedWithFormsDesigner
sumber
107
+1:If your major concern is quantity of tables, you should probably not be designing database systems.
— Joel Etherton
9
Konsekuensi: Tabel database tidak memakan banyak ruang. Ini adalah data yang membutuhkan ruang. Normalisasi = lebih banyak tabel = lebih sedikit pengulangan = lebih sedikit ruang yang digunakan. Dengan mencoba meminimalkan jumlah tabel Anda tidak hanya mengganggu desain, Anda benar-benar membuang - buang ruang . "Golf meja" ini sangat buruk di sekitarnya, kecuali beberapa tabel benar-benar berlebihan.
— Aaronaught
1
+1, meskipun saya tidak berpikir kita cukup tahu untuk mengatakan bahwa angka yang benar adalah 8 dalam kasusnya, karena kita tidak dapat membandingkan skema (aslinya mungkin berdiri lebih baik untuk volume transaksi yang lebih tinggi daripada aplikasi saat ini, untuk contoh)
— Adam Robinson
2
@ Hamza: Ok, jadi dia mungkin memiliki keterampilan PHP yang baik dan keterampilan database yang baik, dan proyek itu mungkin membutuhkan keduanya - tetapi jangan membuat asumsi bahwa memiliki satu secara otomatis menyiratkan yang lain. Banyak pengembang mungkin memiliki satu keterampilan tetapi tidak yang lain.
— FrustratedWithFormsDesigner
4
@ Tom Anderson - Maka Anda seharusnya tidak merancang sistem basis data.
— Joel Etherton
17

Tabel database harus mematuhi Prinsip Tanggung Jawab Tunggal, seperti halnya kelas. Setiap tabel harus berurusan dengan tidak lebih dari satu kelompok data terkait untuk memulai. Selain kinerja, ini membuat seluruh binatang lebih mudah untuk dikelola, karena tabelnya sendiri akan lebih kecil. Ini memberi Anda kinerja yang lebih baik juga, karena tabel yang lebih kecil lebih cepat untuk mencari dan bergabung.

Jangan khawatir tentang jumlah tabel lebih dari yang Anda khawatirkan tentang jumlah kelas - jangan khawatir sama sekali. Fokus pada membuat kode yang baik, bersih, dapat dibaca, bukan pada seberapa banyak ruang yang dibutuhkan. Refactor secara agresif begitu Anda memiliki produk yang berfungsi untuk membuatnya lebih baik - dan maksud saya database juga! Anda akan melihat kolom yang seharusnya ada di tabel lain, atau tidak diperlukan, dll. Profil untuk melihat permintaan apa yang paling lama dan mengapa, dan mengatasi masalah tersebut jika itu benar-benar masalah.

— Michael K.
sumber
4
Dalam model data yang dinormalisasi ya ini adalah pendekatan terbaik, namun jika database dimaksudkan untuk melaporkan atau terutama membaca akses maka denormalized "rata" tabel akan berkinerja lebih baik pada set data yang besar. Sejumlah kecil tabel dalam hal ini akan menghasilkan lebih sedikit gabungan dan kinerja yang lebih baik.
— maple_shaft
2
@maple Sepenuhnya setuju. Anda harus profil untuk menentukan set data apa yang perlu dikelompokkan, jadi IMO Anda harus mulai dinormalisasi. YMMV, para ahli mungkin dapat melakukannya dari atas kepala mereka :) Jeff memiliki posting tentang denormalisasi yang mungkin menarik bagi Anda juga.
— Michael K
1
Pos yang bagus dan berhasil, saya telah membaca yang ini sebelumnya! Terkadang Anda dapat memanfaatkan yang terbaik dari kedua dunia. Jika pelaporan tidak perlu 100% waktu nyata maka pertahankan dua skema, satu skema utama adalah skema normalisasi transaksional untuk penggunaan aplikasi, dan lainnya skema denormalized yang dialirkan secara teratur dan dirancang untuk melaporkan akses data.
— maple_shaft
1
Informasi lebih lanjut pada subjek dengan penjelasan Star Schema: publib.boulder.ibm.com/infocenter/rbhelp/v6r3/...
— maple_shaft
1
@maple_shaft, saya setuju bahwa pelaporan basis data sering didenominasikan untuk kinerja, tetapi mereka bukan sesuatu yang saya harapkan akan diterima oleh siswa atau programmer junior. Saya tahu saya pasti tidak akan membiarkan gudang data saya ditangani oleh siapa pun yang tidak memiliki keahlian yang telah terbukti.
— HLGEM
7

Database produksi untuk aplikasi bisnis mungkin berisi ratusan atau bahkan ribuan tabel. Anda memerlukan jumlah tabel yang Anda butuhkan untuk persyaratan bisnis. Mencoba mengurangi jumlah tabel hanya demi memiliki lebih sedikit tabel biasanya akan menghasilkan database yang lebih sulit untuk ditanyakan, memiliki masalah integritas data dan jauh lebih sulit untuk dikelola daripada database yang dinormalisasi.

Ada saat-saat ketika denasionalisasi dibutuhkan. Ini seharusnya hanya dilakukan oleh seseorang yang tahu persis apa yang dia lakukan dan mengapa. Sangat mudah untuk membersihkan denominasi sehingga hanya boleh dilakukan oleh spesialis basis data atau pengembang aplikasi senior dengan pengalaman bertahun-tahun dalam basis data. Orang yang tidak berpengalaman harus berusaha untuk, setidaknya, mencapai bentuk normal ketiga (kecuali jika Anda melakukan pergudangan data yang merupakan area yang saya tidak akan mempertimbangkan untuk mempekerjakan orang yang tidak berpengalaman) dalam database apa pun yang ia desain.

Ketika orang mengatakan mengurangi tabel karena gabungan itu mahal, mereka umumnya bodoh atau memiliki database yang dirancang dengan buruk yang tidak memiliki indeks kritis atau menggunakan kunci alami mulit-kolom besar. Database relasional dirancang untuk menggunakan bergabung dan bergabung bisa sangat efisien jika FK diindeks dengan benar dan mereka menggunakan bidang kecil untuk bergabung (bilangan bulat paling efisien). Anda akan perhatikan bahwa bisnis besar yang memiliki basis data berukuran terrabyte entah bagaimana berhasil mendapatkan kinerja yang sangat baik dan menggunakan gabungan.

Tidak ada perancang basis data yang serius yang pernah mencoba mengurangi jumlah tabel hanya karena mereka menginginkan lebih sedikit tabel. Anda mengurangi jumlah tabel karena data tidak lagi diperlukan atau Anda memiliki masalah kinerja yang tidak dapat Anda selesaikan dengan cara lain (dan ada banyak cara untuk mencoba sebelum mengambil risiko yang luas untuk data Anda mendenormalkan sebuah tabel) .

— HLGEM
sumber
Google merancang BigTable dan dengan sengaja mengecualikan sambungan karena tidak dapat diparalelkan.
— Lie Ryan
2
@Lie Ryan, BigTable adalah kasus khusus yang TIDAK sesuai untuk sebagian besar aplikasi bisnis karena integritas data bukan masalah besar. Google tidak memerlukan banyak aturan bisnis yang rumit untuk pencarian. Saya berani bertaruh aplikasi keuangan perusahaan mereka tidak menggunakan BigTable. Meskipun demikian, sebagian besar aplikasi bisnis yang memiliki basis data besar dapat, pada kenyataannya, menggunakan gabungan dan berkinerja baik jika perancang memiliki pengetahuan. Basis data perusahaan memiliki banyak cara untuk meningkatkan kinerja (termasuk mempartisi) dan dengan demikian tidak perlu kehilangan fitur integritas data dari basis data relasional.
— HLGEM
+1 untuk Anda, @HLGEM, baik untuk jawaban maupun komentar; sungguh memalukan melihat banyak pengembang yang melompat ke kereta dokumen database karena mereka berpikir "bergabung = lambat", hanya untuk pergi dan mencoba memecahkan masalah relasional yang dipecahkan oleh database relasional 20 tahun yang lalu.
— Adam Robinson
5

Karena setiap bidang dalam database ditentukan oleh kombinasi nama tabel, nama kolom, kunci utama dan nilai, Anda selalu dapat mengurangi jumlah tabel dengan melakukan denormalisasi menjadi satu tabel yang menyimpan hal itu. Tidak terlalu bermanfaat, tetapi sepenuhnya mungkin.

Tabel adalah lapisan abstrak yang membantu dengan masalah berurusan dengan data. Itu sebabnya mereka diciptakan. Saya membuat lelucon tetapi memahami bahwa Anda dapat mengurangi setiap set data ke satu tabel master segera menunjukkan mengapa Anda tidak boleh: karena tabel membawa Anda sesuatu. Pada level konseptual, mereka memberi Anda struktur yang lebih mudah dipahami manusia daripada data serial. Pada tingkat peralihan mereka membawa konsep normalisasi: untuk menghindari penyimpanan data yang berlebihan dan memberikan satu titik untuk perubahan, daripada mengubah sesuatu di beberapa tempat. Pada tingkat teknis, basis data membawa sebagian besar hal yang ingin Anda lakukan dengan data, banyak alat, dan mengimplementasikannya dan mengujinya lebih dari yang mungkin Anda akan lakukan sendiri. Pikirkan tipe data, nilai default, hak pengguna, indeks, batasan kunci asing dll. Ini telah diuji, digunakan oleh banyak orang, dioptimalkan, debugged. (Tidak ke dalam kesempurnaan, tapi tetap saja.)

Karena database adalah alat, yang utama adalah memutuskan bagaimana menggunakan alat tersebut. Jumlah tabel tidak penting. Meminimalkan selalu dimungkinkan tetapi dengan biaya membuang manfaat. (Jika Anda membaca lebih banyak tentang normalisasi, Anda akan menjumpai beberapa kasus untuk melakukan denormalisasi - tetapi meskipun demikian itu semua adalah tentang keputusan yang tepat dan bukan hanya secara buta mengurangi jumlah tabel.)

— Inca
sumber
terima kasih, sekarang sudah sangat jelas !, dan saya telah membaca tentang normalisasi btw, saya melakukannya bahkan dalam basis data cakePHP, yang mendorong pendekatan lain dan agak berbeda.
— Shaheer
3

Anda harus menggunakan hak jumlah meja. Anda bisa secara teori puas dengan tabel tabel tunggal dengan mendenormalisasi seluruh database, tetapi database tidak dapat digunakan. Temanmu kedengarannya dia terlalu banyak waktu.

— Neil Butterworth
sumber
2

Memiliki jumlah minimum tabel menurut saya sebagai tujuan yang sangat aneh.

Tentu saja mengurangi skema dari 20 tabel menjadi 8 mungkin merupakan hal yang baik (jika dilakukan dengan baik itu dapat mengurangi bergabung dan meningkatkan kinerja, menghapus kolom yang tidak digunakan dan sebagainya) tetapi itu juga bisa membuat lebih sulit untuk memahami dan meningkatkan ke depan.

Untuk memikirkannya dengan cara lain menurut Anda normalisasi adalah hal yang baik? Normalisasi biasanya mengarah ke sejumlah besar tabel tetapi juga mengarah pada solusi yang lebih dapat dipertahankan, mengurangi duplikasi data dan manajemen data yang lebih mudah.

Tentu saja itu juga dapat menyebabkan kinerja lebih lambat (dengan asumsi database dinormalisasi dirancang dengan baik).

Pada akhirnya Anda perlu berpikir tentang apa persyaratan Anda di area ini, tetapi sebagai posisi awal default, saya akan mengatakan untuk tingkat normalisasi yang masuk akal dan kemudian melihat apakah itu menyebabkan masalah spesifik di mana lebih sedikit tabel mungkin menjadi solusi.

— Jon Hopkins
sumber
0

Angka tidak penting. Desain adalah. Lihatlah beberapa sistem di luar sana. Magento, PHPBB, dll. Mereka memiliki lusinan tabel dalam sistem mereka dan berfungsi dengan baik.

— Ryan Street
sumber
0

Seiring dengan kekhawatiran untuk normalisasi dan kinerja, Anda dapat menggunakan "yang akan membutuhkan tabel lain" sebagai cara untuk mengelola ruang lingkup aplikasi. Fitur itu akan membutuhkan tabel baru dan semua waktu, energi dan upaya untuk merancang, membangun, menguji, mengelola dalam peningkatan, dan semua pengkodean lain yang terlibat. Menambahkan 5 bidang ke tabel yang ada (jika perlu) jauh lebih mudah daripada tabel 5 kolom.

— JeffO
sumber
0

Jika Anda mendesain database dengan mencoba meminimalkan pembuatan tabel, maka Anda akan segera melihat kesulitan mendadak dan kesalahan dalam cara Anda.

Jumlah tabel tidak boleh berada di garis depan pikiran Anda saat membuat desain basis data. Tempatkan barang-barang di mana mereka harus pergi secara logis dan relasional.

0

Saya pikir jumlah tabel penting dan dapat memiliki dampak besar pada kinerja jika Anda memilih untuk membagi data yang seharusnya, untuk semua maksud dan tujuan bisnis, tetap bersama, menjadi beberapa tabel (yaitu sehingga Anda akan memiliki database yang dinormalisasi). Biasanya ketika Anda melakukan ini, Anda akan dipaksa untuk BERGABUNG Operasi (atau setara non-SQL) untuk mendapatkan semua data yang Anda butuhkan dan untuk tabel cukup besar yang terstruktur seperti ini, kinerja rawa turun cepat.

Saya tidak akan masuk ke rincian, tapi saya pikir fakta yang sangat nyata bahwa jumlah tabel dapat mempengaruhi kinerja adalah salah satu alasan mengapa tidak ada database SQL seperti Cassandra, Mongo, dan Google BigTable (sic!) Telah ditemukan, dan itu juga mengapa mereka mendorong de-normalisasi data (dan akibatnya menghindari sejumlah besar tabel / koleksi, dll).

Hal yang sama dapat dikatakan untuk server pencarian seperti Solr Apache yang tidak benar-benar mendorong atau dengan mudah memfasilitasi pemisahan dokumen Anda menjadi beberapa "tabel" atau "jenis entri" yang mendorong Anda alih-alih memiliki skema "satu mencakup semua" yang memiliki bidang yang sama untuk semua jenis dokumen yang ingin Anda indeks (dan akibatnya menghindari harus melakukan operasi seperti BERGABUNG).

Saya tidak mengatakan bahwa fakta sederhana memiliki x tabel dalam skema tentu akan membuatnya lebih lambat daripada skema dengan x / 2 tabel sepanjang waktu, tetapi ada konteks tertentu di mana ia dapat menyebabkan perlambatan karena konsekuensinya operasi tambahan diperlukan untuk mengumpulkan data di semua tabel tersebut. Melanjutkan ini, saya juga tidak berpikir bahwa boleh saja mengatakan "sejumlah tabel dan normalisasi data yang ekstrem tidak berdampak apa pun terhadap kinerja".

— Shivan Dragon
sumber
0

Paman Bob berpendapat bahwa More is Simpler.

Lihat http://c2.com/cgi/wiki?FearOfAddingTables

"desain yang bagus umumnya disederhanakan dengan menambahkan tabel"

Saya percaya bahwa hampir semua entitas banyak-ke-banyak, yang membutuhkan lebih banyak tabel.

Buat tabel negara dengan kode benua di dalamnya. Oh, Anda tidak bisa karena sebenarnya ada 8 negara lintas benua. Sama dengan mata uang. Panama menggunakan dua.

— Neil McGuigan
sumber
-2

Maka jawabannya adalah YA.

Tapi tergantung apa arti sebenarnya dari jumlah tabel "minimum".

Misalnya (anti-contoh).

Jika saya memiliki objek berikutnya

  1. pengguna
  2. pelanggan

dan keduanya memiliki status (bidang) yang sama dan tidak ada batasan keamanan, cara ini lebih cocok untuk melakukan satu tabel

  1. table_persons

agak dua tabel yang berbeda

  1. table_users
  2. table_customers

kontra adalah daripada di table_persons kita perlu menambahkan bidang baru (type_of_person).

Kesalahan lain (kesalahan jika tidak benar-benar perlu dilakukan) adalah "membagi" tabel, dibaca sebagai: pisahkan satu tabel menjadi dua.

  1. table_persons

dalam dua tabel

  1. table_info_persons
  2. table_extra_info_persons

karena Anda memaksa beberapa permintaan untuk bergabung dengan dua tabel dan itu buruk.

— magallanes
sumber
hei jawaban Anda sangat deskriptif dan membantu, terima kasih
— Shaheer
2
Ini memberi saya kilas balik ke aplikasi perusahaan pertama saya dan database di belakangnya dan berapa banyak mimpi buruk DBA membuatnya menjadi tabel nazi pada hal-hal seperti ini. Saya benar-benar tidak akan pernah menyatukan pelanggan dan pengguna yang sama sekali berbeda entitas bisnis.
-1: Pengguna dan pelanggan memiliki bidang yang berbeda; Jika tidak pada saat ini, mereka akan memiliki suatu saat di masa depan. Jadi mereka pantas menerima tabel terpisah.
— Sjoerd
1
@ Soerd, @ Chris: Meskipun itu sering terjadi, itu belum tentu benar. Hal-hal seperti itu tergantung pada aplikasi. Yang sedang berkata, saya setuju dengan sentimen. Terlalu sering pengembang basis data akan melihat "nama bidang umum" berarti ini adalah data yang sama. Ini menjadi sangat mudah dilakukan ketika Anda melihat database dari ORM terlebih dahulu (dengan kata lain, mundur). Sementara konsep OO dapat dimodelkan dalam database, database adalah baris dan hubungan, bukan objek .
— Adam Robinson
1
+1 untuk "database adalah baris dan relasi, bukan objek", saya akan menambahkannya ke kutipan favorit saya!
— Shaheer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.