Роман Дынник
Судя по Вашим высказываниям я вывел для себя примерно такую мысль "Мне с Тигрой давно пора бросать проектировать таблички и ХП, и переходить на ООП, потому что Вам так удобнее". Не обижайтесь, но смысл полностью таков.

Далее еще раз не обижайтесь, но лично я вижу, что опыта проектирования БД и написания бизнес-логики на хранимых и триггерах у Вас маловато будет. Это не смертельно, но это не повод лично Вам выступать как просветителем "мрачных и морально устаревших" архитекторов БД.

Далее могу сказать, что у меня на WatcomSQL (диалект ХП для ASA) написан движок, который по макетам может генерить ХП с параметрами, при запуске которых они создают в БД ХП, генерящие нужные действия. Это используется для генерации в моих личных целях HTTP-контентов и организации интранет-сайтов на базе ASA. Это же используется для генерации по макетам хранимых процедур и триггеров. Движок этот занимает ровно 12 небольших по обьему хранимых процедурок, которые расковыривают макет, выщемляют с него тело, определяют секции и параметры, описанные на XML, преобразуют ключевые слова в действия и генерят все в виде WatcomSQL скриптов. В итоге в моих БД 80% ХП тоже генериться автоматически. Я мог написать такой движок на ООП, но уверяю, меньше бы по размеру и трудоемкости написания он не стал, просто бы пришлось использовать при написании другие парадигмы.

Далее мои и Ваши 80% автоматически сгенерированных процедур в БД не говорят о том, что мы с Вами круты, а вот Тигра нет. Это говорит только о том, что мы с Вами предпочитаем уводить DML операторы на уровень хранимых процедур и они вполне однотипны согласно определенным макетам. У меня во всяком случае в зависимости от типа сущности, который может обьединять в себя множество связанных таблиц и определенные аттрибуты могут автоматически генерится множество процедур по 7 различным макетам, все назначение которых - свести работу клиентского приложения с базой данных до примитивного уровня - получил в простом виде, изменил и вызвав ХП зафиксировал изменения в простом виде. Я уже молчу про множество автоматом генерящихся триггеров, которые в зависимости от определенной модели поведения занимаются различными проверками, вычислениями и другой полезной, но в принципе рутинной работой.

Что имеем в заключение ? Имеем, что не средство определяет специалиста, а специалист определяет средство. Так же имеем, что чем шире у специалиста кругозор, тем больше решений в различных измерениях он может осознать и применить. Не надо думать, что Тигра или я в жизни не занимались ООП. Лично я потратил на это 7 лет своей жизни, написал добрую сотню визуальных/невизуальных компонент, несчетное кол-во классов, с десяток интрепретаторов и различных парсеров. Поэтому не надо лично мне заявлять, что мне пора отвыкать от таблиц и полей - это на самом деле не серьезно. Я знаю что такое ООП и успешно использую его по назначению каждый божий день :)

Гы - не удержусь - в конце концов с ООП я знаком с 1990 года, когда мне в руки попал славный добрый Turbo Pascal 5.5 и первое что я на нем сделал в качестве осмысливания ООП - это собственную навигационную базу данных :) Странно, что я с тех пор переменил свое мировозрение, не правда ли ? :)