ВладддПример:
есть человек - пациент амбулаторной поликлиники.
У пациента, помимо стандарного набора (ФИО, дата рождения, пол,адрес и т.д.) есть специфические свойства, которые могут быть добавлены в любой момент: например, завтра вышеуказанная контора придумает "нацпроект" специально для голубоглазых брюнетов (вводится два параметра: цвет глаз и цвет волос). Это, конечно утрировано, но смысл тот же. Нужно иметь возможность добавлять параметры не меняя структуры БД. Например, у пациента(в данном случае пациентки ЖК) нужно добавить параметр "Беременность по счету", т.е. какая беременность по счету:1-я, 2-я или 25-я....Т.е. этот параметр не выбирается из справочника, а вводится вручную.
А завтра нужен будет параметр, который необходимо выбрать из какого-либо справочника, а послезавтра еще один, который вводится вручную, но вводить нужно не из справочника, а вручную, но тип данных - логический (приведен к логическому) или что-то еще...У меня внезапно возник вопрос, простенький, но со вкусом. Предположим, мы реализовали модель EAV и пользователи легко и непринужденно добавляют атрибут "Цвет глаз" или "Номер беременности". Что с этими атрибутами предполагается делать дальше? Как ИС будет обрабатывать эти атрибуты? Где именно будет написано что-то вроде
Где будет храниться реализация этих процедур?
Ну и, заодно, кто будет писать эти процедуры?

Shtock1.как показал мой опыт - люди,любящие eav любят иметь еще и свой язык программирования,но в любом случае обработчики таких вещей обычно лежат в базе либо в виде хп,либо скриптами.Т.е., пользователь, добавив атрибут, должен еще и написать на SQL-расширении БД или, того хуже, на скриптовом языке приложения код, обрабатывающий вновь добавленный атрибут?
Shtock2.прямо в коде процедуры,например CalcComission,а далее в нужной форме вызываться (есть имитация наследования-вызовется по цепочке (может если умная реализация,то и overide сделает метода,т.е. просто что-то не вызовет)).В чем вопрос то?Вопрос простой - для чего нужно городить огород с EAV, если преимуществ от него никаких - скорость выборки низкая, запросы неоправданно усложнены, а от DDL мы никуда не делись - хранимую процедуру все равно пишем. Правда возможен вариант, когда эту самую процедуру процедурой не оформляем, а интерпретируем на ходу, использую динамический SQL, но это еще больше снижает производительность приложения.
Shtock3.А писать,как не удивительно будем их мы,скромные добрые программеры :)Само точно писаться не будет.Хотя если построить как-нибудь умно справочники-возможно сделается и само.Т.о., ничто не мешает "скромным добрым программерам" добавить в таблицу поле, описывающее новый атрибут.

модВсе очень просто: есть заранее написанные функции для доступа к любым (и новым и старым) атрибутам сущностей (даже еще не существующих). Эти функции используются везде: в обработчиках, в отчетах, в формулах и т.д. Т.о. можно добавлять новые сущности и (или) атрибуты и тут же их использовать.Функция доступа, извлекающая значение тривиальна, поэтому интереса не представляет. Вопрос был сформулирован иначе - в чем смысл предоставления пользователю приложения возможности добавления новых атрибутов, если он не сможет эти новые атрибуты обрабатывать?

Petro123 новый гость вы путаете 2 вещи:
- EAV позволяет легко добавить новый атрибут пользователем, но не имеет никакого отношения к новой бизнес-логике по его использованию.
За исключениме того, что в запросах SELECT пользователь его увидит автоматом, т.к. он не в полях, а записях.
Бизнес логика с пособиями одинаково пишется что в EAV что в ROT.... (где-то же надо писать про добвленную колонку разрез-глаз)Не путаю, в том-то все и дело. Именно поэтому и спрашиваю - откуда такой восторг по поводу этого подхода, если плюс у него только один - "в запросах SELECT пользователь его увидит автоматом"?