Это крайне важный вопрос, т.к. от него зависит вся дальнейшая база. Обязательно побольше тренируйтесь создавать структуры баз данных. Причем вы можете просто в голове или на листке бумаги проектировать различные базы для всего что вас окружает (например, сейчас я еду в поезде – и это может быть учет поездов в компании, автоматизация работы вокзала, мини программа для работы торговли в поездах, работа контроллера в поезде). Получив навык разработки баз данных, вы сможете избежать очень многих проблем, связанных с неверно выбранным решением в самом начале проекта.
Первое, что нужно научиться – это выделять сущности. Возьмем пример с контроллером поезда. Какие здесь есть сущности? Подумайте и напишите…. Я бы выделил следующие:
После выделения сущностей опишите атрибуты этих сущностей, например, для поезда это может быть:
Следующий момент – это установка связей. Можно выделить 3 типа связи:
В нашем случае давайте рассмотрим эти отношения. Допустим мы будем хранить в отдельной таблице сертификаты на поезда (прямо как файлы в базе). Это будет отношение один к одному между Поездами и Сертификатами поездов. Далее Вагон принадлежит Поезду. У Вагона будет поле Поезд ID – как ссылка на поезд, к которому он принадлежит. Это один ко многим (один поезд – много вагонов). Есть Рейсы и есть Поезда. На конкретный Рейс могут быть поставлены разные Поезда. Один Поезд может участвовать в разных Рейсах. Это отношение много ко многим. Будет нужна дополнительная таблица связи – экземпляры рейсов (поезд ID, рейс ID, дата). Мы рассмотрели небольшой пример, в котором по сути затронули все моменты, которые вам нужно знать при проектировании базы. Проделайте то же самое хотя бы для 10 примеров.
Следующий шаг развития в плане проектирования баз данных – это учитывать оптимизацию и нагрузку.
Вот несколько советов, которые помогут сделать вашу базу более готовой к нагрузкам:
Обычно архитектура в веб проектах не определяется – она задается структурой движка, который вы используете.
В нашем случае, если кратко – это DAL, BLL + MVC подход с UI в виде JSON компонентов. Поэтому ваша главная задача – это следовать архитектуре, которая используется на проекте.
Узнайте у старшего разработчика своего проекта что и как надо делать, все условные соглашения по разработке и после этого строго их придерживайтесь.
При проектировании решения сразу учитывайте момент повторного использования.
Если намерены использовать повторно это решение, то сразу делайте как компонент (т.е. учитывайте, что вам надо делать минимально возможную связность с проектом, чтобы это решение можно было перенести в другой подобный проект). При проектировании очень полезно делать макеты- сделайте простой макет, согласуйте с клиентом, расскажите по нему как будет работать функциональность – и вам не придется переделывать что-то на готовом функционале (вернее не нужно будет делать с нуля полностью новое решение, когда заказчик увидит на тестовом сервере, как это работает).
Макет позволяет сблизить технический и бизнес языки. Все говорят в терминах графического интерфейса и это упрощает понимание друг друга. При проектировании обязательно документируйте свое решение. Что оно должно включать:
Этот документ, во-первых, будет использоваться при разработке (т.е. не нужно полагаться на смекалку разработчика, который будет это делать + можно быть уверенным что будет реализовано именно то решение, которое вам нужно). Во-вторых, это может послужить хорошей основой для руководства программиста по системе на этапе эксплуатации.
Далее рассмотрим использование API.