В предыдущей серии этого сериала:
Автор постарался описать EAV модель опираясь на официальные источники информации. Привёл примеры преимуществ и недостатков, постарался их объяснить.
Своим языком
В прошлой статье я привёл пример отражения общего случая EAV модели, который позволяет хранить все сведения о сущности в виде нескольких таблиц с разделением способов хранения значения значений атрибутов как в разных полях, так и в разных таблицах. Выберем случай, в котором хранятся характеристики в разных полях с доработаем его, добавив разделение сущностей по типу через поле entities.type(INTEGER, NOT NULL) для идентификации описываемой сущности:
С помощью такой структуры можно описать в трёх таблицах любую сущность с любым набором характеристик, а сами сущности разделяются по типам.
Добавив поле entities.type в котором будет хранится тип сущности, на первых порах будем использовать magicNumbers (так же, как и в атрибутах). Для описания этой сущности пока будем использовать магическое число (entities.type = 1). После добавления данных таблицы будут выглядеть так:
Таким образом, каждая известная нам характеристика отражена и сохранена в СУБД. Получить всех характеристики сущности можно следующим образом:
Результат выполнения скрипта будет выглядеть следующим образом:
Однако, такая структура таблиц позволяет хранить характеристики не только нескольких экземпляров уже созданной сущности, но и других сущностей, не связанных с первой. Добавим к этим данным описание другой сущности установив, что для неё будем использовать entities.type = 2. После добавления таблицы будут выглядеть так:
Причём добавление описания новой сущности не привело к необходимости создавать новые таблицы, либо добавлять новые поля в имеющиеся. Добавлены только новые атрибуты, для описания новых характеристик. Имеющиеся атрибуты (Наименование сущности, Основное действие, Параллельное действие) так же использовались по возможности. Скрипт выбора характеристик по идентификатору так же изменился, но только потому, что атрибуты изменились и порядок их вывода.
Тем не менее, выбрав при отражении неправильную сущность мы нарушили правило, которое ранее не озвучивалось, но подразумевается - сущность должна описываться по возможности в единственном числе. Исправим это:
Скрипт так же необходимо модифицировать
Внесение изменений в характеристики этой сущности не вызвало никаких проблем ни при изменении значений имеющихся атрибутов, ни при добавлении новых. Добавив новый атрибут мы уточнили сущность, исходя из возникших в результате неправильной оценки дополнительных требований. Так же исправили скрипт, дополнив его новым поле "Минимальное количество", чтобы обозначить, что у описываемой сущности для взаимодействия должна быть ещё одна такая же. Наличие же второй сущности пока проверять не будем на уровне СУБД, отнесём это к уровню клиентского ПО.
Таким образом, я постарался подтвердить на практике преимущества, описанные в предыдущей статье, а именно:
- При правильном подходе к отражению сущностей в модели EAV можно хранить любой набор характеристик любой сущности, при условии, что к моменту использования этой модели ошибок в постановке задачи и составлении технического задания допущено не будет. Но даже если эти ошибки попадут в первую редакцию - из исправление не принесёт дополнительной серьёзной нагрузки на разработчиков
- Нам удалось сохранить разные характеристики разных сущностей в одной структуре таблиц без внесения изменений в эту структуру.
- Добавление новой характеристики не привело к изменению структуры таблиц. Изменился только запрос, который отвечает за выдачу сведений на уровень выше.
Предыдущая статья | Следующая статья