Мы же про передачу иерархического объекта заговорили в виде xml в сравнении с java-объектом.
Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. Потом, у меня, например, как я уже говорил ВСЯ бизнес-логика на сервер не переносится. На сервер переносятся только CRUD операции в виде слоя хп. Что же касается бизнес-логики (далее БЛ) по части различных проверк на корректность ввода, в ряде случаев (не во всех) ветвлений if-ов - по моему мнению это дело именно среднего звена (если мы говорим о многозвенной арх-ре). При этом часть БЛ касающаяся проверки на корректность ввода дублируется и в среднем звене и на клиенте. И все это способствует масштабированию.
У меня стандартные компоненты доступа к данным используются для заполнения и просмотра списков и именно в этом их основное предназначение (если говорить о различных recordeset, dataset, reader-ах).

Странно, но мне как раз все это облегчает задачу.
Я знаю что вы являетесь поклонником продуктов Sybase...
Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами.
В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах.
ООП полезно везде. Пора перестать мыслить таблицами и полями.

авторНу во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ?
Мы же про передачу иерархического объекта заговорили в виде xml в сравнении с java-объектом.
авторВо вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ?
Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. Потом, у меня, например, как я уже говорил ВСЯ бизнес-логика на сервер не переносится. На сервер переносятся только CRUD операции в виде слоя хп. Что же касается бизнес-логики (далее БЛ) по части различных проверк на корректность ввода, в ряде случаев (не во всех) ветвлений if-ов - по моему мнению это дело именно среднего звена (если мы говорим о многозвенной арх-ре). При этом часть БЛ касающаяся проверки на корректность ввода дублируется и в среднем звене и на клиенте. И все это способствует масштабированию.
автор Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта.
У меня стандартные компоненты доступа к данным используются для заполнения и просмотра списков и именно в этом их основное предназначение (если говорить о различных recordeset, dataset, reader-ах).

авторВ данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу.
Странно, но мне как раз все это облегчает задачу.
Я знаю что вы являетесь поклонником продуктов Sybase...
Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами.
В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах.
авторгде ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения.
ООП полезно везде. Пора перестать мыслить таблицами и полями.

>>>c127
Не используют потому что не привыкли, потому что мыслят таблицами и записями, потому что надо время на изучение а его нет, потому что не везде целесообразно применять java-процедуры.
Если признаться, раньше я и сам задавался вопросом где и зачем они мне могут понадобиться.

авторВы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д.

В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность?

А я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого. Я говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных. Если отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема. Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь:
наследование в виде связи 1-1
методы в виде слоя хп
свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую.

авторНу и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте.
я почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур.
По поводу поодержки - разделяйте код на сборки, модули...
Про перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS).

>>tygra, вы вникайте повнимательнее в сообщения.

>>>Tygra's
Для примера, какие бы вы таблицы создали для простого
справочника клиентов с разделением на физические и юридические лица?

to funikovyuri
авторТем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми.
Как вам (100+1) вызов на сохранение счета со 100 позициями?
авторС уровнями изоляции если правильно работать - то никаких deadlock'ов не будет
Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД?

авторТаблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 0, значит нет, если 1 - значит это юрик, и тогда у него есть реквизиты =>
А это уже таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д.
Вот вроде и все. Когда мне нужен просто клиент - селект фром Клиент. Если нужны реквизиты к тому же - left join Реквизиты. Ну и т.д.
Как вы можете прокомментировать?

Как же ФИО может относиться и к физ лицам и к юр?
И видимо ФИО хранится в одном поле и используется либо как наименование организации, либо как фамилия имя отчество для физ/лица?

А У нас так:
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)

для вывода всех клинтов: select * from контрагент
для вывода всех юриков: select * from [Юридическое лицо] JOIN контрагент
для вывода всех физ.лиц: select * from [Физическое лицо] JOIN контрагент

видите, только из-за того что вы отвергаете мышление в терминах ООП вы сделали outer join, когда можно было join, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи. В принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д).
Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования.

Теперь дальше...
Возникло новое требование.
Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом.
Ваш действия?

авторЯ бы сказал, что контагент - это обобщение понятия физических и юридических лиц
Именно это я и хотел сказать.
Это уже бизнеслогика.
авторТо есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.
Это как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно.