Как спроектировать простую базу данных

С чего начать

Не с таблиц. Сначала выпишите, о чём вообще ваш проект: какие есть сущности и что между ними происходит.

Для сервиса заметок: есть пользователи, есть заметки, у заметок бывают категории. Три сущности — три таблицы.

Правило простое: сущность — это то, о чём вы говорите «одна штука такого-то». Один пользователь, одна заметка, один заказ.

Порядок действий

1. Выпишите сущности. Существительные из описания проекта.

2. Для каждой перечислите признаки. У заметки: заголовок, текст, дата создания. Только то, что нужно сейчас, без запаса на будущее.

3. Определите связи. Между каждой парой сущностей спросите: сколько к скольким.

• Один ко многим. У пользователя много заметок, у заметки один автор. Самый частый случай.
• Многие ко многим. У заметки много меток, у метки много заметок. Нужна отдельная связующая таблица.
• Один к одному. Встречается редко; обычно это признак того, что сущность стоило не разделять.

4. Расставьте ключи. У каждой таблицы свой идентификатор. Связь «один ко многим» делается так: в таблице заметок хранится идентификатор пользователя.

5. Продумайте, что обязательно. Заметка без заголовка допустима? А без автора? Лучше решить это сразу, чем чинить потом.

Правила, которые спасают

Одно значение в одной ячейке. Список меток через запятую в одном поле — классическая ошибка новичка. Потом такое поле невозможно нормально искать и обновлять.

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

Даты создания и изменения. Добавляйте почти всегда: пригодятся при разбирательствах, а добавить потом сложнее.

Не удаляйте, а помечайте. Часто удобнее пометить запись удалённой, чем стирать безвозвратно, — особенно в учебном проекте, где легко случайно снести нужное.

Ошибки, заметные со стороны

• Таблица на сорок колонок. Обычно означает, что в ней смешались две-три сущности.
• Поля с номерами: телефон1, телефон2, телефон3. Нужна отдельная таблица.
• Хранение вычислимого. Если сумму заказа можно посчитать из позиций, обычно не надо хранить её отдельно. Исключение — когда так требуется по делу, например для фиксации цены на момент покупки.
• Отсутствие ограничений. База должна сама не давать создать заметку с несуществующим автором.

Проверка себя

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

Если для простого экрана нужно соединить пять таблиц — схему стоит упростить.

Не усложняйте заранее

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