user.maxНа какие грабли можно наступить при такой "оптимизации" хранения eav?
На грабли можно наступить, если этого не делать.

user.maxА вот между 2 и 3 по каким критериям определяться?
Очевидно, посмотреть на значения этого типа и решить, что больше подходит для их хранения: столбец или таблица.

Сергей ВаскецовДа и при чём тут брендовость?
Брендовость здесь очень даже при чём. Автор называет те системы, разработчик которых

а) не сопровождает их и не решает связанные с ними проблемы
б) стремится плюхнуться на разные платформы, не обладающие совместимым инструментарием. начиная с 1С с её dbf-ами
в) не заинтересован в целостности данных и между раскладами "просигнализировать об ошибке" и "спрятать ошибку" однозначно предпочитает второе

Отсутствие СЦ при таких требованиях очень даже логично.

Сергей ВаскецовПричём в пример приводится совершенно конкретный класс ERP, который можно смело называть "впарил и забы(и)л".
Именно так.

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

L_argoВ идеальных условиях можно использовать СЦ.
А в остальных - нужно.

L_argoЯ когда-то пробовал использовать СЦ и мне не понравилось. Многие "удобства работы" становились недоступны.
Как и ожидалось, Вы не назвали ни одного удобства, которое становится недоступно. Как и в случае с EAV, речь идёт исключительно о неграмотности, приводящей к проектированию трёхколёсных велосипедов.

L_argoКоллега, зачем Вы так грубо передергиваете ?
Говоря деликатно - у меня противоположное мнение на тему того, кто передёргивает.

L_argoТолько не надо тут "а вот в Оракле...". Не у всех Оракл.
Если бы Вы сказали "в моём dbf СЦ не поддерживается, поэтому я ей не пользуюсь", это ни у кого не вызвало бы несогласия. Если же Вы говорите про СЦ - извольте говорить про СЦ, а не про реализации в дерьме мамонта.

L_argoПросто есть многочисленные задачи, где это применять по ряду причин неудобно.
Назовите хотя бы одну.

L_argoПовторяться из поста к посту и из топика в топик ?
Ну если хотите напоминать двоечника, который в сотый раз пишет 2+2=5 и надеется, что в этот раз окажется прав...

L_argoНаличие данных в стиле ТипДокумента+ИдДокумента.
И? Если в предыдущих примерах хотя бы понятно, чего Вы не умеете, то здесь-то чему мешает СЦ?

L_argoБлижайший пример такого решения - 1С.
Снова пример решения на dbf-архитектуре?

L_argoЕсли бы причин неиспользования СЦ не существовало, то они бы использовались буквально везде.
Это правда. Вопрос в том, что неграмотность и тому подобные причины, хоть и приводят к неиспользованию СЦ, но, как бы деликатно назвать - неубедительны.

L_argoНо все наоборот - используются нечасто.
Господи, какая глупость. Такое впечатление, что Вы сидите в каком-нибудь болоте, где не используются, например, хранимые процедуры, и на основании этого утверждаете, что ХП нигде не используются.

L_argoВставка данных в разные таблицы из CSV. Если таблиц 5-6, то порядок их импорта может быть неочевиден.
Отдельно от прочего хочется спросить - часто ли Вам приходится выполнять задания вида "вот какие-то левые данные, загрузи их куда попало не разбираясь в них"?

Стандартным решением для задач подобного плана является загрузка данных не в боевые таблицы, а в отдельную staging area, в просторечьи - "отстойник". Причина в том, что в таких данных, как правило, присутствует уйма нарушений, например - неправильные десятичные разделители, насованные куда попало лишние пробелы, нарушения формата csv во входных файлах (скажем, неправильная обработка запятых или кавычек в исходных данных), ИНН из девяти или одиннадцати цифр, нарушения уникальности, скажем, один и тот же номер паспорта у двух разных людей и т. д. и т. д. и т. д. Только идиот суёт подобный мусор в боевые данные, обычно их загружают отдельно, очищают, выверяют, и только после этого пускают в работу.

Тем не менее, даже если делать так, как Вы - пока что не вижу проблем, требующих отказа от СЦ. Что именно Вы с ней не можете сделать?

L_argoК тому же в любой момент может оказаться, что для одного из малозначимых ИД-полей недогружен соотв.справочник.
Опять же не вижу проблем, требующих отказа от СЦ. Чего именно Вы в этой ситуации не можете сделать?

L_argoВы из какого десятилетия пишете ? Это последняя 1С8.3 на mssql
Она работает с MSSQL. При этом, насколько я помню, внутри у неё тот же dbf - в смысле, та же структура данных, которая была во времена dbf.

L_argoОга. Значит для таблиц staging area мы не делаем СЦ ?
Вы - не знаю. Обычно в staging area для числовых полей и дат используется тип varchar (потому что в загружаемых данных на их месте запросто могут встретиться пробелы или чего повеселее) и в целом используются подходы, рассматривающие загруженные данные как мусор, из которого надо извлечь жемчужное зерно. Вы, насколько я понимаю, привыкли именно так проектировать базу в целом? Тогда я не удивляюсь тому, что Вы не используете СЦ.

L_argoА где грань между "staging area" и всем остальным ?
Там же, где у Вас в квартире грань между мусорным ведром и холодильником.

Так чего именно в вышеизложенных задачах Вы не умеете сделать при наличии СЦ?

L_argoЧему мешает СЦ ? Тому, что "Документы" это разные таблицы.
То есть, Вы не умеете решить эту задачу в реляционном стиле, я правильно понял?

L_argoзы: ни один сантехник не скажет, что его предыдущий коллега все сделал правильно. :)
Теперь я понял, у кого Вы учились программировать.