Приведу пример чтобы было понятнее. Потому что сформулировать тему граммотно не очень получается.

Есть например карточки товаров
Каждая карточка может иметь свой уникальный и не уникальный набор атрибутов

Задача состоит в том чтобы дать возможность пользователю через интерфейс создавать свои карточки (сущности). То есть по сути создавать таблицы

Как это лучше реализовать.
create table выполнять.

Или же

Создать виртуальную бд на базе нескольких.
Например. в одной таблице хранятиться. Список таблиц. В другой список полей. В третий список значений.

Или например создать таблицу универсальную с большим запасом полей анонимных. Вообщем наверное много чего можно придумать.
Наверное у каждого способа есть недостатки и достоинства. Хотелось по этому поводу получить какую нибудь фундаментальную информацию. Повторяю Даже не знаю как охарактеризовать данную тему.
Ну или у кого какой опыт есть по этому поводу тоже буду рад если поделитесь

Хорошо переформулирую.

Задача состоит в том чтобы пользователь через интерфейс мог создавать свои сущности. То что нужны еще механизмы обработки согласен. Скажем так пусть существует механизм (алгоритм) использующий метаинформацию этих сущностей.

Метаинформация сущности это например кол-во полей и их тип. Имя таблицы. Вообщем все что описывает саму сущность. Или возможно она сама себя самоописывает.

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

Ваши насмешки разделяю полностью. Может проще научить пользователя. Реалиционным БД и научить писать скрипты.

Ну все же есть некий тут разумный стержень.
Создать еще один слой абстракции. Такой конструктор который намного более ограничен чем предшествуй инструмент в виде sql и средств администрирования но в тоже время намного проще.
И со своей конкретной задачей справляющийся.
Конкретно задача в примере состоит в том. чтобы.
Создавать Карточки Товара (юзерский язык )
Ну еще конкретнее. Про обработку что с ними потом можно делать.

Вот товар
Утюг
У него есть свойства
Имя, Габариты.

Есть товар
Телевизор
у него есть Имя, Габариты, + Диагональ.

Когда пользователь выбирает посмотреть все телевизоры. Пользователь видит список Телевизоров в каждом элементе списка он видит характеристики и длину диагонали тоже

По этому полю можно сортировать делать поиск. еще что то.

А когда выбирают все Утюги диагонали нет.

Каждый раз гонять программиста создай мне товар например "Телефон " со своими какими то параметрами не очень то канает.

RodionAT,

Решение похоже на.
Создать виртуальную бд на базе нескольких таблиц.

То есть ГруппаТоваров - это список таблиц.
Свойство Товара - список полей.
....
Да вот тут интереснее как это все обрабатывать. Потом. Написать можно но насколько это разумно быстро и прочее.


Я вот склоняюсь к идеи. Создавать все таки таблицы create table и использовать обычный sql . А не писать фиг знает какой механизм обработки. Для этих виртуальных таблиц.

Bely,

Да вот концепция EAV я не знал как это называется правильно. Когда имел в виду виртуальную Бд на основе нескольких таблиц.

Спасибо за часть ответа.

Вот этот EAV мне не нравиться. из за того. что нормальный sql летит к черту. это вообще какой гипертрофированный предельный случай нормализации. вся нормализация затратиталась на эту гипертрофированность и дальше вся нормальная привычная работа с бд летит к черту.

И про большие объемы данных я согласен. что все будет очень плохо. Интернет магазин может быть и не таким уж и маленьким по объему товаров. Также просто у магазина может быть большая посещаемость. Да и потом не обязательно это магазин. Может просто какой -то инфо. каталог.

Плюс косость программирования.

Вот Теперь могу лучше сформулировать.

EAV против create table.
Почему бы не создавать таблицы через ddl.
а потом работать с ними как обычно.

Почему вы рекомендуете EAV?


А про то что утюг не товар это верно подмечено :). Хотя утюг с ценником это уже товар :)

Да вот еще одно решение
Наследование.

Если создать абстрактный товар.


описать там общие свойства.

Абстрактный товар

tovar
id name cost

дальше наследник

custom_tovar
id -
parent_id - ид объекта от которого наследуемся.
diagonal - новый атрибут.


Тоже не знаю как этот подход грамотно называется наверное что то вроде
ООСУБД
мне кажется он более разумным.

proposed amendment,

Для критичных апдейтов придеться писать конверторы данных. Думаю это решаемо.

Еще интересный способ прочел у вас на форуме. Тоже очень интересный.

цитирую

>Все извращения,которые не укладываются в общую модель, хранил бы в поле XML(список с
>двумя полями:наименование,значение).Минимум телодвижений, и пусть себе ни в чем не
>отказывают.


Гибридные БД.
Тоже очень интересное решение.

Есть например товар с набором общих признаков.
Все дополнительные поля. Хранить в неком дополнительном поле в формате XML.

Все эти решения гораздо интереснее чем этот EAV

Но почему то именно его все вспоминают в первую очередь. И тут мне его тоже порекомендовали. Хотя если читать. Другие ветки этго форума про EAV , он далеко не однозначен. Да я и сам как то с ним сталкивался. Он работает безусловно. Но смотриться ужасно. Тех поддержка сложна. Скорость явно будет плохой. Все не прозрачно. Какой то целый движок работы с EAV надо реализовывать. Нужна реализация EAV у меня её просто нет. Самому писать не хочеться. Должен быть стандарт тогда уж. Опять же язык запросов какой то нужен специальный для EAV Фильтры группировки. Все то что есть в обычном sql.
Где это можно узнать?


Если уж мы выбираем EAV который являеться виртуальной копией БД. Тогда почему уж не использовать create table , alter table.
Зачем делать зеркало системы которая уже есть.

В случае гибридных и ОО случаев тут еще можно спорить согласен.

А вот EAV вообще являеться попыткой повторить функционал который итак представляет СУБД. (create table , alter table)
Может я ошибаюсь но мне это так видеться пока что.

proposed amendmentFoxluckА вот EAV вообще являеться попыткой повторить функционал который итак представляет СУБД. (create table , alter table)
Может я ошибаюсь но мне это так видеться пока что.

ИМХО не то, чтобы повторить...

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

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

XML и ОО поддержка осуществляются некоторыми СУБД.

а вот EAV на уровне СУБД осуществлена где нибудь? Кто нибудь слышал об этом. :) Этого не может быть потому что это дублирование того Базового функционала который есть.

Что дает EAV. ? Чего не может дать ddl и dml ?

Я слышал аргументацию что вроде какие то проблемы с безопаснотью. что это плохо когда пользователь создает 200 таблиц и т.п.

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

Сахават Юсифов,

Про динамически скомпоннованые типы не совсем понял.

1000 строк но какого кода. Это явно не бизнес логика. месяц работы.

Тут интересная мысль была что использовать этот механизм только очень осторожно совместно с обычными плоскими таблицами. кажется человек частично и понимает проблемы которые могут возникнуть с EAV.

Я же говорю что EAV абсолютно неуместен в данной задачи.

Ну так что мешает динамично сгенирить ddl и dml.

генерить ddl и dml кажется сложнее чем делать какие insert delete операции над тремя таблицами

Добавил строку в таблице сущностей таблица создана.
Добавил строку в таблице типов Тип создан. Но легкость обманчива. Потом работать с этим очень неудобно. Потом нужны механизмы вывода фильтрации и прочее. все это надо тоже писать. Все это потом еще и очень плохо читаемо. Нужны свои дебаг инструменты создавать наверное будет.

Вообще пример хороший приведен.
кажется все таки этот EAV в некоторых случаях оправдан. Но явно не для этого случая, явно вообще не для СУБД. То есть механизм EAV можно применять но не совместно с обычными СУБД.

КифирчикFoxluck,
по поводу создания по таблице на сущность, ИМХО:
во 1-х, не надо пользователю давать права на create/drop каких либо объктов БД... мало ли что он вам под этим логином и паролем надропает. токо SELECT/INSERT/UPDATE, а ещё лучше только вызов процедур и запросы из вьюх.

во 2-х, ну сделает вам пользователь на каждую "сущность" по таблице.. а если вам надо получить сводную информацию по всем сущностям? будете генерировать динамический запрос в котором селект по всем 200-м таблицам? когда всё всего в нескольких таблицах (фиксированное колличество), ещё и в НФ, возможно заранее составить "нормальные" запросы, то есть над такими данными в дальнейшем проще производить различные манипуляции

а а операцию DELETE не забыли ?

Дело в том что при EAV вся система безопасности летит медным тазом.
Потому что таблицы виртуальные становятся и удалять их можно DELETE том обычным. Drop для этого уже не нужен.

по поводу общей выборки из 200 таблиц интересное замечание.

Но это решаемо поскольку решаемо и на EAV. а EAV это не что иное как копия уже текущей реализации возможностей заложенных в СУБД. ну наверное динамично придется генерить sql запрос. или может какую то денормализацию использовать для ускорения процесса.
можно еще наследование таблиц предложить.

proposed amendment,

Это офтоп. Проблема не в том зачем. Проблема в том как.
Смысл в этом есть. Смыслов много можно найти один из них не знание предметной области программистом. И не знание пользователем sql. Это просто некоторый компромисс. Добавить немного гибкости системе.

Сахават Юсифов

В основном под ПОЛЬЗОВАТЕЛЕМ подразумеваются эксперты описывающие предметную область, так называемые АНАЛИТИКИ(постановщики). Обычным юзерам хватает добавление полей для собственных нужд. Да смотрите вы ISA95, OAGIS и т.д.



Так фактически почти так вопрос и стоит. Что пользователю надо добавлять поля.
Ну чтобы добавить поле приходиться создавать сущность.

Например
Есть товар

Абстрактный товар
имя
размер

Добавляем поле

Телевизор
имя
размер
диагональ

Добавили поле.
Но пришлось создать сущность.

Потому что

Добавляем поле

Телефон
имя
размер
емкость аккумулятор

То есть именно различия в атрибутах и порождает необходимость создавать сущности.

Я и не говорю что пользователь может изменить все абсолютно спроектировать БД через интерфейс внести любой сколь угодно сложный функционал.
Речь о банальных простых модификациях в очень ограниченных рамках.
Аналогия 3д коридорных шутер.
Пользователю(игроку) вроде кажется что он свободен. Однако это иллюзия он может бежать только по определенным коридорам. Производить выстрелы из ограниченного кол-ва оружия
Вот этот корридор и есть пользовательская сущность.

Это пользовательская сущность с заранее заложенном смыслом использования. Свобода действия только в том чтобы выбрать название поля, тип, порядок вывода.

Меня интересуют именно технические аспекты судя по тому что вы не стерли меня в порошок еще я полагаю что возразить вам особо нечем. Хотя могут еще набежать товарищи.


По поводу централизации. Это оффтоп. тема другой передачи.

proposed amendment,


и именно это я имею в виду, когда сомневаюсь в возможности передавать ПОЛЬЗОВАТЕЛЯМ функции РАЗРАБОТЧИКА


Так пользователь даже не понимает что он создает сущности.
Он просто добавляет новый вид товара с новыми уникальными аттрибутами.

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

Сахават Юсифов

Это к вопросу о сложных типах.
Показываете на примере объектов.
То есть сложный тип. Это экземпляр объекта. А использование его это использование ссылки на экземпляр объекта. То есть Foreign key в терминах Рел. БД ?

proposed amendmentFoxluckТак пользователь даже не понимает что он создает сущности.

тьфу - много шума из ничего.

[DROP ALL FROM PRECIDING WHERE UserName = "proposed amendment"]

это назавается ОПИСАТЬ новую "сущность".

сто раз обсуждалось в этом и других форумах

Ничего не понял. Что тебя осенило. Приведи пример такого обсуждения.