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

авторВообще разговор перешел в интересную плоскость – не о том, лучше ли многозвенка двухзвенки, а о том, нужна ли объектная прослойка между СУБД и клиентом. По результатам этого обсуждения у меня сложилось впечатление, что адепты двухзвенок и отказа от объектной прослойки просто занимаются разработкой исключительно серверной части, причем с бОльшим упором на базу данных (вернее база данных и является единственной серверной частью), проблемы разработки клиента к этой серверной части от них немного в стороне находятся. Советую поднабраться опыта разработки клиентов и промежуточного слоя на любом ОО-языке, например веб-приложений или веб-сервисов – промежуточный слой в чистом виде. Тогда вопросов уровня “что лучше, ХП или классы”, поубавится.
Не очень понятен этот абзац. Если Вы намекаете, что тут собрались исключительно теоретики и проектировщики БД, то смею Вас уверить, предложение Ваше "поднабраться опыта" не выглядит заманчивым - с 90-ого года я слишком много поднабрался опыта начиная с TP3, Clipper, меняя взгляды в сторону ООП на TP5.5, а так же потом всякие FoxPro, Paradox, Delphi, Java ... Так что и свои движки БД делал и с файл-серверными системами плотно работал, даже 3-х звенкой в конце 90-ых баловался через DCOM. Куда уж больше опыта. Лично сейчас я предпочитаю использовать ООП по назначению - рисовать иерархию форм, визуальные компоненты и прочие вещи для интерфейса клиента, парсеры, интерпретаторы и прочие интересные для ООП вещи, руководствуясь простой истиной для проектов с БД - чем меньше клиентского кода, тем меньше ошибок в нем сделают кодеры. А вот что то рисовать на алгоритмических языках, ООП они или процедурные или еще какие - желания никакого абсолютно нет, представляется мне это неэффективным, неудобным и даже скучным. И по многим, голосующим здесь за бизнес-логику на РСУБД могу сказать тоже самое, путь они прошли долгий, пока поменяли мировозрение и выбрали такую схему работы, что частенько давалось тяжело.

авторЕсли же вы строите ERP-систему, где применяется план счетов со множеством аналитик, где на каждый документ огромное число правил - то сопровождение такой двухуровневой системы очень сложно (что в данный момент у нас в организации и происходит), классы намного бы упростили задачу разработки и сопровождения. Выход я пока видел один - сервер приложений.
У меня проект под департамент социальных выплат для крупного холдинга - поддерживается куча аналитических схем (многоуровневых деревьев) планового и фактического учета выплат, настраиваемые правила по документам - от контроля необходимости заполнения различных аттрибутов документов до финансового мониторинга, системы заявок и статусов фактических выплат, аналитики и прочее. Все это еще обвязано в схему работы узлов, где есть дерево с консолидированной вершиной (сам холдинг) и многоуровневым обеспечением хранения, доставки и работы на удаленных узлах (серверах) с помощью оффлайн репликаций, единым централизованным управлением как серверами, так и правами пользователей (вплоть до того, что пользователь имеющий права на нужные узлы спокойно со своим логином и паролем может разьезжать между ними и работать/администрировать с системой). Все это реализовано стандартными средствами: хранимые процедуры и триггера, дополнительные скрипты в таблицах (text), динамический SQL, репликация. Кода вообще копейки, все легко расширяется и интегрируется с другими системами, откуда могут браться дополнительные данные (с той же зп или ERP). Естественно на клиентской части созданы удобные средства управления и администрирования логики проекта, большая часть - это вообще собственные системные обьекты, отработанные не один год, работающие во всех наших проектах и организованные по модульной системе, проекты пишутся командой, соответствующе изменения служебных обьектов БД или иерархий классов в клиентской части идут через систему контроля версий и спокойно собираются для остальных проектов. Никакого 3-его звена, минимальное кол-во кода и достаточно большая гибкость, универсальность и легкость. Есть одна оговорка - на MSSQL все этого бы не получилось в том полном обьеме, что у нас есть. На ASA или Oracle это нормально можно организовать (на ASA правда по легче, для Oracle придется попыхтеть). Так же сейчас у нас в предварительных проектах лежит система документооборота и система организации интернет продаж с требованиями реализации универсальных пользовательских механизмов, позволяющих на уровне блок схем описывать движение документов и правила продаж товаров с возможностью дополнительной логики (например проводимые акции, подарки и прочее). Самое интересное - если эти проекты будут утверждены для разработки, я даже задумываться не буду - не вижу ни одного препятствия для того, чтобы всю эту логику реализовать средствами БД, причем я даже сразу знаю, как. Так может быть просто стоит задуматься о смене сервера, может быть клиентской части и повышении квалификации, чем переходить на ООП, который по любому для РСУБД, что кривой костыль и мешать парадигмы, где все равно от SQL так или иначе никуда не денешься и обвязка данных обьектами все равно не позволит полностью увести приложение на обьектный уровень, а значит какой в этом толк, если все равно те же отчетники будут требовать SQL, расчеты над множествами данных быстрее работать на ХП и прочее.

P.S. Да - я еще никак не понимаю акцента на клиентские части. Неужели разово нарисовать иерархию интерфейсной части, отработать ее по самое не хочу, купить и доработать универсальные компоненты доступа и визуализации данных через SQL сложнее, чем писать с нуля свою трехзвенку, а значит по любому что то свое лепить с нуля. Про универсальных саморазворачивающихся клиентов можно забыть - легче мышкой накидать новую формочку, причем даже лучше будет не формочку-класс, а формочку встроенного в клиентское приложение какого либо скриптового языка с визуальным дизайнером, благо их навалом, чем пытаться автоматически их генерить, ущемляя удобство интерфейса и возможности. Очень интересные горизонты открываются с такими скриптовыми движками в клиенте, снимается множество проблем и добавляется куча новых возможностей (то же самое и отчетных систем касается - тот же FastReport со своим FastScript после доработки напильником очень даже приятно выглядит).