Сергей Арсеньев ...Вопрос именно в том, что у реляционной модели одни подходы к представлению данных, у ООП другие.
...

Я не понимаю. какие-такие у собственно ООП есть "подходы к представлению данных".

Объясню на примере. Используя какой-нибудь ООЯ я могу создать разные объекты с разным представлением данных. Например я могу реализовать класс "Таблица" и два его подкласса "ХранимаяТаблица" и "Вид". Для класса "Таблица" я сделаю разные методы, например метод "Проекция", который будет принимать у меня набор имен, и выдавать новый объект класса "Таблица". То есть эти мои объекты будут моделировать реляционное хранилище в соответствии с РМД.

Вопрос. В этом примере какое представление данных получилось - объектное или реляционное?

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

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

Поэтому сравнивать ООП И РМД по их "представлениям данных" некорректно, ибо сравнивать нечего.

Кстати, собственных операция над данными в ООП тоже нет. По этому пункту она тоже - не МД.

Если у Вас есть другой ответ на мой впрос по примеру, давайте. Только, ради бога, не надо словоблудий, обходитесь простыми, понятными терминами, типа "тип", "переменная", "операция", "модель данных"(по Кодду, а не просто так), "схема данных" и т.п. Как только начинаешь их понимать и использовать, сразу многое в голове проясняется и становится на свои места.

По остальной части вашего поста вижу кучу обычных ляпов. Типа в разговоре про концепции и про формализмы вдруг начинается обсуждение эффективности систем и т.п. Здесь они обсуждаются. .

И в конце концов мне кааца, Вы о чем-то своем спорите, аргументируя какими то прикладными приложениями, где, видимо, живут объекты, которые, видимо, надо запихнуть в БД. Нет у меня этого.

mad_nazgul
"Смешались в кучу..."

SQL - это декларативный подход, как минимум так проектировался.
Грубо говоря мы формулируем что нам нужно получить, а ЯП сам решает как это сделает.
ООП работает в рамках императивного подхода.
Т.е. мы должны не только знать что нам надо, но и как это получить.
Т.к. ИИ нет, то декларативный подход имеет множество ограничений.
В частности смогли более менее его реализовать на РМД.
Более общий декларативный подход не осилили (см. Prolog).

Если "статичные" данные более-менее укладываются в РМД, то уже такие вещи как бизнес-логика и бизнес-процесс в РМД ложатся очень трудно.
Т.е. в БД нужно хранить только данные, а все остальное выносить на уровень приложения.
И объекты уж точно нельзя хранить в БД, только данные для объектов.

А уж ООБД и NoSQL это химеры.
Предназначенные для "честного отъема денег у населения"

<:o)

Тоже смешались в кучу :) Вы постоянно путаете сами концепции и существующие реализации этих концепций.

Существующие реализации ООП работают в рамках императивного подхода, ибо создавались как развитие средств программирования. В самой ООП нет не слова ни про императивность ни про декларации.

В самой РМД вообще нет понятия алгоритма, потому бизнес-логику туда вообще не уложить. Проблемы возникают в существующих реализациях РМД.

CawaSPbКакой сра.. дисскуссию пропустил!
Да разве это дискуссия! Вот лет десять назад тут кипело, а щас так, пузырек какой-то.

CawaSPbПодливая масла в огонь:
http://martinfowler.com/bliki/OrmHate.html

Ну и конечно же упоминаемая там же классика:
http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer Science.aspx
И я подливаю , подливаю .

BusIntВсе просто - ООП не нужно! Тока не так категорично. Но согласен, существующие реализации ООП местами приносят больше граблей, чем пользы.

Сергей Арсеньев Встречный вопрос у топиккастера - почему ООП плохо ложиться на РМ? Вопрос как РМ переложить на ООП из другой оперы.
Придумать нечто урезанное до того, что легко вписывается в те и другие рамки, тоже не ответ на первоначальный вопрос.
Это мы еще не рассматривали ООП в терминах прототипирования (а не наследования) с динамической сменой цепочки прототипов.

Не надо уходить от ответа.
Я дал совершенно четкий пример и задал очень понятный вопрос по непонятному мне "представлению данных" в ООП Это не "встречный" вопрос, а лишь попытка понять, о чем Вы вообще говорите. Также я объяснил, почему никакого "представления данных" в ООП вообще нет (видимо Вы этого не поняли, раз пишете про "и те и другие рамки").

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

Сергей АрсеньевU-gene,

Мы говорим о том, что часть парадигм составляющих ООП плохо представимы в виде РМ.
Если же пытаться напрямую сбросить это в базу, не задумываясь, что хорошо для РМ, а что плохо, то каким бы ни был умным ОРМ возникают сложности.

А я не говорю "о том, что часть парадигм составляющих ООП плохо представимы в виде РМ." У меня все базовые парадигмы очень даже представимы. И вообще, что такое "плохо"? Мы же говорим о формальных вещах, там либо ""представимы" либо "не представимы".

Какой ОРМ? Откуда Вы ОРМ то взяли? Я ж говорю , что Вы о чем то своем поёте. Нету никакого ОРМа, забудьте же про это. ОРМ - это когда какая-то реализация ООП в системе с линейной памятью отображается в реляционную память, а у меня речь идет о реализация ООП в системе с реляционной памятью , там в принципе маппинга нет, данные уже там где нужно и в каком надо виде.

В общем этот наш разговор - наглядное подтверждение слов Дейкстра о незаметном и сильном влиянии языка на мышление программистов. Все привыкли к принципиально схожим реализациям ООП для программирования систем с линейной памятью и мучаются, пытаясь отобразить линейную память в реляционную (на момент исполнения данные лежат в линейной памяти, а все эти "объекты" остались в исходном тексте и/или в голове программиста).

Кстати, мы же не говорим, что"часть парадигм, составляющих ООП плохо представимы в виде" линейной памяти.

Вы таки помедитируйте о чем я говорю. :)

mad_nazgul,

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

А Вы, я гляжу, знаток, дааа. Извините за следующий вопрос. Правильно я понял, что Вы РМД назвали машиной вывода?

Basil A. SidorovВот соглашусь с безумным назгулом - не надо напяливать ООП на РМД только потому, что это можно сделать. Так напялено уже давным-давно. Принцип напяливания давным-давно используется в куче систем (в том же 1С). Почему бы его не формализовать и не запихнуть в СУБД?