Schemat bazy danych dla listy zadań do wykonania

Usiłuję stworzyć bardzo prostą aplikację listy zadań do wykonania z PHP, MySQL, szablonami Jquery i JSON ... Jednak mój schemat wydaje się komplikować rzeczy w JSON.

Jak najlepiej to zrobić?

1. Nowa tabela dla każdej listy, zawierająca elementy.

lub

2. tabela dla list i tabela dla elementów, które są jakoś połączone? Ponieważ próbowałem tego i nie wydaje się to właściwym sposobem na zrobienie tego? Przykład http://jsfiddle.net/Lto3xuhe/

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ć.

Opcja 2 to tradycyjna konfiguracja master / detail. Prawdopodobnie tego właśnie tutaj chcesz. Umieść identyfikator listy w tabeli przedmiotów i dołącz do tego. Schemat nie powinien mieć wpływu na JSON. Twoje zapytanie może wyglądać mniej więcej tak:

select lists.name as list_name, items.name as item_name 
from items 
join lists on (lists.id = items.list_id)

Nie próbowałbym powiązać twojej reprezentacji interfejsu użytkownika ani transmisji danych z interfejsem użytkownika bezpośrednio z tym, jak zamierzasz przechowywać dane. Utrzymanie dwóch oddzielnych elementów i użycie logiki oprogramowania pośredniego do ich połączenia pozwala na łatwą zmianę jednej ze stron bez wpływu na drugą stronę w krytyczny sposób.

Z punktu widzenia przechowywania danych prawdopodobnie użyłbyś opcji 2, która jest zgodna z typowym znormalizowanym wzorcem danych, w którym wspólne części są pogrupowane w ich własnych tabelach, aby uniknąć powtórzeń i zminimalizować rozdęcie bazy danych.

Z perspektywy widoku wystarczy użyć zapytania do bazy danych, aby połączyć odpowiednie dane w zestaw wyników, a następnie iterować ten wynik i wygenerować odpowiedź JSON odpowiadającą potrzebom interfejsu użytkownika. To, co najprawdopodobniej chcesz zrobić, to wprowadzić dane do JSON, aby najlepiej odpowiadały Twoim potrzebom interfejsu użytkownika, często eliminując potrzebę dodatkowej logiki skryptowej na twoich stronach internetowych.