Схема базы данных EAV

Question

У меня есть БД с более чем 100K записей. Много категорий и много предметов (с разными свойствами в каждой категории) Все хранится в EAV.

Если я попытаюсь сломать эту схему и создать для любой категории уникальную таблицу это то, что мне придется избегать?

Да, я знаю, что, вероятно, у меня будет много таблиц, и мне нужно их изменить если я хочу добавить дополнительное поле, НО это так неправильно?

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

Есть предложения?

Answer 1

Будучи основной структурой в структуре базы данных, структура будет разрушаться по мере роста данных. Вы знаете, что схема базы данных не соответствует бизнес-модели, когда вам нужно запросить ее для отчетности. Для получения разумных отчетов EAV требуется много обходных путей и не встроенная функциональность базы данных. То есть вы постоянно создаете кросс-таблицы / сводные запросы даже для самого маленького запроса. Вся эта обработка, чтобы взять EAV и поместить его в запрашиваемый формат, переживает циклы ЦП и очень подвержена ошибкам. Кроме того, размер данных растет геометрически. Если у вас есть 10 атрибутов, 10 строк в стандартном дизайне сгенерируют 100 строк EAV. 100 стандартных строк будут соответствовать 1000 EAV-строкам и так далее.

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

Можно создать гибридное решение, в котором структура EAV составляет часть решения. Однако должно быть правило, что вы никогда не можете включить запрос [AttributeCol] = 'Attribute'. Т.е. вы никогда не сможете фильтровать, сортировать, ограничивать диапазон по любому атрибуту. Вы не можете поместить определенный атрибут в любом месте отчета или на экране. Это просто блок данных. В сочетании с хорошей схемой для остальной части системы может быть полезен EAV, в котором хранится большой объем данных. Ключ к выполнению этой работы - это принуждение между вами и разработчиками никогда не пересекать черту фильтрации или сортировки по атрибуту. Как только вы пойдете по темному пути, он навсегда возглавит вашу судьбу.

Answer 2

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

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

Answer 3

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

Я провел первый тест, построив иерархию для системы в одной таблице. Thats отлично справились с примерно 4 проектами, 25 продуктами и 4-5 инструментами, каждый из которых выделен через целые числа уровня, которые ссылаются на их первичные ключи.

Я записывал ресурсы, которые проходят через систему, и это означало FLV-файлы, SWF, JPG, PNG, GIF, PDF, MP3 и т. Д. И все особенности mime-типа, касающиеся их. Это колеблется от 4 до 10 атрибутов в каждом файле. Он насчитывал до 8 миллионов записей «данных об активах», где у нас около 800 тыс. Активов. У меня была просьба поместить всю эту информацию в столбцы для отчета. Оператор SQL должен сам выполнить несколько табличных объединений, не говоря уже о том факте, что они хотят знать, в каком содержимом он использовался, в каком продукте, или в каком-либо проекте он просто убивает JOIN.

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

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

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

Специальное примечание: я обнаружил, что эта система была на RedHat, и она была 32-битной. Большая часть потоков обработки PHP не могла работать на более чем 1 ядре ЦП, а на сервере было еще 7 ядер, которые простаивали! Запросы, выполнение которых на этой машине занимало до 45 минут, фактически могли выполняться за 14-25 секунд в правильно настроенной 64-битной системе. Также пища для размышлений при рассмотрении производительности.

Answer 4

Схема EAV DB очень гибкая для добавления большего количества «столбцов» реляционной базы данных, но за счет снижения производительности запросов и потери бизнес-логики, которая хранилась в схеме реляционной базы данных.

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

Это основано на моем опыте.