[quot LSV]Чихать на них. Бесперспективная экзотика. Не то, что не сталкивался, я даже не слышал. И нет желания.
Отомрут сами за ненадобностью.
[quot ]
Ну Вы же не думаете в серьез, что такого рода аргументы не нуждаются в каких-то дополнительных подтверждениях, очищенных от эмоциональной составляющей?


[quot LSV]Странный вопрос. А зачем для этого отдельные СУБД ? EAV это методика. Не универсальная, но удобная для ряда задач.
Ниодна методика в чистом виде неприменима или неудобна. Всегда используется набор методик и приёмов.
[quot ]
Вопрос был связан с тем, что EAV это не просто методика, а МД. Если нет, НЕ МД, то тада ей тем более нечего делать рядом ООМД. Поскоку последняя МД.

LSVДумаю, не ошибусь, если предположу, что 80-90% прикладных решений не используют декларативную ОЦ. И на это есть много объективных причин.
И не нужно тут тыкать в умные книги. Ок ? Это не более, чем теория или даже (подчас спорное) ИМХО автора. Сферические кони в вакууме. А жизнь сложнее.
Ради хохмы возьмите и приведите свою БД в полное соответствие с 3,4,5 НФ. И что получится ?
Вы можете отказаться и от других достижений технологий БД. Например, от юзания самого СУБД, и говорить про тыканье в умные книги, тем кто их юзает. Сделали шаг: отказались от части важнейших возможностей, сделайте следующий откажитесь от всей СУБД. А эти книги не отрицают достоинств и систем без СУБД кстати, как впрочем и недостатков.
И куда тыкать? В выдумки вчерашних проггеров драйверов, пришедших сеня в БД?
Так я встречал, и тех что на ассемблере всю ИС хотели делать. Ну они системщики до этого были.
Не ради хохмы, но я четко контролирую в каких нормальных формах моя БД. И если какая-то нарушена, то я знаю все последствия. Однако, не помню чтобы БД не была в 3НФ. Я вообще при проектировании следую метологиям рекомендованным в умных книгах. Там этап оптимизации (куда входит и нормализация) схемы обязателен. Мне лишние риски не нужны. Мне не хохм.

LSV Почему нарушаем ? Есть основания, не так ли ?

Есть. Например, из-за приведения к нормальной форма Бойса Кодда может нельзя буит навязать деклративно некоторые ф зависимости.


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


LSV На всё есть целесообразность.
по сабжу: Железных правил нет. Есть рекомендации. И то, часть их них ИМХО-шные.
Вот целесообразность в том, что буржуа придумал методолгии и рекомендовал не от того, что ему делать нечего. А исключительно на основе выявления прничин значительного кол-ва не успешных проектов, и вынужденного поиска снижения риска таковых.
Иными словами, кажный проект имеет риски неудач в той или иной степени. Вот чтобы их снизить и приходится юзать рекомендации.

LSVЛибо, наоборот, не юзать. Не так ли ? :)
Ну, да. Это агрессивный типа такой подход к проектированию.
Есть и не заморачиваются ознакомлением с рекомендациями.
В результате бывает так, не только ХП вместо декларативных ОЦ, но и массивы в этих самых ХП вместо таблов в БД появляются. А то и в клиенте. Аномалии БД. И вообще выяснется, что в принципе нет возможности извлеч требуемую заказчиком инфу, не смотря на то что она как бы должна там быть (была в предшествующей системе).

LSVПлатформы - чисто условно. Обычные приложения с использованием СУБД.
Неэффективно ? Пожалуй. Но на это есть причины. И не надо тут про ошибки архитекторов. Ок ?

И на этих типа платформах ХП вместо декларативных ОЦ? Может эти причины связаны с чем-то именно платформенным? Типа налабать свой язык и плюс по возможности достигнуть независимость от конкретной СУБД. Ну просто не сподобились налабать свое СУБД, а тока язык типа свой. Теперь два движка: свой язык и СУБД, ну естественно в сторону своего языка одеяло натянули. Вот может и вся та типа причина. Эта исключает, скорей всего ХП в принципе, и ни о каком их преимуществе над декларативными ОЦ не говорит наличие у кого-то таких причин.

Потому просто сказать, что там есть причина не достаточно на таком форуме. Нужно сказать в чем они.

LSVИ что останется от СУБД-решений, если откинуть все платформы, в т.ч. недо- ?
А что останется от платоформ-решений, если выкинуть СУБД? Файловые системы? Этот до СУБДшный период в истории ИС, скорее всего, ассоциируется с депрессией программного обеспечения. Возможно, платформы менее ценное чем СУБД.

LSVИспользование ХП как ОЦ - всего лишь один из путей построения систем. Имеющий ряд недостатков и преимуществ перед прочими путями.

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


LSVЭто большая отдельная тема. И неоднозначная. Главная причина - независимость от конкретной БД.

Опять извините. Поскоку ХП значительно большая зависимость чем декларации: причины связанные с независимочстью от СУБД не подходячт совсем. Это как бы в минус ХП причины. Это вообще причины для тех у кого есть план теражировать над СУБДшную часть для разных систем. Это левая цель и причина по отношению к проектированию конкретной ИС.

LSV
Юзайте себе СУБД-ОЦ на здоровье.

Разумеется.

LSVзы: списка известных систем использующих СУБД-ОЦ никто так и не привел. :)
А смысл? Ить Вы сами сказали, что у них задача - независимость от конкретной СУБД.
Это для платфомо строителей не иемющих своей СУБД имеет значение.

LSVТупой спор ради спора.
Это от того, что доводы в виде "на то есть причины" при уточнении содержательной стороны причин не подошли?
Ну так не надо было их приводить.


LSVПриведенная цитата касалась различных тиражных систем и причин построения их архитектуры. Конкретно про ХП там речь не шла, а шла про неиспользование ими СУБД-ОЦ.

Ну и пришла поэтому к тому, что не связана с преимуществом ХП (и вообще кода) над декларативными ОЦ. А есть для платформосоздателей какие-то там преимущества при поддержки решений на разных СУБД их платформ.
Ну так для тех кто независим от этих платформ - это в общем случае вообще не преимущество.

LSVЕсть примеры, где частично применяются сразу несколько подходов: СУБД-ОЦ, ХП, прямые запросы/проверки на клиенте и элементы платформы (встроенные средства разработки).

Да есть примеры и вовсе без СУБД. Особенно до появления СУБД их много было.
Мало ли что есть?

LSV
"Нет правил. Есть рекомендации." (с)

А рекомендации основаны на соотношениии недостатков и преимуществ.

LSVДальнейшие прения теряют смысл.
И как видим теперь: они сразу не имели смысла. Сенсации не произошло: то шо написано в умных книгах Вам пошатнуть не удалсь, скорее всего.

LSVДа есть примеры и вовсе без СУБД. Особенно до появления СУБД их много было.
Мало ли что есть?Форумный троль детектед. :)
"В интернете кто-то неправ" (с)
Ну это типа аргументы преимуществ ХП над декларативными ОЦ, хорошо подходящие только для ТП. Здесь они,возможно, не уместны даже, если других нет. Здесь их вообще по хорошему должны были бы удалить.