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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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