Запросы EAV имеют свойства увеличиваться от сложности задачи гораздо быстрее, чем обычные реляционные.
Вот аналог с применением xml:
select *
from objects C
where ((xpath('/Изделие/Наименование/text()', O.body))[1]::text::int in ('Чайник', 'Самовар')
and ((xpath('/Изделие/Цвет/text()', O.body))[1]::text::int in ('Желтый', 'Поносный')
and ((xpath('/Изделие/Цена/text()', O.body))[1]::text::int between 100.0 and 200.0;
Создание таблицы в РСУБД это дорогое действие, и совершать его при каждом неосторожном действии пользователя, по любому поводу — думаю не самое лучшее решение (хотя такой вариант я тоже рассматривал).
Так же при малейшем изменении структуры таблицы(таблиц) придется изменять все пользовательские таблицы, потеряется необходимая гибкость.
Проблемы начнутся, когда нужно будет организовать поиск не по всем товарам, а только по конкретным, например среди всех чайников и самоваров и когда сложность запроса немного увеличится. Тогда в ход пойдут айдишники (т.к. в боле менее сложный запрос достаточно накладно все время приджойнивать таблицы с названиями классов и типами параметров (в Вашем случае categories)), а для удобства можно будет держать в голове, что 493832 — это силикатный кипич, а 2345638 — детское питание.
Так же такую структуру сложно проиндексировать, частенько приходится делать мат представления для того или иного конкретного участка (в тех базах где они есть конечно), но от этого беспорядок только увеличивается.
О решаемой задаче в кратце.
Сущности (за исключением системных) создаются полностью пользователем (через пользовательский интерфейс), т.е. ядро системы ничего не знает (и не может знать) о них. Далее пользователь должен иметь возможность работать со своими сущностями, выбирать данные из них (выборки могут быть любой сложности, любой степени вложенности и т.д.). Для этого используется QBE, который автоматически преобразуется к обычному sql-запросу, так же остается возможность (для продвинутых пользователей) составлять запросы самостоятельно (для сложных, нетривиальных выборок) на стандартном, хорошо известном многим языке SQL.
При этом пользователь в любом случае (даже при ручном написании запросов) работает со своими логическими объектами, тонкости технической реализации (насколько это возможно) остаются для него скрытыми (чего не скажешь о EAV).
Согласен со всеми пунктами. Однако целью моей статьи было показать один из возможных вариантов решения популярной проблемы, саму идею, и небольшой пример использования. Вопрос об использовании данного способа для какой либо конкретной задачи остается открытым, никакой пропаганды нет. Однако для своей задачи я (пока) остановился именно на нем. Описание ее (задачи) целью статьи не являлось, но, если это будет интересно, могу описать ее и причины выбора данного подхода.
Эмоции присутствуют, не скрываю, праздники все таки…
На sql проще, само собой, но только когда заранее известна структура данных и заранее можно определить и продумать запросы к ней. Я же описывал ситуацию обратную, когда структура заранее не определена и периодически изменяется.
«Пока не встречал таких проблем. Да и не думаю, что в этом действительно есть какая-то проблема.»
Думаю ве зависит от приложения и от того как и какую БД оно использует.
Если база используется в качестве простого хранилища (порой разработчики даже не используют встроенную в БД поддержку ссылочной целостности, обосновывая это выйгрышем в производительности), то само собой и париться не надо.
Так же существуют БД-ориентированные приложения, где большинство логики реализовано именно на стороне базы, которые по максимуму используют возможности своей СУБД.
«Структура БД в модели» — это конечно удобно, нарисовал, выгрузил, накатил, но есть вопрос: например описание оператора CREATE TABLE в документации Oracle занимает несколько листов (это только операторы, без комментариев), наврядли какой либо визуальный инструмент предоставит функционал, позволяющий воспользоваться всеми возможностями. Т.о. получится пользоваться только той частью функционала, к которой приспособлен инструмент (IDE, генератор, моделер и т.д.)
«Аналогия БД с исходным кодом на java или другим языком — неверная.» — может не верно выразился, я проводит аналогию в плане отношения разработчиков к исходному коду БД, для многих его как будто и не существует.
Использовать генератор форм и прочие визуальные фичи (в java например) часто считается дурным тоном (программист сам должен следить за своим кодом), а вот в БД пожалуйста — понажимали на кнопки в любимой IDE, выгрузили полученные скрипты и готово.
Согласен, стили разные, IDE разные — гавная идея статьи была в том, чтобы работать именно с кодом БД. Разные визуализаторы, генераторы альтеров это здорово, но использовать их стоит только как вспомогательные средства, а не как основной инструмент для разработки, не задумываясь что вообще творится с кодом.
Вот аналог с применением xml:
Так же при малейшем изменении структуры таблицы(таблиц) придется изменять все пользовательские таблицы, потеряется необходимая гибкость.
Так же такую структуру сложно проиндексировать, частенько приходится делать мат представления для того или иного конкретного участка (в тех базах где они есть конечно), но от этого беспорядок только увеличивается.
Сущности (за исключением системных) создаются полностью пользователем (через пользовательский интерфейс), т.е. ядро системы ничего не знает (и не может знать) о них. Далее пользователь должен иметь возможность работать со своими сущностями, выбирать данные из них (выборки могут быть любой сложности, любой степени вложенности и т.д.). Для этого используется QBE, который автоматически преобразуется к обычному sql-запросу, так же остается возможность (для продвинутых пользователей) составлять запросы самостоятельно (для сложных, нетривиальных выборок) на стандартном, хорошо известном многим языке SQL.
При этом пользователь в любом случае (даже при ручном написании запросов) работает со своими логическими объектами, тонкости технической реализации (насколько это возможно) остаются для него скрытыми (чего не скажешь о EAV).
На sql проще, само собой, но только когда заранее известна структура данных и заранее можно определить и продумать запросы к ней. Я же описывал ситуацию обратную, когда структура заранее не определена и периодически изменяется.
Доверять код (серьезной большой) базы визуалке это дело последнее, ну а если у вас 5 таблиц на мускуле, то пожалуйста
Думаю ве зависит от приложения и от того как и какую БД оно использует.
Если база используется в качестве простого хранилища (порой разработчики даже не используют встроенную в БД поддержку ссылочной целостности, обосновывая это выйгрышем в производительности), то само собой и париться не надо.
Так же существуют БД-ориентированные приложения, где большинство логики реализовано именно на стороне базы, которые по максимуму используют возможности своей СУБД.
Использовать генератор форм и прочие визуальные фичи (в java например) часто считается дурным тоном (программист сам должен следить за своим кодом), а вот в БД пожалуйста — понажимали на кнопки в любимой IDE, выгрузили полученные скрипты и готово.