Desain skema & ORM

Jan 05 2023
Basis data apa pun secara luas memiliki 2 jenis tabel — dimensi & fakta: Saat merancang skema basis data, beberapa panduan berikut membantu melakukannya dengan benar. Normal pertama Terlepas dari apakah database akan berupa SQL atau NoSQL, akan berguna untuk memikirkan Entitas / Objek & karenanya tabel sekali dari perspektif skema yang dinormalisasi.

Basis data apa pun memiliki 2 jenis tabel secara luas — dimensi & fakta:

  1. Dimensi adalah tabel konfigurasi. Tabel ini tidak sering diubah, dan biasanya merupakan nilai snapshot tunggal saat ini (mungkin dengan beberapa perubahan riwayat — detailnya di bawah). Operasi yang paling umum adalah mengedit tabel. Seseorang juga dapat menganggap ini sebagai Config atau Masters.
  2. Fakta adalah tabel yang meningkat hampir secara linear dengan waktu. Biasanya entitas ini dihasilkan secara teratur seiring waktu, pembaruan pada fakta yang dihasilkan tidak umum dan biasanya merujuk ke Dimensi untuk konteks lebih lanjut.

Saat mendesain skema database, beberapa panduan berikut membantu melakukannya dengan benar.

Biasa dulu

Terlepas dari apakah database akan berupa SQL atau NoSQL, akan berguna untuk memikirkan Entitas / Objek & karenanya tabel sekali dari perspektif skema yang dinormalisasi. Skema yang dinormalisasi memberikan kejelasan tentang entitas, hubungan, dan bidang. Denormalisasi atau konversi ke NoSQL dari sini bisa langsung & bisa menjadi desain sadar.

Mencerminkan entitas dunia nyata

Bahkan jika kasus/laporan penggunaan tidak jelas, entitas skema harus mencerminkan kasus penggunaan dunia nyata. Skema seperti itu biasanya kuat.

Salah satu dari berikut ini umumnya merupakan kasus untuk mengidentifikasi & membuat entitas yang berbeda & karenanya tabel:

  1. Entitas yang terpisah secara logis yang dapat berdiri sendiri & berpotensi tanpa keterkaitan satu sama lain — misalnya kumpulan data & stasiun
  2. Memiliki hubungan banyak-ke-banyak atau hubungan satu-ke-banyak satu sama lain — misalnya untuk perusahaan e-niaga, pesanan & pelanggan.

Jika ada bidang yang digunakan dalam kueri, penelusuran, atau pengurutan, tambahkan indeks untuk bidang tersebut secara default. Indeks sederhana harus aktif untuk bidang ini secara default karena memiliki manfaat maksimal. Tidak menambahkan indeks harus menjadi pilihan sadar yang diambil, bukan keadaan default.

Gunakan jenis bidang yang tepat

  1. Pencacahan vs jenis string untuk bidang dengan serangkaian nilai opsi yang tetap: Pencacahan diimplementasikan sebagai byte, karenanya mengambil lebih sedikit ruang (mis. byte panjang 1–4 byte/panjang/int vs string 128-byte), lebih cepat / lebih cepat pada indeks & pencarian. Untuk meja besar, persyaratan ruang & kinerja bertambah. Gunakan pencacahan secara default.
  2. Jenis kunci utama (ID): Kinerja & penyimpanan — selalu disarankan untuk menggunakan kunci ukuran tetap — yaitu bilangan bulat atau UUID.
  3. Bidang tabel umum: Beberapa bidang disarankan di semua entitas ORM yang dapat berubah — misalnya dibuat_at, diperbarui_at, dibuat_oleh, diperbarui_oleh. Selain itu, untuk entitas yang mungkin sering memiliki tautan kunci asing & jarang dihapus, disarankan untuk menggunakan penghapusan lunak.

Kueri Drishti bisa rumit, melibatkan banyak gabungan. Basis data dioptimalkan untuk penggabungan & perhitungan dalam memori. Jika memungkinkan, jalankan gabungan atau perhitungan ini di database — baik melalui penambahan ke lapisan ORM, kueri yang tepat, atau desain ulang skema. Sebagai aturan praktis, seseorang harus melihat gabungan hasil yang besar dalam kode aplikasi hanya jika basis data tidak dapat melakukannya di dalam memori — misalnya untuk gabungan lintas basis data.

Kapan menambahkan tabel riwayat?

Setiap sistem berbasis transaksi membutuhkan pencatatan dasar dari semua perubahan untuk entitas kunci. Ini terutama berlaku untuk tabel Dimensi, karena ini dikonfigurasi/dimodifikasi melalui API.

Ada 2 cara di mana mereka dapat dipertahankan:

  1. Pertahankan abstraksi generik untuk perubahan atribut, di mana setiap baris dalam riwayat perubahan ini menunjuk ke tipe entitas, atribut, id entitas, nilai lama & nilai baru. Keuntungan: Tidak memerlukan tabel baru per entitas.
  2. Pertahankan tabel riwayat berdasarkan entitas untuk setiap perubahan nilai. Keuntungan: Tangkap sebagai transaksi atom beberapa perubahan bidang, menunjukkannya seperti itu kepada pelanggan. Dengan demikian, konsep transaksi seperti yang dilakukan oleh pengguna di frontend atau lainnya dipertahankan.