Cara terbaik untuk memodelkan singleton dalam basis data relasional

12

Ketika merancang skema basis data relasional untuk aplikasi web, saya sering menemukan kasus di mana saya akhirnya membuat tabel hanya berisi satu baris, dan hanya satu baris. Rasanya itu adalah cara yang salah untuk mendesainnya, tetapi saya tidak dapat menemukan sesuatu yang jauh lebih baik, atau itu jelas "cara yang tepat untuk melakukannya."

Contoh terbaru adalah situs yang memungkinkan pengguna mengontrol konten secara manual di beranda. Yah, hanya ada satu halaman rumah. Saya membuat tabel yang memiliki semua bidang yang diperlukan untuk membangun beranda, seperti bidang teks untuk area yang berisi teks deskriptif. Bidang untuk menyimpan nama file gambar besar. Beberapa kunci asing yang menunjuk ke artikel yang akan ditampilkan di beranda, dll. Berhasil, tetapi rasanya salah memiliki meja hanya dengan satu baris.

Di masa lalu saya sudah mencoba banyak desain lain, seperti memungkinkan beberapa baris di tabel beranda dan memilih satu secara acak. Saya sudah mencoba menambahkan bidang boolean bernama "aktif" dan memilih salah satu homepage aktif secara acak. Saya sudah mencoba memaksa hanya satu baris untuk aktif pada waktu tertentu dalam logika aplikasi. Saya sudah mencoba bahkan tidak membuat tabel beranda dan memiliki semua item lainnya, seperti artikel, memiliki bidang boolean dengan nama-nama seperti Featured_on_homepage.

Dalam kebanyakan kasus, saya dapat membangun beranda dengan sekelompok konstanta dalam file pengaturan. Masalah utama dengan file pengaturan adalah bahwa itu di bawah kendali pengembang. Karena sesuatu seperti isi beranda adalah sesuatu yang harus diedit oleh pengguna, itu harus masuk dalam database.

Di banyak situs, saya tidak memiliki masalah ini karena saya dapat membangun hal-hal seperti beranda dengan kueri seperti memilih lima artikel terbaru. Tetapi ketika saya memiliki halaman yang dikuratori secara manual dengan persyaratan yang ketat, menjadi sulit untuk memodelkannya dalam database. Tapi bayangkan Anda punya meja foto dan meja artikel. Syaratnya adalah bahwa beranda akan menampilkan tepat lima foto, tepat tiga artikel, dan dua blok teks sewenang-wenang yang dikontrol secara manual oleh pengguna. Bagaimana Anda memodelkan itu dalam database dengan cara yang benar?

Juga, saya memiliki masalah pemodelan ini dalam banyak kasus lain selain hanya beranda. Itu hanya contoh termudah dan paling umum berlaku yang bisa saya buat.

design-patterns database-development database

— Apreche
sumber

Sama sekali tidak jelas masalah apa yang disajikan tabel baris tunggal kepada Anda, selain itu dalam beberapa hal merupakan pemborosan tabel. Apakah Anda yakin sedang mencoba menyelesaikan masalah yang sebenarnya Anda derita?

— David Aldridge

10

Satu pendekatan sederhana adalah menyimpan properti Halaman Beranda dalam tabel Properti (atau menyebutnya sesuatu yang lain) yang terdiri dari kolom Nama & Nilai.

HomePageProperty1 - UserValue1

HomePageProperty2 - UserValue2

Ini mungkin bukan solusi yang ideal, tetapi sederhana dan fleksibel. Ini juga menghilangkan tabel dengan skenario satu baris.

— Walter
sumber

1

Pendekatan ini berfungsi untuk berbagai tujuan. Misalnya, saya akan menyimpan informasi versi skema, pointer rotasi untuk hal-hal yang perlu didaur ulang setiap hari, dll. Info versi skema penting ketika mendiagnosis apa yang salah. Ini adalah cara yang masuk akal untuk memastikan tambalan diterapkan untuk perbaikan hanya basis data.

— Berin Loritsch

2

+1 - Ini tata letak tabel yang diberikan oleh Arsitek Data kami untuk tujuan serupa.

— Ali

3

Masalah dengan pendekatan ini adalah bahwa Anda harus mewakili tipe variabel yang berbeda sebagai kolom yang berbeda, dan memiliki logika untuk memberi tahu Anda kolom mana yang akan digunakan, dan mana yang wajib. Anda tidak dapat menentukan bahwa nilai boolean adalah boolean, atau bahwa tanggal adalah tanggal, atau bahwa atribut tertentu tidak boleh nol, atau harus berada dalam rentang tertentu atau memenuhi kondisi - semua hal yang sepele sederhana dengan tabel baris tunggal.

— David Aldridge

3

Tidak jelas bagi saya bahwa Anda memiliki masalah yang harus Anda selesaikan.

Tabel baris tunggal sama sekali tidak menjadi masalah bagi database itu sendiri, dan memungkinkan Anda untuk menerapkan tipe data dan kendala ke data.

Saya tidak yakin Anda mencoba memecahkan masalah nyata, jujur saja.

— David Aldridge
sumber

2

Sepertinya saya menggunakan database untuk sesuatu yang sebenarnya harus disimpan sebagai file.

Deskripsi Anda mengingatkan saya pada banyak halaman Wiki, di mana pengguna dapat mengedit konten. Di Wikis, atau setidaknya dalam implementasi yang saya lihat, halaman-halaman tersebut tetap sebagai file.

Ini membantu Anda dengan perincian web lainnya seperti memungkinkan pengguna Anda untuk me-cache halaman rumah Anda, yang praktis praktis gratis jika Anda menyimpan halaman sebagai file, tetapi Anda harus secara manual menerapkan logika untuk pembatalan cache jika Anda sedang membangun halaman pada setiap permintaan berdasarkan konten yang disimpan di database.

Bagaimanapun, saya hanya ingin memperjelas bahwa meskipun sebagian besar data persisten suatu aplikasi disimpan dalam database, itu tidak berarti bahwa kita harus menyimpan semua yang ada di sana. Database hanyalah salah satu alat perdagangan kami. Kita harus belajar memanfaatkan sebanyak mungkin alat yang berbeda.

— MichelHenrich
sumber

2

Sama sekali tidak ada yang salah dengan tabel dengan satu baris.

Jika ini adalah bagian dari desain Anda, Anda harus menegakkannya. Beri tabel kolom identitas, berikan kendala keunikan, lalu tambahkan kendala kolom untuk hanya mengizinkan nilai tunggal. Ini akan memastikan bahwa tidak ada yang akan dapat menambahkan baris kedua, yang bisa menjadi bencana jika pernyataan SQL yang membaca tabel (dimengerti) tidak memiliki klausa where.

Jika Anda mulai mendapatkan sejumlah besar kolom, Anda mungkin tergoda untuk mempersempit tabel dan alih-alih memiliki satu baris per item konfigurasi. Ini bukan ide terbaik karena Anda kehilangan keamanan dan validasi tipe. Selain itu, Anda akan kehilangan kepuasan dengan multitenancy , yang mungkin penting bagi Anda. Solusi yang lebih baik adalah memikirkan kembali apa sebenarnya entitas Anda dan memiliki tabel baris tunggal terpisah untuk entitas yang berbeda.

Ya, saya tidak hanya mengatakan tabel baris tunggal OK, tapi saya sarankan Anda ingin lebih dari satu.

— John Wu
sumber

1

Anda dapat membuat tabel yang disebut STATIC_CONTENT dan memiliki kolom untuk kunci serta konten, pelacak aktif / tidak aktif, dll. Kemudian, buat baris dengan kunci "HomePage" dan di beranda Anda, muat konten statis untuk kunci itu dan tampilkan. Dengan begitu, ketika Anda memiliki konten statis lainnya (tentang halaman, halaman kontak, dll.), Anda dapat menambahkan baris ke tabel itu.

— RasionalGeek
sumber

1

Tidak ada yang salah per se dalam memiliki meja hanya dengan satu baris. Jika Anda hanya memiliki satu contoh entitas tertentu, maka itu mungkin cara yang paling alami untuk mewakili hal ini.

Tetapi memilih satu baris secara acak adalah salah dan buruk. Jika logika domain Anda hanya mengharapkan satu baris, itu jelas merupakan kesalahan dalam data jika sebenarnya ada lebih banyak. Jadi, Anda harus mencari tahu siapa atau apa yang menulis data tidak valid ke database dan mencegah mereka melakukannya! Bergantung pada basis data, Anda mungkin bisa menambahkan batasan pada tabel untuk mencegah hal ini terjadi, misalnya, membiarkan hanya nilai tertentu sebagai kunci utama.

— JacquesB
sumber

0

Hanya untuk menambah ke Walter ..

Struktur tabel properti harus memungkinkan beberapa tipe data.

Fileds:
PropertyName
PropertyTextValue
PropertyDateValue
PropertyNumericValue
PropertyBoolValue

— Orang bodoh
sumber

Dengan ini, bagaimana Anda menjamin bahwa hanya satu nilai properti disetel per baris? Cukup mudah untuk menerapkannya dalam aplikasi, tetapi bagaimana jika seseorang kemudian memperbarui database secara manual dan memasukkan beberapa data ke sana?

— Apreche

0

Menurut saya, Anda bisa mengabstraksi satu tingkat lagi. Pada akhirnya "HomePage" adalah "Halaman". Anda dapat memiliki berbagai jenis halaman dengan properti yang Anda butuhkan. Jika Anda memiliki bagian di situs Anda, Anda mungkin perlu "SectionHomePage", yang dapat berfungsi sama dengan "Halaman Utama".

Syaratnya adalah bahwa beranda akan menampilkan tepat lima foto, tepat tiga artikel, dan dua blok teks sewenang-wenang yang dikontrol secara manual oleh pengguna. Bagaimana Anda memodelkan itu dalam database dengan cara yang benar?

Mari kita coba seperti ini. Saya menambahkan tabel ArticlePage sehingga Anda melihat bagaimana Anda dapat memisahkan properti yang sesuai.

PAGES
Id
Title
Description

HOMEPAGES
PageId (FK)
PhotoListLimit
ArticleListLimit
TextBlockListLimit

ARTICLEPAGE
PageId (FK)
ArticleMainQuote
ArticleMainBody
ArticlePhoto1
ArticlePhoto2

Itu akan bekerja dengan baik untuk saya, bahkan akan bekerja dengan baik untuk situs besar.

— Juan Carlos Eduardo Romaina Ac
sumber