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

M>Для начала надо определиться с тем, что такое ОО, а потом уже приплести к этому DBMS и, возможно, R. На сколько мне известно даже четкого определения, что такое ОО, по сути не существует, все интуитивно понимают, что это такое, но сформулировать никто не может.
Ну формулировок хоть отбавляй и конкретных реализаций. Просто базируется все понятие ОО на высокоуровневых понятиях. Как в С++ нет понятия статических виртуальных методов, но это не значит, что такого нет вообще.
С другой стороны ОО для БД особенно в подходе хранения данных и развивается независимо от стандартов. Когда на стороне сервера можно будет применять весь арсенал компилируемых ООяП, тогда они наверное и будут в полной мере соответствовать ООБД.

Здравствуйте, <Аноним>, Вы писали:

А>версионник на OLTP занимает первые места, позволяет не ограничивать длину транзакции,

Ерунда это все. Длинные транзакции опасны в любой транзакционной системе. Long running transactions это совершенно отдельная головная боль, универсальным способом нормально не решаемая.

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

O>Специально написанные продукты разработки для Oracle,
...
O>JDeveloper

Специально для Oracle говоришь? JDeveloper это слегка подрихтованный небезызвестный JBuilder

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

B>А на дельфи и .NET столько всего придется делать, чтобы оно хоть как-то зажило.

Как любят говорить местные апологеты MSSQL — "ты просто не умеешь их готовить" — (C) твой

B>У них даже репортера своего нет,

Уже практически есть

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

A>Вопрос обширный (надо цитировать матчасть), но если в 2-х словах, то это использование одного языка в другом без дополнительных телодвижений.

Проблема только в том что SQLJ это не хитрые переключения контекста, а банальный препроцессор для джавы.

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

S> Ну формулировок хоть отбавляй и конкретных реализаций.
Приведи хоть одну..
На самом деле — есть, де факто, минимальный набор требований, которым должна удовлетворять система, чтобы иметь право называться объектной: наследование, инкапсуляция и полиморфизм. Обычно под ОО системой принято понимать именно систему объекты которой обладают этими свойствами.
Это я сейчас Sinclair'а вольно цитирую, если что он поправит..

Но как только объекты в таком виде необходимо сохранить, тут же вылезает ряд проблем связанных с эффективностью их обратного доставания. И здесь OODB проигрывают просто фатально. Причем на столько, что даже те конструкции, которые принято сейчас называть ООБД (хотя по большому счету это не так) этим трем требованиям удовлетворяют лишь отчасти, и все равно, этой части хватает чтобы сливать RDBMS со страшной силой, на более-менее широком классе задач.

S> С другой стороны ОО для БД особенно в подходе хранения данных и развивается независимо от стандартов.
Но пока как-то очень робко, и не невнятно. Каких либо определенных успехов в это направлении не наблюдается уже много лет.

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

AVK>Ерунда это все. Длинные транзакции опасны в любой транзакционной системе. Long running transactions это совершенно отдельная головная боль, универсальным способом нормально не решаемая.
Андрей, лучше не ввязывайся, с пониманием там бедулька...

Здравствуйте, <Аноним>, Вы писали:

А>"достать данные по человечески можно только через SQL" — ну это временно,
А>вот например Xquery, даже W3C считает вполне человеческим.
А>http://www.oracle.com/ru/oramag/december2003/index.html?dev_xquery.html
А>думаю скоро воткунт и в оракл и дб2 (если не уже)

А ты погляди кто этот стандарт предложил и догадайся где оно появится первым

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

S>> С другой стороны ОО для БД особенно в подходе хранения данных и развивается независимо от стандартов.
M>Но пока как-то очень робко, и не невнятно. Каких либо определенных успехов в это направлении не наблюдается уже много лет.

По поводу структур хранения данных я уже много раз проходился, и надстройка ООП над РБД легко строится особенно на локальных базах, но ввод Явы а тем более его синтеза с SQL на стороне сервера только радует и надеюсь, что данный поход будет развиваться и в Юконе.

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

AVK>Здравствуйте, <Аноним>, Вы писали:

А>>версионник на OLTP занимает первые места, позволяет не ограничивать длину транзакции,

AVK>Ерунда это все. Длинные транзакции опасны в любой транзакционной системе. Long running transactions это совершенно отдельная головная боль, универсальным способом нормально не решаемая.

ерунда все это конечно весомый оргумет, но хотелось бы деталей ... например для реализации оракла. т.е. при каких условиях, какой выйгрышь и т.п.
от Мерле кроме авторитетного заявления "Особенно учитывая каким образом Оракл мудрит с RW транзакциями при RC, а при snapshot'е все еще грустнее — там версионник сливает по определению." выудить ничего не удалось
мой аргумент см чуть выше.

Gt_

Здравствуйте, <Аноним>, Вы писали:
А>ерунда все это конечно весомый оргумет, но хотелось бы деталей ... например для реализации оракла. т.е. при каких условиях, какой выйгрышь и т.п.
А>от Мерле кроме авторитетного заявления "Особенно учитывая каким образом Оракл мудрит с RW транзакциями при RC, а при snapshot'е все еще грустнее — там версионник сливает по определению." выудить ничего не удалось
А>мой аргумент см чуть выше.
Просто Merle прямо в этом форуме уже дважды читал курсы лекций по особенностям поведения Oracle при выполнении RW транзакций. Вряд ли ему захочется делать это же в третий раз. По крайней мере до выхода нового оракла. А Андрей совершенно прав. Люители длинных RW транзакций положат как версионник, так и блокировочник. Если интересно почему — рекомендую все-таки пойти в книжный магазин. Трудно в форуме изложить 200 страниц теории. Вкратце и так все очевидно — deadlock это deadlock, независимо от стратегии изоляции. Поддержка изоляции съедает ресурсы, и чем длиннее транзакция, тем больше этих ресурсов. По поводу OLTP — версионники сливают. До выхода 10g говорить о выступлениях Oracle в OLTP было вообще смешно. Сейчас на tpc запощены результаты, которые позволяют Oracle надеяться на лучшее. Тем не менее, статус их до сих пор in review, а сопоставимая с МССКЛ цена транзакции в минуту достигается только в одном из варинатов. Я плохо знаю Оракл, поэтому не в курсе, какие такие изменения по сравнению с 9кой позволили им так вырваться вперед. Есть у меня подозрение, что они таки сделали блокировки со всеми теми эскалациями, которыми пугают юных оракл-девелоперов .

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


S>Вот когда будет работать что-то типа
S>Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
S>можно будет вернуться к этому разговору.

Для Оракл:

CREATE TYPE address AS OBJECT
  ( hno    NUMBER,
    street VARCHAR2(40),
    city   VARCHAR2(20),
    zip    VARCHAR2(5),
    phone  VARCHAR2(10) );

CREATE TYPE person AS OBJECT
  ( name        VARCHAR2(40),
    dateofbirth DATE,
    homeaddress address,
    manager     REF person );

CREATE TABLE persons OF person
  ( homeaddress NOT NULL,
      UNIQUE (homeaddress.phone),
      CHECK (homeaddress.zip IS NOT NULL),
      CHECK (homeaddress.city <> 'San Francisco') );

--Создаем объектный тип и объектную таблицу OID (не ROWID!!!!) primary key

CREATE TYPE employees_typ AS OBJECT 
   (e_no NUMBER, e_address CHAR(30));

CREATE TABLE employees_obj_t OF employees_typ (e_no PRIMARY KEY)
   OBJECT IDENTIFIER IS PRIMARY KEY;


-- Затем можно ссылаться на этот объект двумя способами:

CREATE TABLE departments_t 
   (d_no    NUMBER,
    mgr_ref REF employees_typ SCOPE IS employees_obj_t);

CREATE TABLE departments_t (
    d_no NUMBER,
    mgr_ref REF employees_typ 
       CONSTRAINT mgr_in_emp REFERENCES employees_obj_t);

Не вижу какая трудность по сохранению объектов и извлечению таковых? Такое ощущение, что вы ответы на ходу иногда пытаетесь придумать. Хотя как говорят: "Не уверен — не обгоняй!".

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

S>Есть у меня подозрение, что они таки сделали блокировки со всеми теми эскалациями, которыми пугают юных оракл-девелоперов .
Ну это-то вряд-ли , скорее причина в другом.
В чем именно станет известно после того, как появится документация на 10G. Но в целом, похоже, причина кроется в том, что в tpc-c тесте уже используются 64 процессорные машины, которые у интела появились относительно недавно. А это довольно серьезное изменение в архитектуре, которое, если брать БД, отражается на сканировании индексов, и прочей низкоуровневой рутине которой занимается ядро. У Oracle есть большой опыт работы с подобными системами на спарках и уже готовые решения, чего про MS не скажешь.

Опять-таки можно выудить немного полезной информации если посмотреть на tpc-c по внимательнее.
Обрати внимание на 5 и 6 позицию. Oracle и DB2 на практически идентичных машинах и одной и той же ОС, показывают практически одинаковый результат. Но если копнуть поглубже, то выясняется, что разница в железе все же есть. И та и та система в качестве хранилища использовала около 2000 винтов, но если DB2 понадобилось 26 фибероптических контроллеров, то Oracle, чтобы достичь той же производительности, понадобилось 66.
Из этого можно сделать вывод, что с, хорошей вероятностью, система ввода/вывода у Oracle все-таки работает не без проблем...

S>Просто Merle прямо в этом форуме уже дважды читал курсы лекций по особенностям поведения Oracle при выполнении RW транзакций. Вряд ли ему захочется делать это же в третий раз. По крайней мере до выхода нового оракла. А Андрей совершенно прав. Люители длинных RW транзакций положат как версионник, так и блокировочник. Если интересно почему — рекомендую все-таки пойти в книжный магазин. Трудно в форуме изложить 200 страниц теории. Вкратце и так все очевидно — deadlock это deadlock, независимо от стратегии изоляции. Поддержка изоляции съедает ресурсы, и чем длиннее транзакция, тем больше этих ресурсов. По поводу OLTP — версионники сливают. До выхода 10g говорить о выступлениях Oracle в OLTP было вообще смешно. Сейчас на tpc запощены результаты, которые позволяют Oracle надеяться на лучшее. Тем не менее, статус их до сих пор in review, а сопоставимая с МССКЛ цена транзакции в минуту достигается только в одном из варинатов. Я плохо знаю Оракл, поэтому не в курсе, какие такие изменения по сравнению с 9кой позволили им так вырваться вперед. Есть у меня подозрение, что они таки сделали блокировки со всеми теми эскалациями, которыми пугают юных оракл-девелоперов .

совсем не обязательно тут пересказывать ... достаточно одной ссылки, с указанием где зерно ... только умоляю — не на Мерле. я извиняюсь но он порет откровеную чушь (например топик про блокировки II).
из ваших строк я понял 2 проблемы — дедлог и ресурсы? так ?

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

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

в OLTP у блокировочника есть преимущество, но в реальной жизни очень редко встречается такая идеальная как в тестах задача и тут рульность версионности вылазит во всей красе. МС это видит и с хорошими темпами догоняет оракл по многим статьям. версионная модель Юкона вытеснит блокировочную, также как это роизошло в опен сорсе — posgres, firebird, mysql — я не знаю ни одной бд в опен сорсе блокировочника.

на данный момент как в прочем и много лет до этого оракл всех делает больше чем на 20% на любых тестах, поэтому я всетаки предлагаю хватит смешных аргументов типа "версионники сливают", оракл как был 30 лет назад первым (первая РСУБД) так и сейчас. девятку они поставили RACом и запихнули всякую ерунду, поэтому и было там пару процентов отстование, но это все реализация конкретной версии. посиотрите что было 5-10 лет назад. выйдет Юкон померием обе модели ок ?

ладно чо-то мы серьезные сегодня .. нада передать привет хорошему модератору Мерле

Gt_

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

O>Не вижу какая трудность по сохранению объектов и извлечению таковых?
Нууу.. В твоем примере нет
1. Наследования
2. Инкапсуляции
3. Полиморфизма
То есть, с точки зрения ООП, здесь и не объекты вовсе, а структуры. Я уже не говорю о виртуальных методах и прочих тонких материях.

Чтобы понять в чем здесь глобальная засада, возьмем например инкапсуляцию. Допустим в объекте есть метод, который возвращает какое-то значение по очень хитрому алгоритму. Построить сколь-либо эффективный индекс, по этому методу нельзя, так как нет доступа ни к реализации этого метода, ни к приватным полям, на основе которых метод и делает свои расчеты. Таким образом поиск объекта по значению этого метода выливается даже не просто в table scan, а в то, что каждый объект надо поднять из хранилища в память, вызвать метод, подождать пока он там что-то посчитает, проверить результат и положить обратно, если результат не удовлетворительный. В итоге перфоманс просто убойный.
Ясное дело, что это в принципе поддается некоторой оптимизации, но пока серьезных успехов на этом фронте не достигнуто.

O>Такое ощущение, что вы ответы на ходу иногда пытаетесь придумать.
Не доверяй им (ощущениям)..

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

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

A> только умоляю — не на Мерле. я извиняюсь но он порет откровеную чушь (например топик про блокировки II).
От Вас слышать обвинение в чуши несколько странновато...
Что же касается указанного сообщения, то там собственно мысль не моя, а некоего Фила Бернстайна, который, к слову, в мире БД будет по авторететнее того же Тома Кайта.

А>из ваших строк я понял 2 проблемы — дедлог и ресурсы? так ?
Нет, из его строк надо было понять, что неплохо бы пойти и почитать теорию... Или хотя бы понять, как работает любимый Оракл, зачем ему блокировки при такой чУдной версионности, и в каких местах его версионность встает колом, а блокировки не спасают, потому как умеют мало.

А>в OLTP у блокировочника есть преимущество
Сломался !!!

А>, но в реальной жизни очень редко встречается такая идеальная как в тестах задача и тут рульность версионности вылазит во всей красе.
В реальности как раз чистая версионность нервно курит, тот же Оракл при необходимости пользует блокировки, но не очень удачно...

А>версионная модель Юкона вытеснит блокировочную,

Да, надо совсем не знать как и что работает, чтобы говорить такое...

А> также как это роизошло в опен сорсе — posgres, firebird, mysql — я не знаю ни одной бд в опен сорсе блокировочника.
Согласен — это сильный аргумент...
Один клон Оракла, другой чистого версионника IB, а в третьем вообще транзакции толком и не появились..

А>на данный момент как в прочем и много лет до этого оракл всех делает больше чем на 20% на любых тестах,


А> оракл как был 30 лет назад первым (первая РСУБД) так и сейчас.

Вот это сильно!
А ничего, что когда Оракл еще умещался на дискету, ни чуть не менее реляционный DB2 ворочал гигабайты на майнфрейме?
Языком трепать — не мешки ворочить конечно, но меру-то знать надо...

А> девятку они поставили RACом и запихнули всякую ерунду,
Ага, нашли виноватого...


А> поэтому и было там пару процентов отстование,
Ну не пару, а 50...

А> посиотрите что было 5-10 лет назад.
Рулили DB2 и Terradata.


А>ладно чо-то мы серьезные сегодня .. нада передать привет хорошему модератору Мерле
Всегда рад благодарным ценителям..

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

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

O>>Не вижу какая трудность по сохранению объектов и извлечению таковых?
M>Нууу.. В твоем примере нет
M>1. Наследования
M>2. Инкапсуляции
M>3. Полиморфизма
M>То есть, с точки зрения ООП, здесь и не объекты вовсе, а структуры. Я уже не говорю о виртуальных методах и прочих тонких материях.

M>Чтобы понять в чем здесь глобальная засада, возьмем например инкапсуляцию. Допустим в объекте есть метод, который возвращает какое-то значение по очень хитрому алгоритму. Построить сколь-либо эффективный индекс, по этому методу нельзя, так как нет доступа ни к реализации этого метода, ни к приватным полям, на основе которых метод и делает свои расчеты. Таким образом поиск объекта по значению этого метода выливается даже не просто в table scan, а в то, что каждый объект надо поднять из хранилища в память, вызвать метод, подождать пока он там что-то посчитает, проверить результат и положить обратно, если результат не удовлетворительный. В итоге перфоманс просто убойный.
M>Ясное дело, что это в принципе поддается некоторой оптимизации, но пока серьезных успехов на этом фронте не достигнуто.

O>>Такое ощущение, что вы ответы на ходу иногда пытаетесь придумать.
M>Не доверяй им (ощущениям)..

Не соглашусь. Объект может опираться на несколько записей которые считываются по мере необходимости. А так как объект. Записи очень удобно хранить в обычных таблицах а доступ к полям через свойства с применением Inline, а в качестве первичного ключа Хэш таблицу. Для того что бы не считывать запись можно вычислять адрес этой записи в памяти если она загружена итд. И уверяю скороость очень высокая. Во всяком случае у меня на ФоксПро с ее дубовым форматом.

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

S> Объект может опираться на несколько записей которые считываются по мере необходимости.
Так это как раз то, что есть сейчас.
Объект в ручную, распихивается по реляционным табличкам.

S>Записи очень удобно хранить в обычных таблицах а доступ к полям через свойства с применением Inline,
Что есть в данном случае inline?

S> а в качестве первичного ключа Хэш таблицу.
Какие данные хешировать?

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

S>И уверяю скороость очень высокая. Во всяком случае у меня на ФоксПро с ее дубовым форматом.
Так у тебя там опять же структуры лежат, а не ОО объекты, раз ты к любым полям доступ имеешь.

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

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

S>> Объект может опираться на несколько записей которые считываются по мере необходимости.
M>Так это как раз то, что есть сейчас.
M>Объект в ручную, распихивается по реляционным табличкам.
На самом деле это даже саме то, т.к. хранить объект в сериализованном виде неоптимально, да и с точки зрения хранения данных и модификации
S>>Записи очень удобно хранить в обычных таблицах а доступ к полям через свойства с применением Inline,
M>Что есть в данном случае inline?
В С есть понятие инлайн, когда всесто вызова процедуры подставляется ее код, тем самым сокращая время вызова метода.

S>> а в качестве первичного ключа Хэш таблицу.
M>Какие данные хешировать?
Первичный ключ, обычно используются Б+ деревья для связи.
S>>Для того что бы не считывать запись можно вычислять адрес этой записи в памяти если она загружена итд.
M>В данном случае у записи нет значения как такового. Оно вычисляемое, причем алгоритм не известен. Пока метод явно не вызовешь значение записи узнать не возможно.
Не совсем так, все зависит от алгоритма, на первом то этапе можно выбрать оптимальный метод выборки, а уж доступ к полям уже происходит через свойства, которые загружают новые данные объекта если поле является ссылкой.

S>>И уверяю скороость очень высокая. Во всяком случае у меня на ФоксПро с ее дубовым форматом.
M>Так у тебя там опять же структуры лежат, а не ОО объекты, раз ты к любым полям доступ имеешь.
Я выше объяснял, что объекты хранить не нужно, только его данные, это несколько другой подход, но все же ОО.

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

S> На самом деле это даже саме то, т.к. хранить объект в сериализованном виде неоптимально, да и с точки зрения хранения данных и модификации
С точки зрения хранения как раз очень оптимально...

M>>Что есть в данном случае inline?
S> В С есть понятие инлайн, когда всесто вызова процедуры подставляется ее код, тем самым сокращая время вызова метода.
Да что это такое inline в С — я знаю, что есть инлайн в данном случае? Я так понимаю, ты хочешь подставлять уже посчитанное значение, но так не всегда можно сделать.

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

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

S> Не совсем так, все зависит от алгоритма,
Фокус в том, что ты не знаешь алгоритм.. Ясен хобот, что когда алгоритм известен можно просто с бешенной силой все прооптимизировать. Но в общем случае алгоритм не известен, он скрыт внутри объекта и кроме объекта о нем никто не знает. Его там может вообще не быть, это может быть константа, но об этом никто, кроме самого объекта даже не догадывается.

S> Я выше объяснял, что объекты хранить не нужно, только его данные, это несколько другой подход, но все же ОО.
Если понимать под данными приватные поля, то это уже не ОО. А если результаты вызовов методов, то нет гарантии, что они актуальны.