MySQL: banyak tabel atau satu tabel dengan banyak kolom?

Jadi ini lebih merupakan pertanyaan desain.

Saya memiliki satu kunci utama (katakanlah ID pengguna), dan saya memiliki banyak informasi yang terkait dengan pengguna itu.

Haruskah saya memiliki beberapa tabel yang dipecah menjadi kategori sesuai dengan informasi, atau haruskah saya hanya memiliki satu tabel dengan banyak kolom?

Cara yang biasa saya lakukan adalah memiliki banyak tabel, jadi katakanlah, satu tabel untuk data penggunaan aplikasi, satu tabel untuk info profil, satu tabel untuk token back end, dll. Agar semuanya tetap teratur.

Baru-baru ini seseorang mengatakan kepada saya bahwa lebih baik tidak melakukannya seperti itu dan memiliki tabel dengan banyak kolom tidak masalah. Masalahnya, semua kolom itu memiliki kunci utama yang sama.

Saya cukup baru dalam desain database jadi pendekatan mana yang lebih baik dan apa pro dan kontra?

Apa cara konvensional melakukannya?

Setiap informasi waktu adalah satu-ke-satu (setiap pengguna memiliki satu nama dan kata sandi), maka mungkin lebih baik untuk memiliki satu tabel, karena mengurangi jumlah gabungan yang perlu dilakukan database untuk mengambil hasil. Saya pikir beberapa database memiliki batasan pada jumlah kolom per tabel, tetapi saya tidak akan mengkhawatirkannya dalam kasus normal, dan Anda selalu dapat membaginya nanti jika perlu.

Jika datanya satu-ke-banyak (setiap pengguna memiliki ribuan baris info penggunaan), maka itu harus dipecah menjadi tabel terpisah untuk mengurangi data duplikat (data duplikat menghabiskan ruang penyimpanan, ruang cache, dan membuat database lebih sulit untuk dipelihara ).

Anda mungkin menemukan artikel Wikipedia tentang normalisasi database menarik, karena membahas alasannya secara mendalam:

Normalisasi database adalah proses pengorganisasian kolom dan tabel database relasional untuk meminimalkan redundansi dan ketergantungan. Normalisasi biasanya melibatkan pembagian tabel besar menjadi tabel yang lebih kecil (dan tidak terlalu berlebihan) dan menentukan hubungan di antara mereka. Tujuannya adalah untuk mengisolasi data sehingga penambahan, penghapusan, dan modifikasi bidang dapat dilakukan hanya dalam satu tabel dan kemudian disebarkan ke seluruh database melalui hubungan yang ditentukan.

Denormalisasi juga merupakan sesuatu yang harus diperhatikan, karena ada kasus di mana pengulangan data lebih baik (karena mengurangi jumlah pekerjaan yang perlu dilakukan database saat membaca data). Saya sangat menyarankan untuk membuat data Anda senormal mungkin untuk memulai, dan hanya melakukan denormalisasi jika Anda mengetahui masalah kinerja dalam kueri tertentu.

Satu meja besar seringkali merupakan pilihan yang buruk. Tabel terkait adalah apa yang database relasional dirancang untuk digunakan. Jika Anda mengindeks dengan benar dan tahu cara menulis kueri yang berkinerja baik, mereka akan bekerja dengan baik.

Saat tabel mendapatkan terlalu banyak kolom, Anda dapat mengalami masalah dengan ukuran sebenarnya dari halaman tempat database menyimpan informasi. Entah rekaman bisa menjadi terlalu besar untuk halaman, di mana Anda mungkin akhirnya tidak bisa membuat atau memperbarui rekaman tertentu yang membuat pengguna tidak senang atau Anda mungkin (di SQL Server setidaknya) dibiarkan meluap untuk tertentu datatypes (dengan sekumpulan aturan yang perlu Anda cari jika Anda melakukan ini) tetapi jika banyak rekaman akan melebihi ukuran halaman, Anda dapat membuat masalah kinerja yang parah. Sekarang bagaimana MYSQL menangani halaman dan apakah Anda memiliki masalah ketika ukuran halaman potensial menjadi terlalu besar adalah sesuatu yang harus Anda cari di dokumentasi untuk database itu.

Saya punya contoh yang bagus. Database yang terlalu dinormalisasi dengan kumpulan hubungan berikut ini:

people -> rel_p2staff -> staff

dan

people -> rel_p2prosp -> prospects

Jika orang memiliki nama dan detail orang, staf hanya memiliki detail catatan staf, prospek hanya memiliki detail prospek, dan tabel rel adalah tabel hubungan dengan kunci asing dari orang yang menautkan ke staf dan prospek.

Desain semacam ini berlaku untuk seluruh database.

Sekarang untuk membuat kueri kumpulan relasi ini, itu adalah penggabungan multi-tabel setiap waktu, terkadang 8 tabel dan lebih bergabung. Ini telah berfungsi dengan baik hingga pertengahan tahun ini, ketika mulai menjadi sangat lambat sekarang setelah kami melewati 40000 catatan orang.

Pengindeksan dan semua buah gantung rendah telah digunakan tahun lalu, semua kueri dioptimalkan untuk kesempurnaan. Ini adalah akhir dari jalan untuk desain normalisasi tertentu dan manajemen sekarang menyetujui pembangunan kembali seluruh aplikasi yang bergantung padanya serta restrukturisasi database, selama jangka waktu 6 bulan. $$$$ Aduh.

Solusinya adalah memiliki hubungan langsung untuk people -> staffdanpeople -> prospect

Menemukan ini, dan sebagai seseorang yang dulu sering menggunakan MySQL, dan kemudian beralih ke Postgres baru-baru ini, salah satu keuntungan besarnya adalah Anda dapat menambahkan objek JSON ke bidang di Postgres.

Jadi jika Anda berada dalam situasi ini, Anda tidak harus memutuskan antara satu tabel besar dengan banyak kolom dan membaginya, tetapi Anda dapat menggabungkan kolom menjadi objek JSON untuk menguranginya, misalnya alamat menjadi 5 kolom, itu bisa saja jadilah satu. Anda juga dapat melakukan kueri pada objek itu.

tanyakan pada diri Anda pertanyaan-pertanyaan ini jika Anda meletakkan semuanya dalam satu tabel, apakah Anda akan memiliki beberapa baris untuk pengguna itu? Jika Anda harus memperbarui pengguna, apakah Anda ingin menyimpan jejak audit? Bisakah pengguna memiliki lebih dari satu contoh elemen data? (seperti nomor telepon misalnya) akankah Anda memiliki kasus di mana Anda mungkin ingin menambahkan elemen atau serangkaian elemen nanti? jika Anda menjawab ya maka kemungkinan besar Anda ingin memiliki tabel anak dengan hubungan kunci asing.

Kelebihan tabel induk / anak adalah integritas data, kinerja melalui indeks (ya, Anda juga dapat melakukannya pada tabel datar) dan IMO lebih mudah dipelihara jika Anda perlu menambahkan bidang nanti, terutama jika itu akan menjadi bidang yang diperlukan.

Desain kontra lebih sulit, kueri menjadi sedikit lebih kompleks

Tetapi, ada banyak kasus di mana satu meja datar besar akan sesuai sehingga Anda harus melihat situasi Anda untuk memutuskan.

Saya sudah selesai melakukan semacam desain database. bagi saya, itu tergantung pada kesulitan sistem dengan manajemen database; ya memang benar memiliki data unik di satu tempat saja tetapi sangat sulit untuk membuat kueri dengan database yang terlalu dinormalisasi dengan banyak catatan. Cukup gabungkan dua skema; gunakan satu tabel besar jika Anda merasa akan memiliki catatan besar yang sulit dipertahankan seperti facebook, gmail, dll. dan menggunakan tabel yang berbeda untuk satu set record untuk sistem yang sederhana ... nah ini hanya pendapat saya .. saya harap ini bisa membantu .. lakukan saja .. Anda bisa melakukannya ... :)

Cara konvensional untuk melakukan ini adalah dengan menggunakan tabel yang berbeda seperti pada skema bintang atau skema kepingan salju. Namun, saya akan mendasarkan strategi ini menjadi dua kali lipat. Saya percaya pada teori bahwa data seharusnya hanya ada di satu tempat, karena skema yang saya sebutkan akan berfungsi dengan baik. Namun, saya juga percaya bahwa untuk mesin pelaporan dan suite BI, pendekatan kolumnar akan sangat bermanfaat karena lebih mendukung kebutuhan pelaporan. Pendekatan kolom seperti yang ada di infobright.org memiliki peningkatan kinerja dan kompresi yang sangat besar yang menjadikan penggunaan kedua pendekatan ini sangat berguna. Banyak perusahaan mulai menyadari bahwa hanya memiliki satu arsitektur database dalam organisasi tidak mendukung seluruh kebutuhan mereka. Banyak perusahaan yang menerapkan kedua konsep memiliki lebih dari satu arsitektur database.

Saya pikir memiliki satu tabel lebih efektif tetapi Anda harus memastikan bahwa tabel diatur sedemikian rupa sehingga menunjukkan hubungan, tren serta perbedaan variabel dari baris yang sama. misalnya jika tabel menunjukkan usia dan nilai siswa, Anda harus menyusun tabel sedemikian rupa sehingga terima kasih skor tertinggi dapat dibedakan dengan baik dengan skor terendah dan perbedaan usia siswa genap.