Проектирование базы данных

Это крайне важный вопрос, т.к. от него зависит вся дальнейшая база. Обязательно побольше тренируйтесь создавать структуры баз данных. Причем вы можете просто в голове или на листке бумаги проектировать различные базы для всего что вас окружает (например, сейчас я еду в поезде –  и это может быть учет поездов в компании, автоматизация работы вокзала, мини программа для работы торговли в поездах, работа контроллера в поезде). Получив навык разработки баз данных, вы сможете избежать очень многих проблем, связанных с неверно выбранным решением в самом начале проекта.

Выделяем сущности

Первое, что нужно научиться – это выделять сущности. Возьмем пример с контроллером поезда. Какие здесь есть сущности? Подумайте и напишите…. Я бы выделил следующие:

  • Поезда
  • Вагоны
  • Места
  • Пассажиры
  • Билеты
  • Рейсы.

После выделения сущностей опишите атрибуты этих сущностей, например, для поезда это может быть:

  • Номер,
  • Марка
  • Количество вагонов (или состав вагонов)
  • Компания

Установка связей

Следующий момент – это установка связей. Можно выделить 3 типа связи:

  • Один к одному
  • Один ко многим
  • Много ко многим (создается дополнительная таблица связи).

В нашем случае давайте рассмотрим эти отношения. Допустим мы будем хранить в отдельной таблице сертификаты на поезда (прямо как файлы в базе). Это будет отношение один к одному между Поездами и Сертификатами поездов. Далее Вагон принадлежит Поезду. У Вагона будет поле Поезд ID – как ссылка на поезд, к которому он принадлежит. Это один ко многим (один поезд – много вагонов).  Есть Рейсы и есть Поезда. На конкретный Рейс могут быть поставлены разные Поезда. Один Поезд может участвовать в разных Рейсах. Это отношение много ко многим. Будет нужна дополнительная таблица связи – экземпляры рейсов (поезд ID, рейс ID, дата). Мы рассмотрели небольшой пример, в котором по сути затронули все моменты, которые вам нужно знать при проектировании базы. Проделайте то же самое хотя бы для 10 примеров.

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

Вот несколько советов, которые помогут сделать вашу базу более готовой к нагрузкам:

  • Большие поля отдельно. Если у вас хранятся в базе статьи – то возможно лучше сам текст статьи хранить в отдельной таблице (отношение один к одному). Это уменьшит размер таблицы и упростит поиск по ней.
  • Индексы. Используйте индексы для всех полей, по которым будет идти поиск или фильтрация (но помните, что индекс увеличивает размер базы).
  • Минимально нужный тип данных. Не ставьте всем строковым полям nvarchar(max). Ставьте то размер, который будет адекватен для данного поля.
  • Ставьте внешние ключи. Это ускоряет поиск и обеспечивает целостность базы (т.е. позволит избежать битых ссылок).
  • Закладывайте возможные изменения при проектировании. Например, предлагает вам внедрить какой-то статус (например деталь продана). Первое что напрашивается – это сделать поле типа bit – isSold, Но, возможно, в дальнейшем появятся дополнительные статусы и может быть необходимо использовать поле statusID как внешний ключ на таблицу статусов. Потом переделать это на новый лад будет гораздо сложнее, поэтому учитывайте эти вопросы лучше сразу.
  • Здесь также как в обычном кодировании вы можете создавать для себя типовые решения. Например, статусы всегда имеют название, код и цвет. Вы можете заранее проработать решения для типовых задач. Здесь я укажу пару возможных областей, а вы для них придумайте свои решения и применяйте их от проекта к проекту. Вот они:
    • Категории неограниченной вложенности для любых сущностей.
    • Права доступа ролей или пользователей к какой-либо функции.
    • Статусы для различных сущностей
    • Хранение файлов для сущностей
    • Логирование различных операций
    • Настройки системы

Архитектура и проектирование

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

В нашем случае, если кратко – это DAL, BLL + MVC подход с UI в виде JSON компонентов. Поэтому ваша главная задача – это следовать архитектуре, которая используется на проекте.

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

Проектирование

При проектировании решения сразу учитывайте момент повторного использования.

Если намерены использовать повторно это решение, то сразу делайте как компонент (т.е. учитывайте, что вам надо делать минимально возможную связность с проектом, чтобы это решение можно было перенести в другой подобный проект). При проектировании очень полезно делать макеты- сделайте простой макет, согласуйте с клиентом, расскажите по нему как будет работать функциональность – и вам не придется переделывать что-то на готовом функционале (вернее не нужно будет делать с нуля полностью новое решение, когда заказчик увидит на тестовом сервере, как это работает).

Макет позволяет сблизить технический и бизнес языки. Все говорят в терминах графического интерфейса и это упрощает понимание друг друга. При проектировании обязательно документируйте свое решение. Что оно должно включать:

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

Этот документ, во-первых, будет использоваться при разработке (т.е. не нужно полагаться на смекалку разработчика, который будет это делать + можно быть уверенным что будет реализовано именно то решение, которое вам нужно). Во-вторых, это может послужить хорошей основой для руководства программиста по системе на этапе эксплуатации.

Далее рассмотрим использование API.