авторКогда программист пишет программу он работает с объектами, не так ли. Они существуют в памяти компьютера. Это данные, правильно? Чтобы их сохранить в РБД надо преобразовать эти данные к виду таблиц. Сделать маппинг.
Вот оно как оказывается получается :) Я почему то всегда думал, что программист когда пишет программу, он описывает структуру информации и пишет алгоритмы ее обработки. А уж в каком виде информации хранится и обрабатывается зависит от использующегося инструмента. Или Вы думаете что все тут пишут программу обьектами, которые еще почему то все храняться в памяти ? :) Лично я наоборот все больше считаю, что SQL гораздо современнее и эффективнее ООП в области работы с данными, так как это фактически функциональный язык работы с множествами (описанными структурами), а в реализованая в современной модели ООП концепция обьектов и их обработки скажем так для операций над множествами не очень катит. И тут никакое наследование не поможет по той причине, что оно просто не сдалось - нам не надо стремится сделать отображение реального мира (которое по любому с помощью наследования лишь частично реализуемо), а всего то решать конкретно поставленные задачи.

авторПросто дать команду commit и объект уже в базе данных. Я так понимаю объектные СУБД.
А если мы зараз меняем миллион обьектов, которые на событие их изменения они меняют еще 10 миллионов обьектов. И вдруг по бизнес-логики возникает ошибка запрета на изменение одного из обьектов, которая приводит к ROLLBACK и соотвествующе к тому, что неплохо бы все эти свойства обьектов вернуть в первоначальное состояние, чтобы не нарушить целостность базы данных. А в это время другая сессия пытается по всем этим обьектам отчет собрать, причем ее не волнует, чего там и как меняется - главное, чтобы вся информация была целостной и не получилось, что в начале отчета данные одни, в конце другие, а в базе вообще третьи. Как все это себе представляем ? Если в виде "дал commit и обьект уже в БД", то это будет грустно, глючно и тормознуто. Но в той же РСУБД об этом даже думать не придеться.

P.S. Я лично вообще не работаю в задачах с обьектами. Я работаю с информацией, ее сбором, обработкой, преобразованием, аналитикой. Обычно информации "множество" и алгоритмы обработки требуются для "множеств". Никого не интересует одна запись (обьект), разве что клиентские приложения, когда они формочку на ее ввод, редактирование делают. И то у тех уже на обьектной иерархии нужные компоненты работы с множествами реализованы, которые кстати в первую очередь используют коллекции, кои в каком то плане можно назвать убогим аналогом таблиц РСУБД.

LankasterОн не мыслит набором данных.
Тем не менее нужно определить набор данных. Но кто сказал, что это нельзя представить в виде объектной модели? Есть CASE-средства для этого. Которые, кстати, могут на основе модели создавать прототипы классов.
Профессиональному программисту (а не администратору баз данных) этого уже достаточно.
ИМХО
А что - CASE уже генерить физические модели для РСУБД по логическим уже не умеют ?

авторПрофессиональному программисту (а не администратору баз данных) этого уже достаточно.
И еще пожалуйста определите, причем тут администратор БД и может ли профессиональный программист быть проектировщиком БД, не занимаясь кодированием (я например таковым себя считаю) ?

Lankaster ASCRUSА что - CASE уже генерить физические модели для РСУБД по логическим уже не умеют ?
Умеют. А зачем?
Зачем программисту на Java, например, физическая структура данных? Если он может работать с логической.
Я не очень понимаю, как на Java можно работать с логической структурой данных. Если Вы считаете, что обьект в ООП можно назвать логической (чистой) структурой, один в один соотвествущей реальному обьекту в мире, то Вы глубоко ошибаетесь.

авторВсе IMHO:
Мое личное мнение, что программист проектирует систему (ее архитектуру), а не структуру данных. Точнее даже не программист, а архитектор.
Программист реализует эту архитектуру.
Администратор баз данных - тот, кто следит за оптимизацией хранения (чтения-записи) данных.
Не возможно спроектировать систему и ее архитектуру без формализации ее структуры и описания ее бизнес-процессов. Все это элементарно делается на РСУБД, где на DDL описываются структуры хранения данных, а на SQL, DML и языке хранимых процедур прописывается бизнес-логика. БД получается законченным самостоятельным модулем системы. Дальнейшая разработка клиентской части - это уже вторичное дело и без разницы на чем ее делать - на ООП языках, веб-технологиях или вообще работать напрямую через ISQL. Соотвествующе пытаться подогнать СУБД только под критерий "чтоб было удобно одной из технологии разработки клиентских приложений" мне кажется не рациональным.

Lankaster"Программистские объекты" - лишь попытка приблизиться к реальности. На мой взгляд, пока - самая удачная.
На мой взгляд это не удачная, а устаревшая модель приближения к реальности. Концепция обьединения формализованных данных с методами их обработки, да еще с поддержкой посредством наследования расширения аттрибутов обьекта мне лично в последнее время не нравиться. Можно подумать, что если у меня в иерархии классов от класса "Обезьяна" будет наследован класс "Человек", то я в любой момент смогу "привести" человека к обезьяне и получить размер хвоста и модель ее поведения.