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

IT>>Причём тут кластер вообще? Или по твоему веб-фарм == кластер?

Д>э.... а мы под кластерами точно одно и то же понимаем?

У нас с тобой вообще наблюдается поразительное несходство в понимании чего бы то ни было.

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

IT> У нас с тобой вообще наблюдается поразительное несходство в понимании чего бы то ни было.

Бывает...
ну что ж, попробуем с другой стороны. В чем принципиальное отличие веб-ферм от кластеров, с твоей точки зрения?

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

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

Может ну его? Приводить ссылки на вики и цитировать Lingvo мне не хочется. Доказывать что-то уже порядком надоело. Давай завяывать, давай? Ну пожалуйста!

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

IT>Может ну его? Приводить ссылки на вики и цитировать Lingvo мне не хочется. Доказывать что-то уже порядком надоело. Давай завяывать, давай? Ну пожалуйста!

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

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

Д>Нет там ничего в подтверждение твоего утверждения...

... в твоём понимании.

Д>Ну если очень хочется, давай завязывать.

Ok, завязали.

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

Всё-таки оставил последнее слово за собой, хитрец

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

S>Хм. Не очень ясно, что же ты имеешь в виду. Я попробую развернуть здесь эту критику поподробнее:
S>- отсутствие внятной концепции метаданных. Классический SQL вообще не содержал средств работы с метаданными. Клиентское приложение должно было получить знания о таблицах/view и их колонках эзотерическим путем). Справедливости ради стоит отметить, что в новых версиях стандарта SQL работа с метаданными таки предусмотрена
Вопрос только насколько они действенны. Современная база данных это не только данные, но и поведение. Узнать о том, что данное поле заполняется автоматом с помощью триггера, можно только просмотрев реализацию триггеров. А информация о том что поле read only, или в каких случаях оно является read only, вполне полезно.
S>- малое внимание к связям. FK трактуются как декларативные ограничения, к которым довольно сложно получить доступ, в то время как это на самом деле first-class citizens. Фактически, объявление FK вводит новый тип данных — "ссылка на таблицу", и это должно быть очевидно и легкодоступно.
По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.
Ну например такой запрос вполне жизненен.

select *, ISNULL(organization.Name, citizen.Family) from document outer join organization on (document.signer = organization.id and document.sign_org=1)
outer join citizen on (document.signer = citizen.id and document.sign_org=0)
where document.signed is not null

FK — как "ссылка на таблицу" — недостаточен. Нужно что-то более полиморфное.
В принципе, в OODB это решается через наследование. Но тут легко получить, как ты выражаешься, выстрел в ногу. В случае оперативной памяти, мы легко получаем ссылку на экземпляр и его RTTI. В случае СУБД, экземпляр как таковой не инстанцирован, и получение экземпляра, или его ссылки — затруднено. IMHO Лучшим выходом в случае СУБД является явное указание конкретных типов который может адресовать ссылка. Указание же типа предка, подразумевает более широкий поиск возможного типа ссылки что не есть гуд.

S>- 100% отсутствие информации о структуре бинарных объектов. Тут уже точно пошла жесткая необходимость рыться в исходниках клиентского приложения для понимания сути blob.
S>Работы по поддержке пользовательских типов вместо blob и переносе хотя бы части семантики внутрь БД не слишком скоординированы. Насколько я знаю, попытки стандартизовать UDT есть, но реальная картина в мире СУБД печальна: каждый производитель тянет одеяло на себя. Кстати, стоит отметить полную бесперспективность данного подхода в отстутствие управляемой среды: исполнение пользовательского кода в контексте сервера, который должен обеспечивать высокую надежность — самоубийство.
Данные могут быть полуструктурированы(короче говоря, меняющеяся от blob'a к blob'у схема).

GZ>>2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.
S>Я бы не был так категоричен. Сама по себе реляционная модель не может обладать никакой эффективностью. Есть средства эффективной реализации некоторых выражений реляционной алгебры. Например, это индексы. Важно понимать, что индексы не являются частью реляционной модели.
Зависит от обстоятельств. Иногда оптимизаторы пользуются индексами как отношением.
S>Материализованное view — это паллиатив, попытка реализовать сразу несколько типов индексов, не встроенных в движок. Временные таблицы — это вообще нонсенс; это попытка обойти либо ограничения выразительности языка, либо ограничения оптимизатора. И если со вторым еще как-то можно смириться — оптимизаторы неуклонно совершенствуются, и нужда явно указывать способ хранения промежуточных результатов снижается, то проблема с первым напрямую связана с убогостью SQL. К этому пункту мы еще вернемся.
+1 Во первых, ты забыл вернуться к убогости SQL.
Во вторых, ты темповую таблицу меришь по реализации в MSSQL. Там ублюдочная реализация. Темповая таблица — это некоторый промежуточный результат для получения других конечных результатов и которая не требуют транзакционности. Данные для темповой таблицы могут быть собраны как внутри СУБД, так и с внешней стороны. А после этого ты можешь сделать несколько взаимосвязанных с этими промежуточными данными запросов. В MSSQL время жизни таких промежуточных данных — запрос. В Oracle — сессия. Во втором случае пользы больше. MARS, в принципе, должен решать эту проблему для внутренних данных, но не для внешних. И то, не полностью

S>Вместо расширения декларативной модели, комитет изобретает частные затычки — например, CTE. О, классно, мы теперь можем делать рекурсивные запросы, ура! Если бы SQL позволял писать table-valued функции с табличными параметрами, мы получили бы то же самое в качестве побочного эффекта. Увы и ах.
Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?

S>Это неверно. Инкапсуляция вовсе не означает криптологию: она фактически запрещает строить код, статически завязанный на подробности реализации, а вовсе не получать информацию о внутреннем устройстве кода. Ну, вот например, допустим компилятор С++ видит в некотором месте вызов метода A::a(). Соответствие областей видимости компилятор проверит первым делом, так что внешний код скомпилируется только если a() public, и т.п. Но сразу после выполнения этой проверки компилятор может забыть все эти модификаторы доступа. Если внутри этого метода всего лишь идет обращение к полю экземпляра, пусть даже и приватному, компилятор имеет полное право устранить вызов путем инлайнинга и выполнять прочие модификации. С точки зрения С++, private прячет интимности от кода, но не от компилятора. С точки зрения управляемой среды, оптимизатор всего лишь имеет права "врача, священника, и мужа" по отношению к коду хранимых сущностей, т.е. соответствующий reflection permission. Это никак не нарушает инкапсуляцию.
Я абсолютно согласен. Это было просто утверждение о реализации большинства OODB.

GZ>>6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.
S>Вот это я не очень понимаю. Это же неудачное стечение двух совершенно различных обстоятельств: отстутствие достаточно декларативного языка запросов, и отсутствие оптимизатора, который мог бы воспользоваться избыточной информацией в индексах.
Проблема в том, что объект в оперативной памяти может быть достаточно большим. Его основная цель быть полноценным экземпляром. Это процесс бесплатный если сравнить с падением производительности при чтении большого объекта в таблице. Поэтому, конечный тип может быть эфективнее если он сборный из двух и более таблиц. Вторая проблема — наследование. Join — отнюдь не самая легкая операция в СУБД, если хранить предка и потомка раздельно. В тоже время, если их хранить вместе, также невесело. На каждый тип свой запрос и свой проход по данным. При требовании, что объект поднятый с БД должен быть полноценным экземпляром подразумевает избыточность действий и данных.

GZ>>7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.
S>Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием.
Здесь выйгрыш в том, что код более гибкий. На СУБД — у нас одна обработка. На клиенте, который объект получил через web-сервис, другая обработка. В каждом слое приложения можно сделать свою обработку бизнес-объекта в соответсвии с целью, которая заложена в бизнес-логику слоя. При этом, они зависимы только по интерфейсу бизнес-объекта, а не по методам его получения или методам работы с хранилищем.
S>Вообще, конечно же, статическая трактовка данных, принятая в RDBMS, сильно упрощает жизнь. Хотя это вовсе не 100% упрощения, и проблемы с сопровождением все равно есть. В самом оптимистичном случае, когда вносимые изменения не требуют модификации фактологической модели (т.е. мы, к примеру, все еще считаем "телефон" скалярным атрибутом сущности "клиент", а не заменяем это на связь многие-ко-многим), все равно есть риск нарваться на несовместимость логики, когда данные находятся в состоянии, валидном с точки зрения предыдущей модели, но недостижимом в новой модели.
Гы-гы. Собственно с помощью компонентной объектной модели можно скрыть факт о связи многие к многим, и о несовместимости логики за интерфейсом. Возможности не бесконечны но все таки более эффективны, чем при РСУБД.

GZ>>9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
S>На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.
Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.

GZ>>9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.
S>?
GZ>>10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
S>?
Фактически — это одно и тоже. Уже давно языки пытаются вынудить показывать интерфейс, а не реализацию. Реализация скрыта. Соответсвенно, клиенту подставляется тот интерфейс который ему нужен, а не тот который может обеспечить реализация в последней версии.

GZ>>12. Для оптимизатора запросов важна подробная информация.
S>Ну, с этим никто не спорит. Вообще здесь, как и много где еще, работает правило Парето: 80% успеха обеспечивается 20% усилий.
S>В частности, для RDBMS оказывается, что даже минимальной статистики (типа количества уникальных значений ключа индекса) достаточно для выбора планов, близких к оптимальным. Следующий шаг — построение гистограмм распределений — позволяет добиться еще некоторого сокращения лишних операций. Дополнительная семантическая оптимизация на основе данных о констреинтах позволяет улучшить планы в граничных случаях. В принципе, уже этой информации достаточно оптимизатору для того, чтобы почти не оставить шансов человеку на улучшение запросов.
То что ты описал, в принципе, оставляет шансы для человека. Данные редко изменяют свою статистику. А вот учет кэша страниц в оперативной памяти — это уже каюк.

S>Вменяемый ODBMS оптимизатор должен справляться не хуже. Все, что ему нужно — доступ к телу используемых методов. Все равно в итоге идет обращение к полям экземпляров и классов; поэтому особенной разницы в оптимизациях нет. С одной стороны, все кажется сложным — типичный "объектный" запрос будет иметь значительно более сложное AST, чем типичный реляционный.
Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты? SQL с одной стороны много не позволяет. Хотя в нем можно делать предикаты о которых не существует статистики, но это редкость. Будет ли это редкостью в коде OODB, еще вопрос.

S>С другой стороны, есть очень хороший шанс использовать кэш. В частности, если посмотреть на статистику Jit для Януса, то окажется, что в этом приложении обработано всего ~2600 методов. Новые методы будут появляться крайне редко (относительно количества вызовов этих методов), а, значит, можно не выполнять дорогостоящий анализ каждый раз.
IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать. И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.

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

GZ>Вопрос только насколько они действенны. Современная база данных это не только данные, но и поведение. Узнать о том, что данное поле заполняется автоматом с помощью триггера, можно только просмотрев реализацию триггеров. А информация о том что поле read only, или в каких случаях оно является read only, вполне полезно.
Да, действительо, все еще хуже, чем я описал. Часть метаинформации, описанная в императивном виде, вообще не поддается получению.
GZ>По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.
С точки зрения реляционки, все (почти) в порядке. Все будет полностью в порядке только при расширении трактовки понятия Foreign Key так, чтобы оно могло ссылаться не только на хранимую таблицу, но и на произвольное реляционное выражение.
GZ>Ну например такой запрос вполне жизненен.
GZ>

GZ>select *, ISNULL(organization.Name, citizen.Family) from document outer join organization on (document.signer = organization.id and document.sign_org=1)
GZ>outer join citizen on (document.signer = citizen.id and document.sign_org=0)
GZ>where document.signed is not null
GZ>

GZ>FK — как "ссылка на таблицу" — недостаточен. Нужно что-то более полиморфное.
Это мы уже забредаем на территорию ODBMS. Реляционка пренебрегает такими концепциями, как наследование и полиморфизм.

GZ>В принципе, в OODB это решается через наследование. Но тут легко получить, как ты выражаешься, выстрел в ногу. В случае оперативной памяти, мы легко получаем ссылку на экземпляр и его RTTI. В случае СУБД, экземпляр как таковой не инстанцирован, и получение экземпляра, или его ссылки — затруднено. IMHO Лучшим выходом в случае СУБД является явное указание конкретных типов который может адресовать ссылка. Указание же типа предка, подразумевает более широкий поиск возможного типа ссылки что не есть гуд.
Нет, тут никакой проблемы нету. Дерево наследования — всего лишь дерево; способ оптимизации для операции "получить всех потомков" хорошо известен — транзитивное замыкание.
Запрос, приведенный тобой выше, будет записан значительно короче, но при выполнении автоматически раскрыт в

select *, ResponsibleParty.Name from document outer join 
(
  select id, Name from organization
  union 
  select id, Family from citizen
)
where document.signed is not null

GZ>Данные могут быть полуструктурированы(короче говоря, меняющеяся от blob'a к blob'у схема).
Это само по себе уже не так сложно, как вообще поддержка хоть какой-то семантики о блобах. Вот, к примеру, модный Full-text Search от микрософта предлагает в таких случаяз заводить в таблице рядом с image полем колонку с расширением файла! Хоть бы MIME-тип использовали, позорники.
GZ>Зависит от обстоятельств. Иногда оптимизаторы пользуются индексами как отношением.
Неважно, как именно оптимизаторы пользуются индексами. С точки зрения реляционной алгебры индексов не существует. Точно так же, как арифметика прекрасно "работает" без оглядки на схемы ускоренного сложения, применяемые в электронике.
GZ>+1 Во первых, ты забыл вернуться к убогости SQL.
Не, не забыл. Просто слово это не написал.
GZ>Во вторых, ты темповую таблицу меришь по реализации в MSSQL. Там ублюдочная реализация. Темповая таблица — это некоторый промежуточный результат для получения других конечных результатов и которая не требуют транзакционности.
Пойми, что без ленивой семантики временная таблица — ублюдок вне зависимости от способа реализации. Ее где-то надо хранить, потому что к моменту ее использования информация о способе получения данных безнадежно потеряна. Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.

GZ>Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?
Точно так же, как и для обычных join. А что тебя беспокоит?

GZ>Я абсолютно согласен. Это было просто утверждение о реализации большинства OODB.
Ну, потому это большинство и делит %0.01 рынка обработки данных.
GZ>Проблема в том, что объект в оперативной памяти может быть достаточно большим. Его основная цель быть полноценным экземпляром.
Неа. В хорошей ODBMS должны реально инстанцироваться лишь немногие объекты.
GZ>Это процесс бесплатный если сравнить с падением производительности при чтении большого объекта в таблице. Поэтому, конечный тип может быть эфективнее если он сборный из двух и более таблиц. Вторая проблема — наследование. Join — отнюдь не самая легкая операция в СУБД, если хранить предка и потомка раздельно. В тоже время, если их хранить вместе, также невесело. На каждый тип свой запрос и свой проход по данным. При требовании, что объект поднятый с БД должен быть полноценным экземпляром подразумевает избыточность действий и данных.
Это все происходит от того заблуждения, что основной операцией является разрешение ссылки. Конечно, если не давать описывать более осмысленные операции, то во-первых придется руками указывать СУБД какой объект поднимать, а во-вторых ей придется поднимать полный объект, т.к. она не знает, что именно я собрался с ним делать.
Вот, например, РСУБД при удачном стечении обстоятельств может вообще обходиться без чтения таблицы ("инстанцирования кортежей"), если для выполнения запроса хватает данных в индексе. Точно так же должна работать ODBMS — достаточно дать ей доступ к коду. Тогда она сможет строить код, который работает в основном с данными на диске, но так, чтобы конечный результат был неотличим от полного перебора честных инстансов с соответствующими вызовами.
S>>Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием.
GZ>Здесь выйгрыш в том, что код более гибкий. На СУБД — у нас одна обработка. На клиенте, который объект получил через web-сервис, другая обработка. В каждом слое приложения можно сделать свою обработку бизнес-объекта в соответсвии с целью, которая заложена в бизнес-логику слоя. При этом, они зависимы только по интерфейсу бизнес-объекта, а не по методам его получения или методам работы с хранилищем.
Согласен, это так.
GZ>Гы-гы. Собственно с помощью компонентной объектной модели можно скрыть факт о связи многие к многим, и о несовместимости логики за интерфейсом. Возможности не бесконечны но все таки более эффективны, чем при РСУБД.
Совершенно верно. Об этом я и говорю — чувство легкости при внесении изменений в РБД является ложным. Хорошо спроектированную ОБД будет не труднее, а легче поддерживать и развивать (а иначе нафига мы вообще это все придумываем???)

S>>На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.
GZ>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.
Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
GZ>Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты?
Ну, во-первых они не должны иметь побочных эффектов, иначе — сразу InvalidOperationException.
GZ>SQL с одной стороны много не позволяет.
Во-вторых, главное — выкусить "индексируемую" часть предиката, а остальное оставить в виде residual и честно вычислять.
GZ>Хотя в нем можно делать предикаты о которых не существует статистики, но это редкость. Будет ли это редкостью в коде OODB, еще вопрос.
Действительно, вопрос. Пока что мы говорим о гипотетической ООСУБД для гипотетической ООБД, и довольно сложно представить для чего это вообще будет применяться и как там ляжет карта со статистикой. Будет ли там 5000 классов в сложной иерархии? Будут ли там чудовищно сложные методы с рекурсивными вызовами, циклами и прочей ерундой? И т.д.

GZ>IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать.
А что значит "поубивать"?
GZ>И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.
Ты имеешь в виду сбор мусора?

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

GZ>>По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.
S>С точки зрения реляционки, все (почти) в порядке. Все будет полностью в порядке только при расширении трактовки понятия Foreign Key так, чтобы оно могло ссылаться не только на хранимую таблицу, но и на произвольное реляционное выражение.
Не понял???? Ты предлагаешь вернуться к ad-hoc запросам?

S>Это мы уже забредаем на территорию ODBMS. Реляционка пренебрегает такими концепциями, как наследование и полиморфизм.
Ага. Вместо этого она предлагает ad-hoc запросы и трансформацию схемы.

S>Нет, тут никакой проблемы нету. Дерево наследования — всего лишь дерево; способ оптимизации для операции "получить всех потомков" хорошо известен — транзитивное замыкание.
Жуть.

S>Запрос, приведенный тобой выше, будет записан значительно короче, но при выполнении автоматически раскрыт в
S>

S>select *, ResponsibleParty.Name from document outer join 
S>(
S>  select id, Name from organization
S>  union 
S>  select id, Family from citizen
S>)
S>where document.signed is not null
S>

Да уж. А запрос-то неприятный. У меня большие подозрения что оптимизатор не сможет развести union сквозь outer join(точнее не подозрения, на всякий случай проверил на MSSQL2005). А соответсвенно, не сможет включить в оптимизации планы в которых идет outer join(document, organization) и outer join(document, citizen) + union(res1,res2). При маленькой таблице document — это был бы лучший план. А в данном случае мы всегда обязаны поднимать и конкатенировать всех наследников.Запрос достаточно показателен.
Я имел ввиду что в OODB в качестве reference будет object, и как результат мы поднимем всю базу данных. И второе, к типу может быть подцеплен новый подтип. При этом это сильно может повлиять на работу запросов незаметно для разработчика.

S>Пойми, что без ленивой семантики временная таблица — ублюдок вне зависимости от способа реализации. Ее где-то надо хранить, потому что к моменту ее использования информация о способе получения данных безнадежно потеряна.
А смысл? Способ получения может быть не только внутренним, но и внешним.
S>Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.
Недетерменировано? Даже в случае с внутренними данными у нас получается все равно — чистая эвристика. Оптимизатор находит что такой подзапрос был, следовательно можно использовать именно его данные. Чудно. Но остается вопрос того, что исходные данные на момент второго запроса могли измениться. Как поступить оптимизатору, непонятно.

GZ>>Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?
S>Точно так же, как и для обычных join. А что тебя беспокоит?
Пока сам не разобрался. Пока придавлю эту тему.

GZ>>Проблема в том, что объект в оперативной памяти может быть достаточно большим. Его основная цель быть полноценным экземпляром.
S>Неа. В хорошей ODBMS должны реально инстанцироваться лишь немногие объекты.
Имеется ввиду ООП.

S>Это все происходит от того заблуждения, что основной операцией является разрешение ссылки. Конечно, если не давать описывать более осмысленные операции, то во-первых придется руками указывать СУБД какой объект поднимать, а во-вторых ей придется поднимать полный объект, т.к. она не знает, что именно я собрался с ним делать.
S>Вот, например, РСУБД при удачном стечении обстоятельств может вообще обходиться без чтения таблицы ("инстанцирования кортежей"), если для выполнения запроса хватает данных в индексе. Точно так же должна работать ODBMS — достаточно дать ей доступ к коду. Тогда она сможет строить код, который работает в основном с данными на диске, но так, чтобы конечный результат был неотличим от полного перебора честных инстансов с соответствующими вызовами.
Тут вопрос не в работе оптимизатора. Тут вопрос в самой системе хранения. С маленькими неширокими таблицами — sql работает быстрее. Проблема в том, что при table scan стоимость в прямой зависимости от объема объекта. Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.

GZ>>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.
S>Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
Чего-то я здесь его не увидел.

select otdel from otdel, (select avg(employer.age) as avg_age, employer.otdel 
from employer group by employer.otdel) emp, employer boss
where otdel.id=emp.otdel and otdel.boss=boss.id and emp.avg_age>boss.age

Так?

GZ>>Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты?
S>Ну, во-первых они не должны иметь побочных эффектов, иначе — сразу InvalidOperationException.
GZ>>SQL с одной стороны много не позволяет.
S>Во-вторых, главное — выкусить "индексируемую" часть предиката, а остальное оставить в виде residual и честно вычислять.
А если у нас что-то типа этого:

IEnumerable<IEnumerable<T>> GetEnumerator(int i)
{
while (i!=0)
{
switch (i)
{
    case 1:
       enumer=GetNewEnumFrom1(ref i);
       yield return enumer;
       break;
    case 2:
       enumer=GetNewEnumFrom2(ref i);
       yield return enumer;
       break;
......
}
}

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

GZ>>IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать.
S>А что значит "поубивать"?
Упрощение.
GZ>>И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.
S>Ты имеешь в виду сбор мусора?
Упрощение.
При семантической оптимизации(в некоторых источниках его причисляют к логической, что наверно правильней) рассчитываются диапазоны предикатов и при пересечении сокращается их число. То есть a>10 and b>=20 and a>b можно сократить до a>20 and b=20. Таким же образом могут сокращаються и промежуточные таблицы. При этом могут учитываться навешанные на данные констрейнты(но так мало кто умеет делать).

Здравствуйте, GlebZ, Вы писали:
GZ>Не понял???? Ты предлагаешь вернуться к ad-hoc запросам?
А мы от них никуда и не уходим. Напомню, что тут пока речь про реляционку и ее развитие, а не про то, чем ее заменить. Это просто логическое развитие реляционной алгебры, точнее ее реализации в рамках SQL.

S>>Нет, тут никакой проблемы нету. Дерево наследования — всего лишь дерево; способ оптимизации для операции "получить всех потомков" хорошо известен — транзитивное замыкание.
GZ>Жуть.
Ничего хуткого. Напомню: мы говорим про сверхмалые объемы редкоменяющихся данных. О, кстати — тогда ж можно сделать на Селковских диапазонах! И это все в предположении, что список классов не помещается полностю в памяти, и нам надо что-то оптимизировать. В жизни это будет обход дерева в памяти, и работать оно будет со скоростью света.
GZ>Да уж. А запрос-то неприятный. У меня большие подозрения что оптимизатор не сможет развести union сквозь outer join(точнее не подозрения, на всякий случай проверил на MSSQL2005). А соответсвенно, не сможет включить в оптимизации планы в которых идет outer join(document, organization) и outer join(document, citizen) + union(res1,res2).
Это очень странно. Эта оптимизация известна от зари времен. возможно, надо покрутить вокруг Union All. Но это все неважно — мы-то говорим о нашем оптимизаторе, а он прекрасно поймет, что ID глобально уникальны, и развалит запрос именно на union(join(A, B1), join(A, B2)).
GZ>Я имел ввиду что в OODB в качестве reference будет object, и как результат мы поднимем всю базу данных.
Ну естественно — если в качестве типа reference поставить object, оптимизатор присядет. Хотя я думаю, что и это вопрос разрешимый.
GZ>И второе, к типу может быть подцеплен новый подтип. При этом это сильно может повлиять на работу запросов незаметно для разработчика.
Этого я не боюсь. Нормальный tool с показом планов запросов является предметом первой необходимости для разработчика и DBA уже очень давно. Глупо надеяться, что в более сложной ODBMS удастся обойтись без него.

GZ>А смысл? Способ получения может быть не только внутренним, но и внешним.
С точки зрения RDBMS ничего внешнего нет. А если и есть — это тривиальный частный случай, когда действительно нужна временная таблица.
S>>Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.
GZ>Недетерменировано?
Все детерминированно. У тебя же не возникает проблемы с view?
GZ>Даже в случае с внутренними данными у нас получается все равно — чистая эвристика.
Никаких эвристик. Просто работа не с данными, а с выражением.

GZ>Тут вопрос не в работе оптимизатора. Тут вопрос в самой системе хранения. С маленькими неширокими таблицами — sql работает быстрее.
GZ>Проблема в том, что при table scan стоимость в прямой зависимости от объема объекта.
Проблема только в том, что table scan должен быть нужен как можно реже. Кроме того, даже при необходимости делать table scan можно избежать необходимости инстанцировать полные объекты.
GZ>Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.
В случае bookmark lookup матожидание количества зачитанных страниц примерно совпадает с количеством букмарков

GZ>>>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.
S>>Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
GZ>Чего-то я здесь его не увидел.
Чего ты не увидел?
GZ>

GZ>select otdel from otdel, (select avg(employer.age) as avg_age, employer.otdel 
GZ>from employer group by employer.otdel) emp, employer boss
GZ>where otdel.id=emp.otdel and otdel.boss=boss.id and emp.avg_age>boss.age
GZ>

GZ>Так?
Все правильно.
GZ>А если у нас что-то типа этого:
GZ>

GZ>IEnumerable<IEnumerable<T>> GetEnumerator(int i)
GZ>{
GZ>while (i!=0)
GZ>{
GZ>switch (i)
GZ>{
GZ>    case 1:
GZ>       enumer=GetNewEnumFrom1(ref i);
GZ>       yield return enumer;
GZ>       break;
GZ>    case 2:
GZ>       enumer=GetNewEnumFrom2(ref i);
GZ>       yield return enumer;
GZ>       break;
GZ>......
GZ>}
GZ>}
GZ>

GZ>Все функции не обновляют состояния но функции GetNewFrom1 и GetNewFrom2 содержат разные подзапросы.
Никто не спорит — можно и огурцом зарезаться. Подобный код приведет к потере эффективности, потому что его придется честно исполнять. Аналогом этому являются циклы и курсоры в MS SQL. Ими тоже можно довести сервак до кондратия. Ну, только в ОДБМС это будет работать несколько шустрее благодаря компиляции в нативный код, а не интерпретации скрипта.
GZ>Внедрить в движок операцию ветвления конечно можно, но статистики по нему не получишь. И трансформировать его безопасно, нужно методы придумывать(я по крайней мере о таких не слышал). Так что получается перечень побочных эффектов несколько больше. Или я до чего-то недопер?
Самое главное, что мы можем проинлайнить все эти GetNewEnumFrom1, и попробовать свернуть их во что-то человеческей
GZ>При семантической оптимизации(в некоторых источниках его причисляют к логической, что наверно правильней) рассчитываются диапазоны предикатов и при пересечении сокращается их число. То есть a>10 and b>=20 and a>b можно сократить до a>20 and b=20. Таким же образом могут сокращаються и промежуточные таблицы. При этом могут учитываться навешанные на данные констрейнты(но так мало кто умеет делать).
А, ну, семантика конечно тоже. Я про это читал. Но то, что я читал относительно семантических оптимизаций по отношению к ООДБМС — детский лепед. Люди тщательно пытаются придумать способ сообщить системе, что у менеджера зарплата выше 1000 уев, чтобы она при выполнении запросов типа select * from employee where salary < 0 их не сканировала.
Семантика играет огромную роль в распределенных базах, где сама отправка лишнего запроса — удовольствие дорогое. В обычном случае должна помогать все та же статистика. Семантические оптимизации, конечно, могут помочь откусить частные случаи (типа когда мы ищем null в not null поле). Относительно поглощения предикатов — не уверен, что оно будет встречаться в ОДБМС чаще, чем в RDBMS. Там разве что будут всякие "проносы эквивалентности", когда из ( a=b and b=с) делается (a=с and b is not null).

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

GZ>>Не понял???? Ты предлагаешь вернуться к ad-hoc запросам?
S>А мы от них никуда и не уходим. Напомню, что тут пока речь про реляционку и ее развитие, а не про то, чем ее заменить. Это просто логическое развитие реляционной алгебры, точнее ее реализации в рамках SQL.
Эффективность FK — на технологическом уровне легко увеличить. А вот эффективность custom sql запроса — труднее. И сразу встанет вопрос корректности такого custom sql запроса. Надеюсь каскадное удаление мы не отменяем?

S>О, кстати — тогда ж можно сделать на Селковских диапазонах!
Меня Селковские диапазоны уже бесят. Весьма дурной алгоритм. Лучше уж dewey или ordpath. Там возможности оптимальной работы с индексом больше, и линейное добавление объектов.

S>И это все в предположении, что список классов не помещается полностю в памяти, и нам надо что-то оптимизировать. В жизни это будет обход дерева в памяти, и работать оно будет со скоростью света.
GZ>>Да уж. А запрос-то неприятный. У меня большие подозрения что оптимизатор не сможет развести union сквозь outer join(точнее не подозрения, на всякий случай проверил на MSSQL2005). А соответсвенно, не сможет включить в оптимизации планы в которых идет outer join(document, organization) и outer join(document, citizen) + union(res1,res2).
S>Это очень странно. Эта оптимизация известна от зари времен. возможно, надо покрутить вокруг Union All. Но это все неважно — мы-то говорим о нашем оптимизаторе, а он прекрасно поймет, что ID глобально уникальны, и развалит запрос именно на union(join(A, B1), join(A, B2)).
Ага. Ты правильно указал что RDBMS не пользуется информацией о глобальной уникальности ключей. Еще они, что они не пользуются информацией о том, что связь является строго 1 к 1 и нечасто пользуются информацией, о том что наличие связанного ключа обязательно. Как результат outer join не переводится в inner join что сужает оптимизацию.

S>Ну естественно — если в качестве типа reference поставить object, оптимизатор присядет. Хотя я думаю, что и это вопрос разрешимый.
Вот именно. О том, что этот вопрос нужно решать я и говорю.

GZ>>И второе, к типу может быть подцеплен новый подтип. При этом это сильно может повлиять на работу запросов незаметно для разработчика.
S>Этого я не боюсь. Нормальный tool с показом планов запросов является предметом первой необходимости для разработчика и DBA уже очень давно. Глупо надеяться, что в более сложной ODBMS удастся обойтись без него.
Решать концептуальную проблему только тулзами, по моему не очень хорошо. Решить вопрос в принципе легко. Нужно просто указать какие объекты могут быть подписантами, а какие нет. И не на уровне наследования, а атрибутивно.

S>Все детерминированно. У тебя же не возникает проблемы с view?
С обычными view? Возникает. Допустим, у нас есть 5 запросов. Часть запроса одинакова для всех, и достаточно тяжелая. Эту одинаковую для всех часть в качестве отношения выгружаем в нетранзакционную таблицу. Осталные делаются относительно данной таблицы. Вероятность того, что для двух запросов оптимизатор окажется умнее человека, и будет сгенерирован два различных запроса более эффективных чем данный способ велика. Для пяти запросов ничтожна.

S>Проблема только в том, что table scan должен быть нужен как можно реже.
Зависит от многих обстоятельств.

S>Кроме того, даже при необходимости делать table scan можно избежать необходимости инстанцировать полные объекты.
Да я не говорю о инстанцировании полных объектов. Я говорю именно о доступе к данным. Если тебе нужно пройтись table scan по одному полю, и у тебя объект размером со страницу, то у тебя будет стоимость операций ввода-вывода в два раза больше чем в случае если объект занимает полстраницы.

GZ>>Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.
S>В случае bookmark lookup матожидание количества зачитанных страниц примерно совпадает с количеством букмарков
Для больших данных да. По мере уменьшения таблиц, мат.ожидание уменьшается а КПД кэша страниц увеличивается.

S>>>Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
GZ>>Чего-то я здесь его не увидел.
S>Чего ты не увидел?
тета-джоины

S>Никто не спорит — можно и огурцом зарезаться. Подобный код приведет к потере эффективности, потому что его придется честно исполнять. Аналогом этому являются циклы и курсоры в MS SQL. Ими тоже можно довести сервак до кондратия. Ну, только в ОДБМС это будет работать несколько шустрее благодаря компиляции в нативный код, а не интерпретации скрипта.
Циклы с детерменированным шагом можно легко перевести в запрос. Курсоры — это отношения. И даже ветвление можно представить в системе команд.

S>Самое главное, что мы можем проинлайнить все эти GetNewEnumFrom1, и попробовать свернуть их во что-то человеческей
+1. Только я подумал, в теоретически и такое можно перевести в систему команд с множествами+ветвления. Правда систему команд придется увеличивать, и трансформация запроса ограничена.

S>Относительно поглощения предикатов — не уверен, что оно будет встречаться в ОДБМС чаще, чем в RDBMS.
Я уверен. В случае RDBMS — у человека полный запрос перед глазами. В случае ODBMS — запрос инкапсулирован по задействованным объектам. Требования для оптимизатора ODBMS выше чем для RDBMS, а управляемость человеком хуже.

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

S>>О, кстати — тогда ж можно сделать на Селковских диапазонах!
GZ>Меня Селковские диапазоны уже бесят. Весьма дурной алгоритм. Лучше уж dewey или ordpath. Там возможности оптимальной работы с индексом больше, и линейное добавление объектов.
Кинь в меня ссылкой на них. А то туплю
GZ>Ага. Ты правильно указал что RDBMS не пользуется информацией о глобальной уникальности ключей.
Это от того, что нет способа ей об этом сказать.
GZ>Еще они, что они не пользуются информацией о том, что связь является строго 1 к 1 и нечасто пользуются информацией, о том что наличие связанного ключа обязательно.
А вот это они делать должны.
GZ>Как результат outer join не переводится в inner join что сужает оптимизацию.
И это тоже должно делаться. Неужто MS SQL Server до сих пор не заменяет outer на inner? В конкретном случае проблема именно семантическая; ODBMS оптимизатор может просто сразу генерировать запрос с юнион от джойнов.

GZ>Вот именно. О том, что этот вопрос нужно решать я и говорю.
Один из вариантов решения: включать тип в ссылку. Это позволит иметь статистику и вообще не сканировать незадействованные объекты, а также улучшать все прочие планы.

GZ>Решать концептуальную проблему только тулзами, по моему не очень хорошо.
Здесь нет никакой концептуальной проблемы. Эффективность ОДБМС должна точно так же рулиться индексами, как и RDBMS. И точно так же никакая СУБД не станет сама придумывать эти индексы.
GZ>Решить вопрос в принципе легко. Нужно просто указать какие объекты могут быть подписантами, а какие нет. И не на уровне наследования, а атрибутивно.
Я в это не верю. В ООП крайне не рекомендуется делать ссылку "или на бузину, или на дядьку". Предполагается, что у объектов есть что-то общее. А ты фактически предлагаешь вместо того, чтобы явно это "что-то общее" определять, использовать везде ссылки на object и атрибутами размечать, кто на кого должен ссылаться. Мне не нравится такая реализация. Я бы предпочел, чтобы семантика в первую очередь определялась объектной моделью.

S>>Все детерминированно. У тебя же не возникает проблемы с view?
GZ>С обычными view? Возникает. Допустим, у нас есть 5 запросов. Часть запроса одинакова для всех, и достаточно тяжелая. Эту одинаковую для всех часть в качестве отношения выгружаем в нетранзакционную таблицу. Осталные делаются относительно данной таблицы. Вероятность того, что для двух запросов оптимизатор окажется умнее человека, и будет сгенерирован два различных запроса более эффективных чем данный способ велика. Для пяти запросов ничтожна.
Как раз наоборот. Вероятность того, что один и тот же план будет оптимален в пяти запросах, значительно ниже, чем в двух.

GZ>Да я не говорю о инстанцировании полных объектов. Я говорю именно о доступе к данным. Если тебе нужно пройтись table scan по одному полю, и у тебя объект размером со страницу, то у тебя будет стоимость операций ввода-вывода в два раза больше чем в случае если объект занимает полстраницы.
Это если у меня нет индекса по этому полю

GZ>>>Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.
S>>В случае bookmark lookup матожидание количества зачитанных страниц примерно совпадает с количеством букмарков
GZ>Для больших данных да. По мере уменьшения таблиц, мат.ожидание уменьшается а КПД кэша страниц увеличивается.
Картина также улучшается для малоселективных запросов: очевидно, что если полная длина таблицы = 500 страниц, bookmark lookup для 10000 записей все равно больше этих 500 страниц не зачитает (ну кроме опять же экстремального случая бесконечно большой по сравнению с размером кэша таблицы)

GZ>тета-джоины
Тета-джойн — это операция соединения по произвольному предикату. Вот так перепиши запрос:

select otdel from otdel 
inner join (select avg(employer.age) as avg_age, employer.otdel from employer group by employer.otdel) emp (on otdel.id=emp.otdel)
inner join employer boss on (otdel.boss=boss.id and emp.avg_age>boss.age)

S>>Относительно поглощения предикатов — не уверен, что оно будет встречаться в ОДБМС чаще, чем в RDBMS.
GZ>Я уверен. В случае RDBMS — у человека полный запрос перед глазами. В случае ODBMS — запрос инкапсулирован по задействованным объектам. Требования для оптимизатора ODBMS выше чем для RDBMS, а управляемость человеком хуже.
Угу. Но это как раз то, чего мы хотим получить — нормальный abstraction с минимальным penalty.

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

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

S>>>О, кстати — тогда ж можно сделать на Селковских диапазонах!
GZ>>Меня Селковские диапазоны уже бесят. Весьма дурной алгоритм. Лучше уж dewey или ordpath. Там возможности оптимальной работы с индексом больше, и линейное добавление объектов.
S>Кинь в меня ссылкой на них. А то туплю
ordpath. Что касается dewey, то это облегченная версия ordpath без упорядоченности childs. В следующем номере rsdn будет статья.

S>Это от того, что нет способа ей об этом сказать.
+1
GZ>>Еще они, что они не пользуются информацией о том, что связь является строго 1 к 1 и нечасто пользуются информацией, о том что наличие связанного ключа обязательно.
S>А вот это они делать должны.
Oracle не умеет. MSSQL говорят иногда пользуется информацией о индексах. Надо проверять, знаю только по слухам.

GZ>>Вот именно. О том, что этот вопрос нужно решать я и говорю.
S>Один из вариантов решения: включать тип в ссылку. Это позволит иметь статистику и вообще не сканировать незадействованные объекты, а также улучшать все прочие планы.
+1.

GZ>>Решать концептуальную проблему только тулзами, по моему не очень хорошо.
S>Здесь нет никакой концептуальной проблемы. Эффективность ОДБМС должна точно так же рулиться индексами, как и RDBMS. И точно так же никакая СУБД не станет сама придумывать эти индексы.
Проблема не в индексах, а в количестве операций. И кстати, все дело движется к тому, что СУБД в будущем будет сам генерить индексы. Таких работ много.


S>Я в это не верю. В ООП крайне не рекомендуется делать ссылку "или на бузину, или на дядьку". Предполагается, что у объектов есть что-то общее. А ты фактически предлагаешь вместо того, чтобы явно это "что-то общее" определять, использовать везде ссылки на object и атрибутами размечать, кто на кого должен ссылаться. Мне не нравится такая реализация. Я бы предпочел, чтобы семантика в первую очередь определялась объектной моделью.
Ну можно декларативно обозначать, если класс реализует интерфейс ICanSign. К сожалению при написании OODBMS интерфейсы не были так популярны.

S>Как раз наоборот. Вероятность того, что один и тот же план будет оптимален в пяти запросах, значительно ниже, чем в двух.
Да нет. В пяти запросах их планы сокращаются, так как временное отношение уже существует. Его уже не нужно собирать.

GZ>>Да я не говорю о инстанцировании полных объектов. Я говорю именно о доступе к данным. Если тебе нужно пройтись table scan по одному полю, и у тебя объект размером со страницу, то у тебя будет стоимость операций ввода-вывода в два раза больше чем в случае если объект занимает полстраницы.
S>Это если у меня нет индекса по этому полю
Ну, индексы это отдельная песня. Хотя в зависимости от кластеризованности таблицы относительно индекса, СУБД часто считают дешевле пройти через TableScan. На 2 индексах в or предикате его вполне можно получить.

S>Картина также улучшается для малоселективных запросов: очевидно, что если полная длина таблицы = 500 страниц, bookmark lookup для 10000 записей все равно больше этих 500 страниц не зачитает (ну кроме опять же экстремального случая бесконечно большой по сравнению с размером кэша таблицы)
+1

GZ>>тета-джоины
S>Тета-джойн — это операция соединения по произвольному предикату. Вот так перепиши запрос:
Oops. Я думал что ты берешь именно частный случай декартового произведения. Такое тоже есть в оптимизаторах, когда он самовольно решает что декартово произведение лучший способ исполнения запроса.

Здравствуйте, Sinclair, Вы писали:
GZ>>Зависит от того, что мы имеем ввиду под хеш-индексом. Их достаточно много. Тот что здесь — имеетRe[18]: Настольная БД

Автор: GlebZ
Дата: 05.04.06

.
S>Че-то я почитал-почитал, так и не понял, как это хэш индекс даст упорядоченность ключей.
Sorry. Забыл про сообщения. Ключи упорядочены так как в значении содержится индекс ячейки в таблице, где лежат физический адрес строки.

Здравствуйте, GlebZ, Вы писали:
GZ>ordpath. Что касается dewey, то это облегченная версия ordpath без упорядоченности childs. В следующем номере rsdn будет статья.
Спасибо.
S>>А вот это они делать должны.
GZ>Oracle не умеет. MSSQL говорят иногда пользуется информацией о индексах. Надо проверять, знаю только по слухам.
Я имею в виду — использовать наличие not null FK для конверсии outer join в inner. Тут даже индекс не нужен.

GZ>Проблема не в индексах, а в количестве операций.
Пойми, что операций не будет больше, чем для РДБМС с аналогичной структурой. Как раз вся идея в том, чтобы в случае отсутствия наследования ОБД превращалась в нормальную реляционную, с аналогичной эффективностью. И только введение лишних сложностей будет приводить к плавному снижению производительности.
GZ>И кстати, все дело движется к тому, что СУБД в будущем будет сам генерить индексы. Таких работ много.
Ну, идея-то конечно интересная. Но это все равно сводится к тулам.

S>>Я бы предпочел, чтобы семантика в первую очередь определялась объектной моделью.
GZ>Ну можно декларативно обозначать, если класс реализует интерфейс ICanSign. К сожалению при написании OODBMS интерфейсы не были так популярны.
Ну так это же совсем другое дело! Лично я считаю, что наличие интерфейсов — вещь безусловно правильная и необходимая. Только интерфейсы позволят делать интегрируемые решения. Типа добавил к серверу модуль "Advanced HR" — и у тебя аттестации и карьерные планы. Добавил "Project Management" — и у тебя люди могут участвовать в проектах; причем неважно, стоят у тебя Simple HR или Advanced HR. Добавил Customer Relations — и у тебя в заказах не строчки "физ. лицо", а ссылки на кастомеров с историей взаимоотношений...

GZ>Да нет. В пяти запросах их планы сокращаются, так как временное отношение уже существует. Его уже не нужно собирать.
А, вот ты что имеешь в виду. Это только в том случае, если это отношение в каждом из запросов нужно нам все в том же виде. Шансов на это в 5 запросах подряд — очень мало. Скорее всего мы будем делать join этого отношения с разными отношениями; и есть хороший риск использовать в каждом случае только часть данных. Если бы это было view, то оптимизатор в каждом случае бы мог это учитывать.
Кроме того, помни, что хранимое отношение отжирает дорогие ресурсы.

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

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

GZ>>Oracle не умеет. MSSQL говорят иногда пользуется информацией о индексах. Надо проверять, знаю только по слухам.
S>Я имею в виду — использовать наличие not null FK для конверсии outer join в inner. Тут даже индекс не нужен.
В случае наличия DEFFERED режима(то бишь отложенной проверки ограничений целостности) — это невозможно.

GZ>>Проблема не в индексах, а в количестве операций.
S>Пойми, что операций не будет больше, чем для РДБМС с аналогичной структурой. Как раз вся идея в том, чтобы в случае отсутствия наследования ОБД превращалась в нормальную реляционную, с аналогичной эффективностью. И только введение лишних сложностей будет приводить к плавному снижению производительности.
Операций не будет больше с аналогичной структурой. Но в RDBMS значительно проще разбить таблицу на две, и использовать их связынными 1:1.

GZ>>И кстати, все дело движется к тому, что СУБД в будущем будет сам генерить индексы. Таких работ много.
S>Ну, идея-то конечно интересная. Но это все равно сводится к тулам.
Пока только предоставляются тулы для админа. В Oracle собирается информация о работе с базой, и на основании некоторого промежутка даются рекомендации. Ну а потом посмотрим. Возможность полной автоматизации все таки есть.

S>Ну так это же совсем другое дело! Лично я считаю, что наличие интерфейсов — вещь безусловно правильная и необходимая. Только интерфейсы позволят делать интегрируемые решения. Типа добавил к серверу модуль "Advanced HR" — и у тебя аттестации и карьерные планы. Добавил "Project Management" — и у тебя люди могут участвовать в проектах; причем неважно, стоят у тебя Simple HR или Advanced HR. Добавил Customer Relations — и у тебя в заказах не строчки "физ. лицо", а ссылки на кастомеров с историей взаимоотношений...
Ага. Только я бы еще рассмотрел вопрос миксинов. Фактически данную функциональность можно нормализовать в отдельную таблицу. Наверняка можно и логику выделить.

S>А, вот ты что имеешь в виду. Это только в том случае, если это отношение в каждом из запросов нужно нам все в том же виде. Шансов на это в 5 запросах подряд — очень мало. Скорее всего мы будем делать join этого отношения с разными отношениями; и есть хороший риск использовать в каждом случае только часть данных. Если бы это было view, то оптимизатор в каждом случае бы мог это учитывать.
Ну пример при котором это может быть эффективным, мы уже рассматривали. Наследование. Или если нужно подгрузить связанное дерево объектов.


S>Не, я о логическом операторе, а не о физическом. Просто обычно оптимизаторы тета-джойн превращают в конвеер из естественного ('=') соединения (или декарта, если нет подходящего предиката) и фильтра. Именно это я и имел в виду — в приведенном примере оператор > скорее всего будет выполняться самым последним и безо всяких индексов.
Не люблю я такие цикличные зависимости.