[quot vadiminfo]Т.е. не Вы писали:
БредятинаОчевидно, что это никому неизвестно.

Я. И это факт, который Вы подтвердили.
Вот мое сообщение:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoА теперь, когда стало ясно, что широко известно, пытаетесь забалтывать? Дешевый прием.
Полезная самокритика)) Но, Вы же всегда пользуетесь такими приемами. В надежде на то, что здесь всем на все наплевать, и никто не станет делать запрос в google)) А я сделал и написал:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoА существенно только то, что Дейт считает "реляционные системы" СУБД.
Будьте внимательнее, и говорите по существу. Я полностью согласен с Дейтом в части интерактивного интерфейса. И подчеркиваю, что в "реляционных системах" возможны только такие задачи для интерактивного интерфейса, о которых и пишет Дейт. Из-за неустранимых недостатков РМД. Так что, "реляционная система" в принципе не может быть СУБД. Но, Дейт, как и Вы, может называть такие системы СУБД. Как и продавцы компрессоров, имеют право называть их холодильниками. Но, в отличие от Вас с Дейтом, не называют))
vadiminfoЖаль, что нет ф-ии на форуме объявлять повторы троллингом, и удалять все сообщения автора за них. Это все таки слишком выходит за рамки для технических форумов.
Да, это было бы здорово для Вас)) Ведь Вы ушли даже от такого тривиального вопроса о "Фамилии". Другие участники довольно подробно обсуждают этот вопрос, и даже подсчитывают количество строк, которое нужно написать, чтобы пользователь мог бы добавить свойство "Фамилия" к типу сущности "Человек". Правда один явно говорит о разработке СУБД в среде РСХОД, для которой модель верхнего уровня осталась неизвестной, а на нижнем уровне предлагается использовать EAV. А другой говорит, что ему не составляет никакого труда реализовывать и модель верхнего уровня и EAV каждый раз в приложении. А Вы вот только о моей глупости говорите, а не об обсуждаемой проблеме.
Именно, постоянно выходите за рамки технических форумов.

Arhat109Да "и я могу"... в т.ч. и на вашем любимом Мумпс.
У меня нет ничего любимого. Моя цель - максимально объективно подходить к любому вопросу.
Arhat109Но давайте, каждый сделает ТОТ пример, за который ратует. Считаете лучше - предложите пример, потестим. ЗА ВАС никто и ничего делать не будет.
Я "ратую" за все три варианта (одного и того же примера) . Это же очевидно.
Arhat109Не хотите делать - не отвечайте далее, как и просил ранее. Не надо флудить мне в ответ.
Так Вы-то зачем флудите мне в ответ???
Arhat109("внезапно" нет ни того ни другого... подозреваю, что никогда! и не было, поскольку в моем понимании, вы - "чистый теоретик" не написавший ни разу ни одной строчки кода)
Почему это "внезапно"?)) Здесь все знают, что я не написал ни одной строчки кода)) Теперь и Вы узнали.

vadiminfoИ вот еще, пример, подтверждение пример "факта" (что никому не известнно что про структурированные МД) для особо сообразительных (до которых долго доходят давно известные избитые весчи)
http://www.kgau.ru/istiki/is/ch02.html#teis_kaga2_2
К сожалению, Google Chrome не может открыть страницу www.kgau.ru.
Поэтому, поясните,пожалуйста Вашу позицию по ссылкам, полученным в точности по предложенному Вами запросу.
Вот мое сообщение:
Одной этой фразой Вы поставили крест на Ваших многолетних усилиях не вдаваться в подробности, основным лейтмотивом которых было: "Если чего-то не написано в толстой книге, то это не заслуживает внимания"))

Теперь же Вы предлагаете:
1) Побывать в гостях у Славы
http://slava.fateback.com/work/docs/database/index.htm
2) Подменить структурированные типы структурированными моделями
http://citforum.ru/database/dblearn/dblearn02.shtml
3) Подменить модели структурированных данных структурированными моделями данных
http://www.math.spbu.ru/user/boris_novikov/courses/mtim3/5-semistructured.pdf
4) И т.п.
http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
http://ref.by/refs/98/24089/1.html
...

Пожалуйста, поясните что такое структурированная модель данных, и, соответственно, что такое не структурированная модель данных.
vadiminfoВ завершение общения с ЧАЛом не могу удержаться, и есче раз не поржать над чтением ЧАЛом Дейта и попытками приплести последнего к тому, что "реляционные системы не СУБД".
Это отжиг так отжиг.
Пожалуйста, говорите по существу. Я полностью согласен с Дейтом в части интерактивного интерфейса. И подчеркиваю, что в "реляционных системах" возможны только такие задачи для интерактивного интерфейса, о которых и пишет Дейт. Из-за неустранимых недостатков РМД. Так что, "реляционная система" в принципе не может быть СУБД. Но, Дейт, как и Вы, может называть такие системы СУБД. Как и продавцы компрессоров, имеют право называть их холодильниками. Но, в отличие от Вас с Дейтом, не называют))
vadiminfoТому кто не знает ЧАЛа скажу, что любимый способ "Доказательства" - повтор. Оппоненту надоест отвечать - и тада "мы видим что возражений нет" или что-то подобное подразумевается.
Так вот и ответьте по существу. Вы еще ни разу не ответили. Вы ушли даже от такого тривиального вопроса о "Фамилии". Другие участники довольно подробно обсуждают этот вопрос, и даже подсчитывают количество строк, которое нужно написать, чтобы пользователь мог бы добавить свойство "Фамилия" к типу сущности "Человек". Правда один явно говорит о разработке СУБД в среде РСХОД, для которой модель верхнего уровня осталась неизвестной, а на нижнем уровне предлагается использовать EAV. А другой говорит, что ему не составляет никакого труда реализовывать и модель верхнего уровня и EAV каждый раз в приложении. А Вы вот только о моей глупости говорите, а не об обсуждаемой проблеме.
Именно Вы постоянно выходите за рамки технических форумов.

LSVУ меня сделано так (см. рис.)
Это:
1) Описать новое свойство типа сущности.
2) Описать доступ к нему (или просто добавить в интерфейсе типа сущности).
3) Вводить значения и делать запросы.
применимо ко всем трем рассматриваемым вариантам.
Или Вы хотите рассказать о четвертом варианте. Или о подварианте второго (EAV) варианта?
Напомню их, на всякий случай:
Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.
Вариант 2. EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.

LSVБредятина,
Когда будет "по существу" ? Срач в топике реально поднадоел всем, кроме Вас...
Конкретно что можете посоветовать ТС-у (см. стартовый пост).
Что ТС должен сделать для реализации ? Какова ожидаемая трудоёмкость ?
Вы прекрасно знаете, что я всегда говорю только по существу. Вот мое сообщение:
Это:
1) Описать новое свойство типа сущности.
2) Описать доступ к нему (или просто добавить в интерфейсе типа сущности).
3) Вводить значения и делать запросы.
применимо ко всем трем рассматриваемым вариантам.
Или Вы хотите рассказать о четвертом варианте. Или о подварианте второго (EAV) варианта?
Напомню их, на всякий случай:
Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.
Вариант 2. EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.

LSVТут много "но".
Посмотрим...
LSVКто даст гарантию, что свойство общее абсолютно для всех типов сущности ? Что делать, если позже окажется, что свойство не может быть общим для некоторых параметров.
Это я уже написал в комментарии к первому варианту. Не вижу никаких "но" по этому комментарию.
LSVПолучается, что все свойства должны лежать в отдельной таблице, чтоб унифицировать выборки. Разве это не разновидность реализации ЕАВ ?
Выяснилось, что нет ни одного "но".
Вариант 3 - это не EAV, конечно же. Это же очевидно.
LSVПожалуй невозможно сделать чистые вар.1 или вар. 2.
У обоих вариантов будут элементы др. друга. Только пропорции разные и трудоемкость реализации.
Пожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.
Уточняю:

Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам.
Вариант 2. С использованием EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.

Вариант 1. Классическая РМД с наследованием общих свойств (?) и отдельной таблицей на "специфические" свойства каждого подтипа типа сущности. Здесь возникает вопрос о "масштабе специфичности". Свойство может принадлежать многим подтипам. И любое из общих свойств (не важно всех или части подтипов) может перестать быть общим.
Вариант 2. С использованием EAV.
2.1. Разновидность 1. Требуется описание.
2.2. Разновидность 2. Требуется описание.
...
2.n. Разновидность n. Требуется описание.
Вариант 3. Классическая РМД с одной таблицей.

Комментарии к Варианту 1 показывают достаточно общую проблему технологии БД: стоит ли описывать отдельно свойства, а потом назначать их типам сущностей, для того, чтобы избегать "дублирующих описаний". Часто имеются какие-то отличия в некоторых атрибутах (чтобы не возникало путаницы, можно использовать другой термин) свойств , когда одно и то же свойство применяется к разным типам сущности.

LSVПожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.Вот смешанный:
1. Простые параметры хранятся в структуре а-ля ЕАВ (их могут добавлять простые пользователи).
2. Сложные параметры (со ссылками на многие справочники, с множеством спецификаций и сложной б/логикой) хранятся в своих отдельных таблицах.
Создаются такие параметры с помощью кучи DML и опытного программиста. Выборки, б/логика - тоже с помощью программиста.

Это будет самый общий случай. Но п.2 бывает не всегда (в смысле добавлять на лету). Тогда получим чистый вар.2.
Пожалуйста, поясните суть термина "параметр".
Чтобы было понятнее, имеет ли отношение эта реализация к рассматриваемой задаче с одним типом сущности (Товар).

LSVПожалуйста, опишите один конкретный "смешанный вариант" (один из подвариантов варианта 2, раз EAV все равно используется). А по варианту 1 дождемся ответа автора этого варианта.Вот смешанный:
1. Простые параметры хранятся в структуре а-ля ЕАВ (их могут добавлять простые пользователи).
2. Сложные параметры (со ссылками на многие справочники, с множеством спецификаций и сложной б/логикой) хранятся в своих отдельных таблицах.
Создаются такие параметры с помощью кучи DML и опытного программиста. Выборки, б/логика - тоже с помощью программиста.

Это будет самый общий случай. Но п.2 бывает не всегда (в смысле добавлять на лету). Тогда получим чистый вар.2.
Варианта 2 чистого нет! Поскольку все реализуют EAV по разному. Вы говорите, что если нет "сложных параметров", то остается только EAV . Но, какой именно вариант? Например, в drupal разные типы хранятся в отдельных таблицах. И это же тоже может влиять на производительность. Поэтому, опишите Ваш вариант. Пусть это будет 2.1.

[quot _мод]LSVпропущено...

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