Ada lelucon yang kudengar beberapa saat lalu:
T Bagaimana cara menghitung koder BASIC menjadi 10?
A 1,2,3,4,5,6,7,8,9,10
T Bagaimana cara menghitung kode C hingga 10?
A 0,1,2,3,4,5,6,7,8,9
T Bagaimana DBA menghitung sampai 10?
A 0,1, banyak
Kebenaran di balik lelucon ini adalah bahwa sekali Anda memiliki dua (atau lebih) hal yang sama dalam struktur basis data (kolom atau tabel), Anda salah melakukannya.
Skema yang terlihat seperti:
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
Apakah salah karena di mana Anda akan meletakkan nomor telepon ketiga jika seseorang memilikinya?
Hal yang sama berlaku untuk tabel itu sendiri. Hal yang juga buruk adalah memodifikasi skema saat runtime, yang tampaknya diimplikasikan oleh "tabel baru untuk setiap daftar". (Terkait: MVC4: Bagaimana cara membuat model saat dijalankan? )
Dan dengan demikian, solusinya adalah membuat daftar todo yang terdiri dari dua tabel. Ada dua hal yang Anda miliki - daftar dan barang.
Jadi, mari kita buat struktur tabel yang mencerminkan ini:
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
Daftar memiliki id (kunci utama untuk daftar), dan nama. Tugas memiliki id (kunci utama) listid (kunci asing) dan deskripsi tugas. Kunci asing berhubungan kembali dengan kunci utama dari tabel lain.
Saya akan menunjukkan bahwa ini tidak mulai mencakup semua kemungkinan dalam berbagai persyaratan untuk perangkat lunak dan struktur tabel untuk mendukungnya. Selesai, tanggal jatuh tempo, berulang, dll ... ini semua adalah struktur tambahan yang mungkin perlu dipertimbangkan ketika mendesain tabel. Yang mengatakan, jika struktur tabel bukan salah satu yang dinormalisasi dengan tepat (atau menyadari timbal balik yang telah Anda buat karena tidak dinormalisasi), Anda akan mengalami banyak sakit kepala nanti.
Sekarang, semua yang berkaitan dengan penulisan ini sebagai basis data relasional. Tapi itu bukan satu-satunya jenis database di luar sana. Jika Anda menganggap daftar sebagai dokumen, basis data dokumen nosql yang ditata juga dapat menawarkan pendekatan yang tidak salah.
Meskipun saya tidak akan membahasnya terlalu jauh, ada banyak tutorial di luar sana untuk daftar agenda di sofa. Salah satu yang muncul dengan pencarian adalah Aplikasi daftar tugas sederhana di CouchDB . Lain muncul di wiki couchdb: Skema yang Diusulkan Untuk Daftar yang Harus Dilakukan .
Dalam pendekatan yang sesuai untuk sofa, setiap daftar adalah dokumen JSON yang disimpan dalam database. Anda hanya perlu meletakkan daftar di objek JSON, dan memasukkannya ke dalam database. Dan kemudian Anda membaca dari database.
JSON dapat terlihat seperti:
[
{"task":"get milk","who":"Scott","dueDate":"2013-05-19","done":false},
{"task":"get broccoli","who":"Elisabeth","dueDate":"2013-05-21","done":false},
{"task":"get garlic","who":"Trish","dueDate":"2013-05-30","done":false},
{"task":"get eggs","who":"Josh","dueDate":"2013-05-15","done":true}
]
(dari membuat daftar belanja dengan file json di Stack Overflow).
Atau sesuatu yang mendekati itu. Ada beberapa penyimpanan catatan lain yang dimiliki sofa sebagai bagian dari dokumen.
Masalahnya adalah, ini bukan cara yang salah untuk didekati dan daftar todo dalam database dokumen mungkin sangat cocok dengan apa yang Anda coba lakukan dengan overhead konsep yang lebih sedikit untuk bagaimana melakukannya.