Здравствуйте, Merle, Вы писали:

M>Процитируй меня, пожалуйста или прекращай перевирать.

уже процитировал. Читай в другой ветке.
Если ты сам пишешь так, что тебя нельзя понять недвусмыслено — это уже не моя вина.

Здравствуйте, IT, Вы писали:

IT>Реальной распределённости при сегодняшнем уровне технологий добится очень сложно и то только за счёт гарантированных тормозов. Нужно транзакционно обновлять распределённое состояние объекта, т.е. делать что-то типа распределённого lock. Если эти требования снижать, то можно получить иллюзию распределённости. Например, мы можем принять такое допущение, что объект может изменяться только одним писателем, при этом доступ к объекту на время обновления его распределённого состояния разрешен, а возможными коллизиями мы можем пренебречь.

а что, при отсутствии ООП проблема транзакционного обновления данных снимается?

IT>Ты можешь привести какой-нибудь реальный пример таких других реализаций?

Смоллток. Схема. Руби.
Некоторые концепции ООП до сих пор еще не реализованы толком ни в одном языке.
этого достаточно?

IT>Синхронизация состояния.

а при отсутствии объектов, значит, всё синхронизируется само собой?

Здравствуйте, Дарней, Вы писали:

Д>зато наща беседа с тобой посвящена именно этой теме
Наша с тобой беседа посвящена этой теме в совершенно другой подветке, не надо здесь тему менять.

Д>нет никакой канонической реализации ООП, на соответствие которой язык можно проверить.
При чем здесь каноническая реализация?

Д> Можно сказать, что язык Х реализует ООП.
Именно это я и говорю.

Д>опиши хотя бы один.
Реляционка в хранилищах.

Здравствуйте, Дарней, Вы писали:

M>>Цитату, пожалуйста, где я говорил, что ООП ничего хорошего не светит.
Д>

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

Так где здесь слова, что "ООП ничего хорошего не светит"? Если это твоя интерпретация, то так и пиши.
Более того, в ответ на твою просьбу в следующем постинге, я четко объяснил что имел ввиду под этими словами, но ты почему-то предпоче это проигнорировать и упорно прицепился к тому, что я якобы пророчу крах ООП, хотя ничего подобного я не говорил. Так что сворачивай демагогию.

Д>Ну во первых, хватит обвинять меня во вранье.
Тогда прекращай врать.

Д> Я всего лишь пытаюсь выделить смысл в твоих словесных заграждениях.
Это невозможно сделать не читая моих сообщений.

Д>Во вторых, см пуктом выше. Как вот это твое высказывание следует понимать?
Я уже пояснил, с десяток сообщений назад, потрудись перечитать. Внимательно.

Д>Как следует понимать высказывание, что "ООП не работает в распределенных системах"?
Где я такое говорил? Мне что в каждом сообщении самого-себя цитировать? Если ты не прекратишь перевирать, то мы далеко не уедем.

Д>>В ответ я пока только услышал, что ООП не работает в распределенных системах
M>>Цитату, пожалуйста, где я такое говорил.
Д>

Д>>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Д>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

Ау, с приземленной логикой у нас как? В твоих логических построениях есть разница между "никак не работает" и "плохо работает"?

То есть, ни одной фразы, котрую я якобы говорил, ты найти не смог. Заканчивай демагогию...

Д>если до тебя всё еще не дошло, то мое высказывание эквивалентно следующему:
Д>"неясно излагать запутанные мысли"
И кто из нас после этого "неясно излагает запутанные мысли"?

Д>А еще хотелось бы напомнить, что придирки к построению фраз и грамматике оппонентов противоречат правилам данного форума.
Никаких придирок, просто хотелось понять, что ты имееешь ввиду. Однако раз ты углядел здесь придирку к построению фразы, то очевидно даже для тебя понятно, что твоя логика несколько.. запутана.

Д>приведи детально описанный пример таких изменений.
Не вижу чем тут может помочь детальный пример, очевидно ты и так прекрасно все понимаешь, просто пытаешься демагогию развести.

Д>значит, нужно всего лишь изменить контракт старых объектов.
То есть вместо того, чтобы просто написать новый объект, мы будем менять старый с риском порушить все что есть.
Как у нас там насчет "фундаментальных принципов построения ПО"?

Д>Мыши плакали, кололись и думали, как бы вывести породу кактусов получше, потому что больше в этой пустыне жрать нечего.
Может мыши просто подсели на кактус и не замечают ничего вокруг? Может им все-таки стоит перестать ограничивать свой рацион одним кактусом, тогда и иголки окажутся помягче...

Здравствуйте, Дарней, Вы писали:

Д>уже процитировал. Читай в другой ветке.
Да, там очень хорошо видно, что найти этих моих слов ты так и не смог, да и не сможешь, потому как этого я не говорил.
Так что заканчивай перевирать.

Д>Если ты сам пишешь так, что тебя нельзя понять недвусмыслено — это уже не моя вина.
Признаюсь, мне сложно написать недвусмыслено для человека, который не видит разницу между "не работает" и "плохо подходит", но сдается мне, это не моя вина.

Здравствуйте, Merle, Вы писали:

M>Более того, в ответ на твою просьбу в следующем постинге, я четко объяснил что имел ввиду под этими словами, но ты почему-то предпоче это проигнорировать и упорно прицепился к тому, что я якобы пророчу крах ООП, хотя ничего подобного я не говорил. Так что сворачивай демагогию.

покажи пальцем, где и что ты объяснил. Ссылку на сообщение и указание точных слов в нем — в студию!

Д>>Ну во первых, хватит обвинять меня во вранье.
M>Тогда прекращай врать.

Давай обойдемся без личных нападок? Или ты без этого жить не можешь?

Д>>>В ответ я пока только услышал, что ООП не работает в распределенных системах
M>>>Цитату, пожалуйста, где я такое говорил.
Д>>

Д>>>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Д>>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

M>Ау, с приземленной логикой у нас как? В твоих логических построениях есть разница между "никак не работает" и "плохо работает"?

я у тебя спросил что? Я спросил именно про те проблемы, которые не решаются никак. Потому что если проблемы решаются хоть как-то в рамках существующих технологий, и если они реально осложняют жизнь — значит, они будут решаться проще с развитием средств программирования. Возможно, вообще сойдут на нет.

Если ты решил ответить на вопрос, который я тебе не задавал — это твоя проблема.
А то мне это анекдот один напоминает.

А это правда, что Иванов выиграл "Волгу" в лотерею?
Правда. Только не Иванов, а Петров, и не в лотерею, а в карты, и не "Волгу", а бутылку, и не выиграл, а проиграл.

Попробуй отвечать на те вопросы, которые я задаю, а не те, на которые тебе удобно ответить. И никаких проблем непонимания больше не будет.

M>То есть, ни одной фразы, котрую я якобы говорил, ты найти не смог. Заканчивай демагогию...

в таком случае, постарайся сделать неимоверное усилие воли и сформулировать свои мысли четко.
Ты сказал, что "ООП движется к закату". Насколько можно понять, это должно обозначать, что применение ООП со временем будет уменьшаться и, вероятно, постепенно сведется к нулю. Я правильно угадал?
Варианты ответа: да, нет, не знаю, иное. Если последнее, то расшифровать подробно.

M>И кто из нас после этого "неясно излагает запутанные мысли"?

тебе что, придраться больше не к чему? С точки зрения правил построения предложений в русском языке оба варианта легальны и имеют один и тот же смысл. Если у тебя проблемы с русским языком — я тебе уже пояснил этот смысл, тебе нужна еще какая-то помощь?

M>Никаких придирок, просто хотелось понять, что ты имееешь ввиду. Однако раз ты углядел здесь придирку к построению фразы, то очевидно даже для тебя понятно, что твоя логика несколько.. запутана.

я просто вижу, что ты уделяешь слишком много внимания одной несущественной детали, которая не имеет никакого отношения к обсуждаемой теме. Логика прямая, как оглобля.

M>Не вижу чем тут может помочь детальный пример, очевидно ты и так прекрасно все понимаешь, просто пытаешься демагогию развести.

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

M>То есть вместо того, чтобы просто написать новый объект, мы будем менять старый с риском порушить все что есть.
M>Как у нас там насчет "фундаментальных принципов построения ПО"?

если добавление новых методов для работы с объектом угрожает порушить всю программу, то выход здесь один — лоботомия. Но это не входит в мою компетенцию.

M>Может мыши просто подсели на кактус и не замечают ничего вокруг? Может им все-таки стоит перестать ограничивать свой рацион одним кактусом, тогда и иголки окажутся помягче...

ну так ты предлагай варианты, я слушаю. Вариант "забить на инкапсуляцию и кодить все напрямую" мы уже рассмотрели. Может быть, у тебя есть еще мысли?

Здравствуйте, Merle, Вы писали:

Д>>нет никакой канонической реализации ООП, на соответствие которой язык можно проверить.
M>При чем здесь каноническая реализация?

Д>> Можно сказать, что язык Х реализует ООП.
M>Именно это я и говорю.

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

Д>>опиши хотя бы один.
M>Реляционка в хранилищах.

хорошо. А теперь объясни, какие принципиальные проблемы создает применение принципов ООП к этой задаче.
Не нужно отсылать меня к своим предыдущим сообщениям — там все равно нет никакой конкретной информации. Я кстати так и не дождался ответа на вопрос, почему расширение интерфейса объекта — это зло.

Здравствуйте, Merle, Вы писали:

это всё не имеет смысла. Читай в той ветке.

Здравствуйте, IT, Вы писали:

GZ>>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).
IT>Без понятия. К моему стыду я даже не знаю какую базу данных ты меешь ввиду
ReBar
У них кстати вышла по этому поводу интересная работа:
Lessons Learned from Managing a Petabyte

GZ>>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.
IT>И при чём тут ООБД? Или у неё здесь есть хоть малейший шанс вырваться вперёд?
Фактически да. OODB дает менее универсальное хранилище чем реляционка, но ее можно более эффективно подвернуть под конкретную задачу. Во первых, OODB — это уже готовый сервер приложений. Во вторых, сейчас наблюдается тенденция не хранения всего в единой универсальной базе данных с единым сервером приложений, а разделения функциональности по некоторой специализации. То есть вместо одного большого кластеризованного сервера приложений, некоторое кол-во поставщиков данных, и интеграционные сервера. А как поставщик данных, реляционка не слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни гибко предоставлять. Для этого делают надстройки. Уже сейчас есть тенденции в отказе от традиционных реляционных решений в пользу более слабоструктурированных xml(можно даже проследить по форуму баз данных, куда я иногда захожу).
Ну и конечно то, о чем я говорил вначале. ООDB, в рамках манифеста, не теряет идентификацию данных. OID, в отличие от primary key, является всегда синтетическим ключом, и может адресовать данные находящиеся на другом хосте. Это полезное свойство при интеграции.

Здравствуйте, Merle, Вы писали:

GZ>>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).
M>Подсказываю, это база написанная под конкретную задачу.
Нет. Objectivity/DB — коммерческая БД.

GlebZ wrote:
> GZ>>Игорь, угадай на чем построена самая большая в мире база
> данных(подсказываю, это не РСУБД).
> M>Подсказываю, это база написанная под конкретную задачу.
> Нет. Objectivity/DB — коммерческая БД.
В отчете написано, что им пришлось написать около миллиона строк на С++
для адаптации Objectivity к своей задаче. Так что она у них
коммерческая, но сильно подкрученая

GlebZ wrote:
> <http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml&gt;
> У них кстати вышла по этому поводу интересная работа:
> Lessons Learned from Managing a Petabyte
> <http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/proceedings/CIDR05.pdf&gt;
Понравилось:

The technology that best fits bookkeeping is an
RDBMS. As with the eventstore, the specifics are
abstracted, allowing more than one RDBMS
implementation to be used. Some large centers, like
SLAC (which has an Oracle site-license) use Oracle,
while most small institutes opt for an open-source
alternative, MySQL.
...
The main goal is to provide a compact, simple catalog
for users to find the most common data quickly, while
allowing access to the full archive when needed.

Что вполне логично — основная объектная база используется для хранения
больших объемов сложносвязанных массивных данных. В основных данных не
надо делать поиск по многим таблицам со сложными объединениями, пути
доступа к данным относительно фиксированы и нужны сложные
числодробитильные вычисления на клиентах. В общем, идеальные условия для
ООБД.

Однако для каталога, наоборот, нужны ad-hoc запросы и быстрое их
выполнение. Отсюда и использование РСУБД.

> А как поставщик данных, реляционка не
> слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни
> гибко предоставлять.
Проблема в том, что РСУБД пока лучше всего умеет поставлять
данные. И соответственно, лучше всего проявляет себя в задачах, где
нужно быстро и эффективно искать нужные данные.

ООБД позволяет быстро обрабатывать сложные данные, но плохо умеет их
искать.

> Для этого делают надстройки. Уже сейчас есть
> тенденции в отказе от традиционных реляционных решений в пользу более
> слабоструктурированных xml(можно даже проследить по форуму баз данных,
> куда я иногда захожу).
Скорее свидетельство buzzword'нутости...

Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:
>> GZ>>Игорь, угадай на чем построена самая большая в мире база
>> данных(подсказываю, это не РСУБД).
>> M>Подсказываю, это база написанная под конкретную задачу.
>> Нет. Objectivity/DB — коммерческая БД.
C>В отчете написано, что им пришлось написать около миллиона строк на С++
C>для адаптации Objectivity к своей задаче. Так что она у них
C>коммерческая, но сильно подкрученая
Вообще-то 5 миллионов. Но у них это реализация задачи

GlebZ wrote:
> C>В отчете написано, что им пришлось написать около миллиона строк на С++
> C>для адаптации Objectivity к своей задаче. Так что она у них
> C>коммерческая, но сильно подкрученая
> Вообще-то 5 миллионов. Но у них это реализация задачи
Там где-то в начале было написано, что для обхода ограничений
Objectivity и подгонку под задачу потратили миллион строк кода.

Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:
>> C>В отчете написано, что им пришлось написать около миллиона строк на С++
>> C>для адаптации Objectivity к своей задаче. Так что она у них
>> C>коммерческая, но сильно подкрученая
>> Вообще-то 5 миллионов. Но у них это реализация задачи
C>Там где-то в начале было написано, что для обхода ограничений
C>Objectivity и подгонку под задачу потратили миллион строк кода.
Ты об этом?

The commercial ODBMS provided a powerful database
engine including catalog, schema management, data
consistency and recovery, but it was not deployable into a
system of BaBar’s scale without extra effort. Half a
million lines of complex C++ code were required to
customize it and to implement needed features that did not
come with the product.

Здравствуйте, Cyberax, Вы писали:

C>Что вполне логично — основная объектная база используется для хранения
C>больших объемов сложносвязанных массивных данных. В основных данных не
C>надо делать поиск по многим таблицам со сложными объединениями, пути
C>доступа к данным относительно фиксированы и нужны сложные
C>числодробитильные вычисления на клиентах. В общем, идеальные условия для
C>ООБД.
Ты не то посмотрел. Там есть конкретный абзац почему была выбрана Objectivity

An object oriented approach seems to be the most
natural way to model HEP data, where complex many-tomany
relationships are commonplace. As explained
above, the persistency system has to also provide multipetabyte
scalability. None of the RDBMSes available in
mid-nineties offered any of these features (and they do not
appear to meet all these requirements even today). The
decision to use an Object Oriented Database Management
System – Objectivity/DB followed recommendations
from a study at CERN [14]. ODBMS technology seemed
to best fit BaBar’s needs of scalability, complexity and
C++ bindings. Also, the thick-client thin-server
architecture and distributed features seemed well suited to
scaling, in contrast with the traditional, server-heavy
RDBMS approach.

Последнее предложение наиболее интересное.

C>Однако для каталога, наоборот, нужны ad-hoc запросы и быстрое их
C>выполнение. Отсюда и использование РСУБД.
Каталог сам маленький. 3 гига.

>> А как поставщик данных, реляционка не
>> слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни
>> гибко предоставлять.
C>Проблема в том, что РСУБД пока лучше всего умеет поставлять
C>данные. И соответственно, лучше всего проявляет себя в задачах, где
C>нужно быстро и эффективно искать нужные данные.

C>ООБД позволяет быстро обрабатывать сложные данные, но плохо умеет их
C>искать.
Все правильно. Основной плюс РСУБД — действительно ad-hook запросы в строго нормализованном хранилище. Только на больших данных для увеличения производительности некоторых, особо криминальных, транзакций приходится денормализовать, и некоторая возможность ad-hook запросов теряется.
И еще возникает вопрос в том, что такое сложные данные. Один пример(достаточно простой) я уже показывал:

Есть юридические лица. Есть физические лица. У них есть общие аттрибуты, есть разные аттрибуты. А у документа — есть свойство подписант, в роли которого может выступать и юридическое лицо, и физическое.

Такое легко решается.
Другой пример, более криминальный: есть папка. В ней лежат документы. У каждого из них свой набор аттрибутов. Каким запросом можно получить все документы лежащие в конкретной папке? В принципе такое в реляционной модели вообще не опишешь. Но если у тебя объектная модель с наследованием, или слабоструктурированная xml, то такое очень просто решается. Так что в ограничения реляционки натыкаться приходится достаточно часто.

Здравствуйте, IT, Вы писали:


GZ>>>>А кто сказал что в распределенной среде ООБД плохо живется?
IT>>>А кто сказал что хорошо?
GZ>>Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.

IT>И какое это имеет отношение к ООБД?
Сорри. Читать не распределенной среды а OOБД. Очепятка.

Здравствуйте, IT, Вы писали:

Д>>существует и давно применяется CORBA. Существует и применяется .NET Remoting,
IT>Ты путаешь, это всё не распределённый ООП. В данном случае его можно было бы назвать удалённый, но не распределённый. Распределённый — это когда состояние твоей объектной модели размазано по нескольким компьютерам и любой объект или его часть может одновременно находится в нескольких местах.
CORBA — может быть распределенной.

Здравствуйте, shuklin, Вы писали:
S>Ок. Давайте подискутируем на эту тему. Меня она очень интересует как разработчика собственной ООСУБД/БЗ
Давайте. Меня это интересует в той же степени.

S>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.
Гм. Тогда совершенно непонятно, зачем вообще придумывать какую-то ОБД. Ведь неинкапсулированные данные и так ездят сумасшедшими темпами — десять тысяч обработанных заказов в минуту. И это на потребительском железе, т.е. машинке типа той, с которой я это пишу!
S>Действительно строить индексы по вычисляемым полям объектов занятие не для слабонервных. Но ведь и РБД это не умеют.
Почему же это не умеют??? Еще как умеют.
S>Это просто очень нетривиальная задача, не зависимо от того сеть или таблица является физическим уровнем для хранения полей объектов.
Нетривиальность тут совсем не здесь
S>В своей ОБД я пришел к следующему.
S>- инкапсуляция не рекомендуется к применению. Поля объекта открыты для доступа независимо от методов самого объекта. К этим полям система может обращаться не инстанциируя сам объект.
Таким образом, ты спустил ООП в мусорную корзину. Если объекты устроены таким образом, то все преимущества ООП недостижимы, а весь полиморфизм сводится к выбору подходящей хранимой процедуры.
S>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта. В этом случае программист отгребает все от ручной сериализации и прочих недостатков, о которых ты намекаешь. Согласен. Зато бинарная сериализация действительно быстрее.
Это совсем странно.
S>Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.
Этот выбор и так есть — RDBMS супротив самописанного хранилища.
S>Теперь расмотрим VIEW как аналог инкапсуляции в РБД. Я поддерживаю объектные VIEW.
View не является аналогом инкапсуляции. В каком-то смысле, можно его и так рассматривать, но в существующем виде это скорее инструмент декомпозиции. В SQL с декомпозицией вообще очень плохо; в большинстве случаев все запросы пишутся прямо поверх самого нижнего уровня. От этого стоимость внесения изменений в систему зашкаливает, и в некоторых случаях начинаются моления на схему данных. Типа — вот этот бы столбец убрать нафиг, ибо никто не помнит, для чего он был придуман, а нельзя — вдруг отчеты посыплются.

Так вот, view позволяют хотя бы немного "расчленить" запросы на более читабельные части.

К сожалению, параметризованные view не предусмотрены стандартом, поэтому всяк производитель реализует "table-valued functions" по-своему.
В свете этого, не вполне ясно, какую именно проблему предполагается решать при помощи твоих объектных VIEW.

S>Поддержка реализована на двух уровнях.
S>- на уровне модели данных один и тот же аттрибут может быть чайлдом нескольких экземпляров объектов. Это позволяет формировать объекты являющиеся JOIN аттрибутов других объектов, без потери идентичности и возможности адресации аттрибутов по указателям.
Бр-р. Это уже какая-то мистика начинается. Не представляю себе, как это атрибут ухитряется разделяться между экземплярами.

S>- на уровне собственно экземпляров — благодаря поддержке самим .NET множественного наследования интерфейсов и известным ООП паттернам, типа мост, адаптер, обертка, ...

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

S>Во всех версиях на "семантическом уровне" благодаря возможности окраски связей графа с помощью ИД можно проводить операции близкие к JOIN в РБД. Тоесть что то типа WHERE ИД_СВЯЗИ(связь) = ИД_ОБЪЕКТА(объект) А это в Cerebrum было всегда. Даже в VNPI-99

Если отказаться от type inference, который так ловко был придуман в OQL, то самое сложное — это изобретение эффективной стратегии выполнения запросов типа:

select * from IEmployee e where e.Position.CompensationPolicy.GetBonusAmount(e, ProjectStatus.AlphaCompleted)>500;

Подразумеваются следующие интерфейсы:

public interface IEmployee
{
  IPosition Position { get; set; }
}
public interface IPosition
{
  ICompensationPolicy CompensationPolicy { get; }
}
public interface ICompensationPolicy 
{
  Money GetBonusAmount(IEmployee employee, ProjectStatus projectStatus);
}

На первый взгляд, это вообще труба, т.к. мы оперируем исключительно виртуальными методами. Кроме того, у нас явно есть коррелированный параметр — в дополнение к параметру-константе.
В итоге, способов выполнить запрос, кроме полного перебора, не видно. Однако, если "раскрыть скобки", то теоретически возможно избавиться как минимум от полиморфизма — достаточно заменить всякий источник данных на union из соответствующего набора сканирований типов. А это откроет дорогу к применению следующих методик оптимизации.
Пока что СУБД, способная это делать, мне неизвестна.

Здравствуйте, shuklin, Вы писали:
S>Аналогично. В отличие от педантов, для которых секурити (инкапсуляция) важнее функциональности, я считаю основным достоинством ООП полиморфизм. А вот его то я поддерживаю в своей БД максимально.
Ты не можешь поддерживать полиморфизм, не поддерживая инкапсуляции. Поддержка полиморфизма требует развязки интерфейса и его реализации, а при отсутствии инкапсуляции это невозможно. Слишком велико будет искушение писать внешний код (хотя бы те же запросы) в терминах публичных полей, а не виртуальных методов/свойств. Вот тебе и весь полиморфизм — нельзя будет поменять реализации этих методов/свойств, т.к. есть внешний код, завязанный на внутреннее устройство объекта.