Схема базы данных для списка задач

Я пытаюсь создать очень простое приложение со списком задач с PHP, MySQL, Jquery-шаблонами и JSON ... Однако моя схема усложняет JSON.

Какой лучший способ сделать это?

1. Новая таблица для каждого списка, содержащая элементы.

или

2. таблица для списков и таблица для элементов, которые каким-либо образом объединяются? Потому что я пробовал это, и это не похоже на правильный способ сделать это? Пример http://jsfiddle.net/Lto3xuhe/

Некоторое время назад я услышал шутку:

Q Как BASIC кодер считает до 10?
А 1,2,3,4,5,6,7,8,9,10

Q Как C-кодер считает до 10?
А 0,1,2,3,4,5,6,7,8,9

В Как DBA считается до 10?
А 0,1, много

Истина, стоящая за этой шуткой, состоит в том, что, если у вас есть две (или более) одинаковых вещи в структуре базы данных (столбцы или таблицы), вы делаете это неправильно.

Схема, которая выглядит как:

+----------+
| id       |
| name     |
| phone1   |
| phone2   |
|          |
+----------+

Это неправильно, потому что, где вы положите третий номер телефона, если у кого-то есть?

То же самое относится и к самим таблицам. Плохо также изменять схему во время выполнения, что, по-видимому, подразумевает «новая таблица для каждого списка». (Related: MVC4: Как создать модель во время выполнения? )

И поэтому решение состоит в том, чтобы создать список задач, который состоит из двух таблиц. У вас есть две вещи - списки и элементы.

Итак, давайте создадим структуру таблицы, которая отражает это:

+----------+       +-------------+
| List     |       | Task        |
+----------+       +-------------+
| id (pk)  <---+   | id (pk)     |
| name     |   +---+ listid (fk) |
|          |       | desc        |
|          |       |             |
+----------+       +-------------+

Список имеет идентификатор (первичный ключ для списка) и имя. Задача имеет идентификатор (первичный ключ), listid (внешний ключ) и описание задачи. Внешний ключ относится к первичному ключу другой таблицы.

Я укажу, что это не начинает охватывать все возможности в различных требованиях к программному обеспечению и структуре таблицы для его поддержки. Завершено, срок выполнения, повторение и т. Д. - это все дополнительные структуры, которые, вероятно, необходимо будет учитывать при разработке таблицы. Тем не менее, если структура таблицы не является должным образом нормализованной (или реализующей компромиссы, которые вы сделали, потому что она не нормализована), у вас будет много головной боли позже.

Теперь все, что связано с написанием этого как реляционной базы данных. Но это не единственный тип базы данных. Если вы считаете список документом документ в стиле NoSQL базы данных также может предложить подход , который не так.

Хотя я не буду вдаваться в подробности, есть многочисленные учебники для списков задач на диване. Одним из таких подходов при поиске является простое приложение со списком задач в CouchDB . Еще один виден в вики couchdb: Предлагаемая схема для списков дел .

В подходе, подходящем для кушетки, каждый список представляет собой документ JSON, хранящийся в базе данных. Вы бы просто поместили список в объект JSON и поместили его в базу данных. И тогда вы читаете из базы данных.

JSON может выглядеть так:

[
 {"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}
]

(от создания списка покупок с помощью файла JSON в Stack Overflow).

Или что-то приближающееся к этому. Есть и другие записи, которые хранятся на этом диване как часть документа.

Дело в том, что это не неправильный подход, и список задач в базе данных документов может идеально подходить для того, что вы пытаетесь сделать, с меньшими затратами на концепцию того, как это сделать.

Вариант 2 - это традиционная настройка мастер / детали. Это, вероятно, то, что вы хотите здесь. Поместите идентификатор списка в таблицу предметов и присоединитесь к нему. Схема не должна влиять на JSON. Ваш запрос может выглядеть примерно так:

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

Я бы не пытался связать ваше представление или передачу данных в пользовательский интерфейс напрямую с тем, как вы собираетесь хранить данные. Сохраняя два отдельных и используя некоторую логику промежуточного программного обеспечения для их объединения, вы можете легко изменить любую из сторон, не оказывая критического влияния на другую.

С точки зрения хранения данных, вы, вероятно, будете использовать вариант 2, который следует типичному нормализованному шаблону данных, где общие части выделены в свои собственные таблицы, чтобы избежать повторения и минимизировать разрастание базы данных.

С точки зрения представления вам просто нужно использовать запрос к базе данных, чтобы объединить соответствующие данные в набор результатов, а затем повторить этот результат и сгенерировать ответ json, соответствующий вашим потребностям пользовательского интерфейса. Скорее всего, вы захотите передать данные в JSON так, чтобы они как можно лучше соответствовали потребностям вашего пользовательского интерфейса, часто устраняя необходимость в дополнительной логике сценариев на ваших веб-страницах.