Od pewnego czasu słyszałem żart:
P W jaki sposób koder BASIC liczy się do 10? 1,2,3,4,5,6,7,8,9,10
P W jaki sposób koder C liczy się do 10? 0,1,2,3,4,5,6,7,8,9
P Jak DBA liczy się do 10? 0,1, wiele
Prawda kryjąca się za tym żartem jest taka, że gdy masz już dwie (lub więcej) te same rzeczy w strukturze bazy danych (kolumny lub tabele), robisz to źle.
Schemat, który wygląda następująco:
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
Czy jest źle, ponieważ gdzie umieścisz trzeci numer telefonu, jeśli ktoś go ma?
To samo dotyczy samych tabel. Błędem jest również modyfikowanie schematu w czasie wykonywania, co sugeruje „nowa tabela dla każdej listy”. (Powiązane: MVC4: Jak utworzyć model w czasie wykonywania? )
Dlatego rozwiązaniem jest utworzenie listy rzeczy do zrobienia, która składa się z dwóch tabel. Masz dwie rzeczy - listy i przedmioty.
Stwórzmy strukturę tabeli, która odzwierciedla to:
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
Lista ma identyfikator (klucz podstawowy dla listy) i nazwę. Zadanie ma identyfikator (klucz podstawowy), listid (klucz obcy) i opis zadania. Klucz obcy odnosi się z powrotem do klucza podstawowego innej tabeli.
Zwrócę uwagę, że nie zaczyna to obejmować wszystkich możliwości w różnych wymaganiach dotyczących oprogramowania i struktury tabeli do jego obsługi. Ukończone, termin, powtarzanie itp. To wszystkie dodatkowe struktury, które prawdopodobnie należy wziąć pod uwagę przy projektowaniu tabeli. To powiedziawszy, jeśli struktura tabeli nie jest taką, która jest odpowiednio znormalizowana (lub realizuje kompromisy, które dokonałeś, ponieważ nie jest znormalizowana), później będziesz miał wiele problemów.
Wszystko, co dotyczy pisania tego jako relacyjnej bazy danych. Ale to nie jedyny rodzaj bazy danych. Jeśli uważasz listę za dokument, bazy danych nosql w stylu dokumentu mogą również oferować podejście, które nie jest złe.
Chociaż nie zamierzam zagłębiać się w to zbyt daleko, istnieje wiele samouczków dla list rzeczy do zrobienia na kanapie. Jednym z takich, który wymyślił wyszukiwanie, jest prosta aplikacja listy zadań w CouchDB . Kolejna pojawia się na wiki couchdb: Proponowany schemat list zadań do wykonania .
W podejściu odpowiednim dla kanapy każda lista jest dokumentem JSON przechowywanym w bazie danych. Wystarczy umieścić listę w obiekcie JSON i umieścić ją w bazie danych. A potem czytasz z bazy danych.
JSON mógłby wyglądać następująco:
[
{"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}
]
(od utworzenia listy zakupów z plikiem json w Stack Overflow).
Lub coś zbliżającego się do tego. Istnieje inna dokumentacja prowadząca tę kanapę jako część dokumentu.
Chodzi o to, że nie jest to zły sposób podejścia, a lista rzeczy do zrobienia w bazie danych dokumentów może idealnie pasować do tego, co próbujesz zrobić przy mniejszym narzutu koncepcyjnym, jak to zrobić.