EAV - гибридный плохой выбор дизайна базы данных

Ответ 1

Я поддерживаю 10-летнюю систему, у которой есть центральная модель EAV с объектами 10M +, значениями 500M + и сотнями атрибутов. Некоторые соображения дизайна из моего опыта:

Если у вас есть какая-либо бизнес-логика, применимая к определенному атрибуту, то стоит использовать этот атрибут как явный столбец. Атрибуты EAV должны быть действительно универсальными, приложение не должно отличать атрибут A от атрибута B. Если вы находите литеральную ссылку на атрибут EAV в коде, то вероятность того, что он должен быть явным столбцом.

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

• У вас есть соглашения и правила, которые позволяют вам узнать, какая часть вашего приложения читает и изменяет часть данных.
• Используйте представления, чтобы облегчить поиск файлов базы данных с помощью инструментов отладки.
• Создавайте и поддерживайте генераторы тестовых данных, чтобы вы могли легко создавать соответствующие фиктивные данные для тех частей модели, которые вас сейчас не интересуют.
• Используйте строгий контроль версий баз данных. Единственный способ сделать изменения схемы должен быть с помощью инструмента, который отслеживает и применяет сценарии изменений. Postgresql имеет транзакционный DDL, то есть одну функцию убийцы для автоматизации изменений схемы.

Postgresql не очень нравится тощие таблицы. Каждое значение атрибута приводит к 32 байтам служебных данных для хранения данных в дополнение к дополнительной работе по перемещению всех строк для совместного использования данных. Если вы в основном читаете и записываете атрибуты в виде пакета, рассмотрите сериализацию данных в строке каким-либо образом. attr_ids int[], attr_values text[] - один из вариантов, hstore - это другая или какая-то клиентская сторона, например json или protobuf, если вам не нужно касаться каких-либо конкретных данных на стороне базы данных.

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

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

Ответ 2

EAV может быть полезна для некоторых сценариев. Но это немного похоже на "темную сторону". Мощный, гибкий и очень соблазнительный. Но это что-то вроде простого выхода. Простой способ сделать правильный анализ и дизайн.

Я думаю, что "сущность" немного выше общего. Кажется, у вас есть представление о том, что должно быть связано с этим сущностью, например, адресом и контактом. Что делать, если вы решите иметь "Книги" в модели. Будут ли у них также адреса и контакты? Я думаю, вы должны попытаться найти правильные обобщения и сохранить части EAV модели в минимерии. Всякий раз, когда вы обнаруживаете, что хотите показать определенный поднабор атрибутов или проверить наличие ценности или определить поведение, основанное на значении, которое вы действительно должны его моделировать как столбцы.

У вас не будет лучшей возможности для разработки этой системы, чем сейчас. Требования известны с предыдущей версии, а также то, что сработало, а что нет. (Просто не становитесь жертвой Второго эффекта системы)

Ответ 3

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

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

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

Ответ 4

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

Я написал системы EAV для ограниченных приложений, но в качестве общего решения обычно это плохая идея.