Лучший образец для моделирования редких атрибутов

Question

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

1. Плотно заполненные столы со сто столбцов.
2. Таблицы значений атрибутов Entity Attribute, где клиент может определять новые столбцы по мере необходимости.

Мы столкнулись с большинством недостатков обоих решений. Множество столбцов обеспечивают нам комфорт, поскольку мы знаем, какие данные мы добавляем в нашу базу данных, но можем заставить нас выглядеть негибкими и дорогими, когда клиент «просто» хочет сохранить новую ценность, например, «Любимый гольф-клуб». EAV показал все свои обычные проблемы: плохо выполняющие запросы, теряя контроль над данными, отсутствие проблем с проверкой и ремонтопригодностью.

Итак, есть ли лучший образец?

Answer 1

Я сделал презентацию по этому вопросу на Percona Live MySQL Conference & Expo 2013. Моя презентация была названа Extensible Data Modeling.

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

Реферат моей презентации. Слайды свободно доступны:

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

Примеры расширяемого Требования к базе данных:

• База данных, которая позволяет пользователям объявлять новые поля по требованию.
• Или каталог электронной коммерции с множеством продуктов, каждый из которых имеет разные атрибуты.
• Или платформа управления контентом, которая поддерживает расширения для пользовательских данных.

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

Я кратко рассмотрим недостатки Entity-Attribute-Value (EAV), проблемного дизайн, который является примером антипаттерн называется Inner-Platform эффект, то есть, моделируя атрибут-менеджмент систему вершина архитектуры РСУБД, которая уже предоставляет атрибуты через столбцы, типы данных и ограничения.

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

• Таблица наследования классов
• Serialized BLOB
• Перевернутый Индексация

Наконец мы покажем такие инструменты, как PT-онлайн-схемы-изменения и новые возможности из MySQL 5.6, которые принимают боль вне модификаций схемы.

Answer 2

Я не думаю, что могу указать вам конкретный образец, но вы, возможно, слышали о PostgreSQL.

Это база данных, которая имеет тенденцию решать множество разнообразных проблем, которые обычно возникают при разработке тяжелых приложений базы данных (т. Е. Можно писать скрипты в CoffeeScript, и вы можете получить доступ к данным через JSON).

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

Answer 3

Я бы это сделал как отдельную таблицу атрибутов, не таблицу с несколькими «настраиваемыми» столбцами ... что происходит, когда у вас 100 столбцов, и они хотят добавить атрибут # 101? Как насчет клиентов с очень небольшим количеством настраиваемых атрибутов? Сто NULL ...

В этом случае ваш тип хранения может быть просто VARCHAR(MAX), потому что вы не выполняете никакой логики на этих столбцах, кроме SELECT и отображаете их. Следствием этого является то, что у вас есть потенциально неэффективное хранилище типов INT или DATE (или любых разнородных типов, которые вы можете захотеть сохранить), но это тот факт, что клиент может хранить что-нибудь в этих настраиваемых полях.

Рассмотрим таблицу, содержащую пять столбцов:

• Id
• ParentType
• ParentId
• CustomValueName
• CustomValue

Так что теперь у вас есть достаточно информации:

1. Отчетливо связать пользовательский атрибут любого другого объекта в вашей БД
2. Имени типов атрибутов для пользовательских агрегатов при необходимости
3. Append любого значения, которое пользователь хочет

Недостатком является то, что это несколько больно запрашивать эти пользовательские атрибуты (хотя это легко можно сделать в SQL, план запроса не будет очень эффективным).