LSVВ моей реализации одна таблица, в которой все типы (строка, целое,флоат, дата, булеан).
Можно разнести их по разным таблицам. В другом проекте, где я участвую, именно так. Не суть. Принцип тот же.
Производительность ? Трудно сказать. Возможно, где неск. таблиц будет немного быстрее.
Правильная суть ЕАВ(ИМХО) - для добавления нового параметра создаем новые строки в фиксированных таблицах.
Что такое параметр ? То, что изображено на картинке выше. Не суть как это назвать. Можно атрибутом. :)
Пожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод. А возможно - другой.
Понятно, что в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений. В Варианте 3 никаких проблем с типами нет - каждое поле имеет такой тип,который и нужен для данного свойства. Схема единственного отношения для Варианта 3:
Товар {Свойство1, Свойство2, ..., СвойствоN}

ViPRosLSV,

надо идти дальше - к механизму динамической типизации
ир познается через знания - тавтология типа такая
знания - не объекты, а признаки их классификации
те. важно иметь тезаурус -словарь свойств (объектов) уже отыменных
это как сито через который пропускается ноый объект
объекты с имеющие одинаковые совйства - типизируются по свойству ( тип = набор свойств)
объекты имеющие одинаковое значение одинаковых свойств - классифицируются (класс - все объекты всех типов с одинаковыми значенями типизированных свойств)
при этом свойства и их значения во времени меняются (ДОБАВЛЯЮТСЯ, УНИЧТОЖАЮТСЯ)
не типизированные (тем более не классифицированнные ) свойства объекта лежать в пуле - ждут часа обобщения
это механизм динамической классификации

вот тут все типизированные и тем более классифицированные вещи - это почти регулярны и их можно отобразить в отношения
а вот то что в пуле - в еав

молчать блин!!!
и пользоваться пока добрый
Если Вы предлагаете один из вариантов Варианта 2, пожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод, и у LSV. А возможно - другой.

ViPRosБредятина,
уткнись, ты знаешь какой у меня вариант
Это, к сожалению, не о модели верхнего уровня. А о модели нижнего уровня - вместо РМД. У Вас на нижнем уровне, судя по прошлым Вашим высказываниям, именно РМД. И здесь речь идет о конкретной задаче, а не о системе масштаба предприятия. Если у Вас настолько сложная конструкция из отношений РМД для реализации одного из подвариантов Варианта 2, то так и скажите. И зачем было писать что-то в этой теме, если она Вас не интересует???

LSVБредятинаПожалуйста, приведите схемы всех используемых отношений РМД, иначе непонятно о чем речь, так как все используют разную терминологию. Возможно, у Вас тот же вариант, что и у _мод. А возможно - другой.
Понятно, что в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений. В Варианте 3 никаких проблем с типами нет - каждое поле имеет такой тип,который и нужен для данного свойства. Схема единственного отношения для Варианта 3:
Товар {Свойство1, Свойство2, ..., СвойствоN}Какие схемы ? Какие отношения РМД ?

болдом: Есть единая процедура записи значений атрибутов. Она зачитывает тип атрибута (целое, флоат, строка и т.д.) и пишет в определенное поле (пишет ХП. Никакой SQL-динамики). Можно сначала проверить на допустимость значений и отформатировать введённое.
Не скажу, что это элегантное решение, но оно работает.
Таблица данных выглядит элементарно: ключи (ID атрибута, ID документа, вспомогательные поля) + поля данных всех нужных типов.
Мне казалось. что я написал предельно ясный текст. Я же привел схемы всех отношений для Варианта 3 . В этом варианте одно отношение (таблица):
Товар {Свойство1, Свойство2, ..., СвойствоN}
Понятно, что в Вашем варианте (2.1) в "таблице значений" есть пять полей, и для каждой записи значение находится только в одном из них. Но не пользователь же вручную помещает значение в нужную колонку. Поэтому приведите схемы всех отношений (таблиц). В формате:
Отношение1{атрибут1отношения1, атрибут2отношения1, ...}
Отношение2{атрибут1отношения2, атрибут2отношения2, ...}
...
ОтношениеN{атрибут1отношенияN, атрибут2отношенияN, ...}

LSV,
Это я помню)) Непонятно только зачем было писать)) Что значит нравится или не нравится, если Вы засекретили основу любой БД - ее схему)) Жаль, что не получилось сделать нормальный анализ... Будем и дальше ждать бесконечных тем про EAV..

LSVБредятинаLSV,
Это я помню)) Непонятно только зачем было писать)) Что значит нравится или не нравится, если Вы засекретили основу любой БД - ее схему)) Жаль, что не получилось сделать нормальный анализ... Будем и дальше ждать бесконечных тем про EAV..Какие секреты ? Я рассказал подробностей реализации больше, чем любой мембер в этом топике. :)
Тут нечего прятать.
Табл 1. Справочник атрибутов(три важных поля) : Код, Название, Тип данного (целое/флоат/строка/дата/булеан).
Табл 2. Хранилище данных(упрощенно) : ID Документа, ID атрибута, целое, флоат, строка, дата, булеан.

Все действия (чтение, вставка, правка, удаление) только через ХП.

Какой еще анализ нужен ???
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}

Infernal V. RavenКоллеги, реанимирую старую тему, но не флейма ради.
Не смог найти пост, в котором некто ЧАЛ, Андрей Леонидович или Бредятина декларирует внедрение ООБД на балабановской спичечной фабрике.
Последнее ее упоминание было тут.
Не стоило реанимировать, ради неправды)) Это постоянно декларирует vadiminfo. Я точно знаю, что на этой фабрике работает 1С. Может у нее и ООБД, но к теме это не имеет отношения на мой взгляд.

vadiminfoБредятинаЯ точно знаю, что на этой фабрике работает 1С.

А куда же делась нашлепка на Кашу Информ Икс?

Ну той фирмы:


БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.\


Где Вы работали. Она, эта нашлепка была еще ДОМД или КОМД, которую Вы тут типа толкали с мешочками


И в Сывтывкаре, где помнится Вы таки впарили эту нашлепку, тоже теперь 1С?

А ведь 1С это РМД.
А еще я учился в 317-ой средней школе)) На Вашей любимой фабрике 1С стоит по моей рекомендации)) Даже исследования проводили для выбора. Потому что им не нужна система масштаба предприятия, а нужен именно бухгалтерский учет. Там, где заинтересованы в корпоративной системе, там используют именно СУБД, а не СХОД)) И, как правило, используют в качестве MUMPS вовсе не Cache. И не нужно давать своих оценок про МД - выглядит совсем уж нелепо. В 1С не РМД, и даже не такая архитектура, которую мы рассматривали здесь:
13577413
Вероятно, у Вас не получилось впарить СХОД Oracle на эту Вашу фабрику, и Вы теперь не можете успокоиться? И опять вступаете в диалог с банальным идиотом))

vadiminfoБредятинаЯ точно знаю, что на этой фабрике работает 1С.

А куда же делась нашлепка на Кашу Информ Икс?

Ну той фирмы:


БредятинаЯ, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.\


Где Вы работали. Она, эта нашлепка была еще ДОМД или КОМД, которую Вы тут типа толкали с мешочками


И в Сывтывкаре, где помнится Вы таки впарили эту нашлепку, тоже теперь 1С?

А ведь 1С это РМД.
А теперь по существу:
Я уже привык клещами вытаскивать простую информацию для анализа)) И опять: в первой таблице "Код" во второй "ID атрибута" - приходится догадываться(( Пока имеем.

Вариант 1. Не EAV. Отдельная таблица на каждый подтип Типа сущности "Товар".
Нет описания.

Вариант 2. С использованием EAV (в том числе только EAV).
Вариант 2.1.
Свойство {Код, Название, Тип, ???, ..., ???}
Товар {Код свойства, Целое, Флоат, Строка, Дата. Булеан}

Вариант 2.2.
Нет описания.

Вариант 2.N.
Нет описания.

Вариант 3. Не EAV. Одна таблица.
Товар {Свойство1, Свойство2, ..., СвойствоN}

БредятинаvadiminfoА ведь 1С это РМД.
... И не нужно давать своих оценок про МД - выглядит совсем уж нелепо. В 1С не РМД, и даже не такая архитектура, которую мы рассматривали здесь:
13577413

Для общего представления хотя бы
http://v8.1c.ru/overview/Term_000000641.htm