dmz>>Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?

E>Был такой язык -- Object Query Language назывался. Почил в бозе вместе с породившим его стандартом ODMG.
Он не один был. По семантике — бледное подражание SQL. В общем, неспроста они окочурились.

M>>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
dmz>>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными,
dmz>>как SQL.

E>Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает
Для реляционных баз, как-то Оракла, есть такие решения, как RAC. Есть ли что-то подобное для OO баз?

Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ? Что-нибудь типа биллинга,
еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться)
— там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время
ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?

А data mining? Есть ли язык запросов, по возможностям близкий к SQL? Построение произвольных отчетов,
не путем генерации и использования каких-то API, а путем простого написания запросов?

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

<SKIP>
M>Увы, лучшего пока не придумали Или придумали? *с надеждой*

<SKIP>
M> Месье знает толк в извращениях

Месье, попробуйте отделить мушек о котлеток и поставить между ними какой-нибудь грамотный OR-bridge и сдается мне что вас потом практически перестанет интересовать вопрос где и как храняться ваши данные.

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

B>Здравствуйте, dshe, Вы писали:
D>>Кстати, многие (если уже не все) РСУБД обладают поддержкой foreign key constraint. Это немного роднит их с сетевыми поскольку в самой идее сетевой модели изначально подразумевается валидация и контроль связей между записями.
B>Разве сетевые БД не есть РСУБД + foreign key constraint — SQL?

Насколько я понимаю, разница между сетевой и реляционной во внутренней реализации. Допустим у нас есть сущности Group и Member со связью между ними Contains (типа Group Contains Member). То в dbVista (и любой другой сетевой СУБД) каждая запись Group содержит неявно ссылку на первый Member из списка дочерних (т.е. тех, которые находятся в одной связи с данной записью Group), а каждая запись Member содержит ссылку на родительскую запись Group + ссылку на следующую запись Member в списке дочерних. Это дает возможнось за одну операцию чтения (как уже говорилось) производить навигацию по данным записям.

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

Что касается SQL, то в dbVista есть какая-то надстройка, которая позволяет делать некоторые select'ы с учетом set'ов. Хотя, конечно, эта СУБД больше ориентирована на навигацию по отдельным записям.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Разве? Там навроде движок MUMPS. А реляционка сверху прикручена.

Точно, мумпс — это иерархическая субд (такие были до реляционных)(одна из проблем — это для того, чтобы по порядку выбрать записи "таблицы", нужно было подниматься по ссылке к родителю, выбирать следующую ссылку, и по ней опускаться обратно). к ней прикручены интерфейсы sql и ооп.

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

M>>Далеко не каждое бизнес-правило можно описать при помощи средств СУБД.

GZ>Бизнес-правила, не все. Это так. Но если использовать их по назначению, а именно для хранения данных, то реляционная модель может описать любую предметную область. Это математически доказанный факт.(Хотя также факт что есть области где РСУБД неэффективен).

Не сомневаюсь. Но сегодня мало просто описать. Нужно описать так, чтоб можно было легко и просто изменять. Причём желательно с минимальным вмешательством программиста. Реляционные структуры данных очень негибкие. Именно об этом говорит Mamut здесь

Автор: Mamut
Дата: 11.10.05

, именно эти проблемы призваны решить различные workflow системы. В идеале все изменения (любой сложности) в бизнес-логику системы должны вностится пользователями. Сейчас делаются попытки создать язык (например BPEL), который будет понятен как владельцу процесса, так и программисту. А ещё лучше не программисту, а самой системе. Основная сложность при создании токго языка в том, что он должен быть достаточно сложен чтобы описать предметную область и достаточно легко формализуем.
Сейчас программисты пытаются создать подобие такого "языка" в РСУБД. Вот Зверёк пишет:
ЗХ> ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]
Кто-то рисует структуры посложнее, но при этом приобретает геморрой с сохранением универсальности/адаптируемости и риск, что в один прекрасный день новое бизнес-правило невозможно будет описать в этой структуре данных и придётся вносить в неё изменения. Может и удастся создать достаточно универсальную структуру данных, в которой все изменения бизнес-логики будут отражать только добавлением записей, а не правкой триггеров/хранимых процедур и применением ALTER TABLE.
С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). Или просто обучить заказчика использованию BPEL (или что там будет).

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>2. Основное преимущество реляционных баз данных — функциональный SQL; лучше которого для запроса к данным еще не придумано. Его вон даже MS в C# 3.0 имитирует

Автор: VladD2
Дата: 10.10.05

.

По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL.

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

dmz>>>Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?

E>>Был такой язык -- Object Query Language назывался. Почил в бозе вместе с породившим его стандартом ODMG.
dmz>Он не один был. По семантике — бледное подражание SQL. В общем, неспроста они окочурились.

M>>>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
dmz>>>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными,
dmz>>>как SQL.

E>>Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает
dmz>Для реляционных баз, как-то Оракла, есть такие решения, как RAC. Есть ли что-то подобное для OO баз?

dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ? Что-нибудь типа биллинга,
dmz>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться)
dmz>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время
dmz>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?

dmz>А data mining? Есть ли язык запросов, по возможностям близкий к SQL? Построение произвольных отчетов,
dmz>не путем генерации и использования каких-то API, а путем простого написания запросов?

Скоро только кролики плодятся. Не знаю сколько лет SQL'у, но явно больше чем OQL. На SystemR надо полагать тоже сначала не ЦУП'ы работали. И сейчас никто кажется не предлагает программу массового перехода на ООСУБД за 3 года. Будет потребность бизнеса — решатся любые проблеммы.

Здравствуйте, Mazay, Вы писали:
M> С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). Или просто обучить заказчика использованию BPEL (или что там будет).
Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты.

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

ЗХ>>2. Основное преимущество реляционных баз данных — функциональный SQL; лучше которого для запроса к данным еще не придумано. Его вон даже MS в C# 3.0 имитирует

Автор: VladD2
Дата: 10.10.05

.

AVK>По семантике LINQ ближе к XPath,
Если не лень, можешь показать пару примеров (в смысле, где семантика ближе к XPath нежели к SQL)?

AVK>хотя синтаксически действительно похож на SQL.
почему я и сказал "имитирует"

ЗЫ: Вообще, мне кажется (со стороны), что C# пошел интересным путем — он постепенно превращается из цельного языка в набор DSL'ей. Нет?

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

M>>>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
dmz>>>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными,
dmz>>>как SQL.

E>>Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает
dmz>Для реляционных баз, как-то Оракла, есть такие решения, как RAC. Есть ли что-то подобное для OO баз?

Я не в курсе, что такое RAC

dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ?

А можно примеры реализации каких-нибудь настолько больших систем как http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml на основе РСУБД?

Не правда ли странно, что самая большая в мире БД работает на основе ООСУБД Objectivity.

dmz> Что-нибудь типа биллинга,
dmz>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться)
dmz>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время
dmz>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?

Я думаю, что без проблем. Даже на Berkeley DB можно сделать время операции меньше 5 секунд на таблицах с миллионами элементов
Многие производители ООСУБД хвастались, что на их основе реализованы различные решения для бирж, которые работают в рилтайме.

dmz>А data mining? Есть ли язык запросов, по возможностям близкий к SQL? Построение произвольных отчетов,
dmz>не путем генерации и использования каких-то API, а путем простого написания запросов?

Вообще-то я заступился за надежность ООСУБД, а не за универсальность
Для меня РСУБД просто на несколько порядков универсальнее, чем ООСУБД. С этим бесполезно спорить.

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

Здравствуйте, dmz, Вы писали:
dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ?

Для JPMorgan's Kapital используется Gemstone/S.

E>Не правда ли странно, что самая большая в мире БД работает на основе ООСУБД Objectivity.
Надо изучить. Не убежден, что она самая большая в мира

dmz>> Что-нибудь типа биллинга,
dmz>>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться)
dmz>>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время
dmz>>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?

E>Я думаю, что без проблем. Даже на Berkeley DB можно сделать время операции меньше 5 секунд на таблицах с миллионами элементов
E>Многие производители ООСУБД хвастались, что на их основе реализованы различные решения для бирж, которые работают в рилтайме.

Да-да. Именно. Я лично не так давно уволился из одной такой конторы, где было именно решение для биржи
и работало оно именно в рилтайме. Была именно OO-база — ну, по крайней мере в видении разработчиков.
Всем хорошая база, только хранила данные только за три дня торгов — иначе капец. Все остальное перекачивалось в
Оракл, а мега-OO база транкейтилась.

Кстати, я бы посмотрел как Беркли будет работать с сотней миллионов записей. Действительно интересно — может, нам
надо на Беркли смигрировать? Столько денег съэкономим на Оракловом суппорте...

E>Вообще-то я заступился за надежность ООСУБД, а не за универсальность
E>Для меня РСУБД просто на несколько порядков универсальнее, чем ООСУБД. С этим бесполезно спорить.
Да — но вопрос, не являются примеры успешного применения OORDBMS на самом деле примерами успеха
применения баз данных, специально разработанных под задачу. Конечно, такие решения должны выигрывать
по каким-то параметрам у универсальных решений.

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

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

В общем, я лично не спорю, что есть области, где ОО СУБД или специально разработанные СУБД выигрывают — но буду
утверждать, что в 90% случаев разумнее применять реляционные — в силу зрелости технологии, наличия инструментов,
etc, etc.

Здравствуйте, Зверёк Харьковский, Вы писали:

AVK>>По семантике LINQ ближе к XPath,
ЗХ>Если не лень, можешь показать пару примеров (в смысле, где семантика ближе к XPath нежели к SQL)?

Лень
Вот к примеру такой код:

new XElement("Customers",
    from c in contacts.Elements("contact")
    select new XElement("Customer",
        new XElement("Name", (string) c.Element("name")),
        new XElement("PhoneNumbers",
            from ph in c.Elements("phone")
            select new XElement("phone", (string) ph,
                ph.Attribute("type")
            )
        )
    )
);

Преобразует XML следующего вида:

<contacts>
    <contact>
        <name>Patrick Hines</name>
        <phone type="home">206-555-0144</phone>
        <phone type="work">425-555-0145</phone>
        <address>
            <street1>123 Main St</street1>
            <city>Mercer Island</city>            
            <state>WA</state>
            <postal>68042</postal>
        </address>
        <netWorth>10</netWorth>
    </contact>
</contacts>

В такой:

<Customers>
    <Customer>
        <Name>Patrick Hines</Name>
        <PhoneNumbers>
            <Phone type="home">206-555-0144</Phone>
            <Phone type="work">425-555-0145</Phone>
        </PhoneNumbers>
    </Customer>
</Customers>

ЗХ>ЗЫ: Вообще, мне кажется (со стороны), что C# пошел интересным путем — он постепенно превращается из цельного языка в набор DSL'ей. Нет?

Нет. Это не DSL. Это добавление в язык функциональной и декларативной стилистики.

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

E>Я не в курсе, что такое RAC

http://www.oracle.com/technology/products/database/clustering/index.html

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

M> Реляционные структуры данных очень негибкие.
Да, не идеал, но с объектами все еще грустнее..

M> С объектами же программисты привыкли делать всё, что им заблагорассудится.
Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость. Сегодня мы данные трактуем так — у нас один объект, завтра надо по другому — не вопрос, объект поменяли, данные остались. А как только мы пытаемся работать с данными как с объектами, то тут же вся гибкость идет лесом и на поверку оказывается, что реляционное представление данных, на данный момент, по гибкости еще никому превзойти не удалось, не смотря на то что из соображений производительности приходится в некоторой степени завязывать струтуру БД на семантику данных.

M> Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL).
Нет, в коде это еще не идеал. Заказчик должен кубики и стрелочки на экране передвигать.

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


E>>Не правда ли странно, что самая большая в мире БД работает на основе ООСУБД Objectivity.
dmz>Надо изучить. Не убежден, что она самая большая в мира

Найдешь больше -- сообщи сюда, пусть все узнают.

E>>Вообще-то я заступился за надежность ООСУБД, а не за универсальность
E>>Для меня РСУБД просто на несколько порядков универсальнее, чем ООСУБД. С этим бесполезно спорить.
dmz>Да — но вопрос, не являются примеры успешного применения OORDBMS на самом деле примерами успеха
dmz>применения баз данных, специально разработанных под задачу. Конечно, такие решения должны выигрывать
dmz>по каким-то параметрам у универсальных решений.

Именно так и происходит. Под некоторые задачи ООБД очень хорошо подходят. Настолько хорошо, что без них задача бы не решалась вовсе (за отведенное время и бюджет).

dmz>В общем, я лично не спорю, что есть области, где ОО СУБД или специально разработанные СУБД выигрывают — но буду
dmz>утверждать, что в 90% случаев разумнее применять реляционные — в силу зрелости технологии, наличия инструментов,
dmz>etc, etc.

+1

Именно такой же позиции и я придерживаюсь.

Только будучи разработчиком собственной ООСУБД мне интересны как раз оставшиеся 10% случаев

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

B>Из чего можно сделать вывод, что у математиков вместо мозгов — ...

Сам такой

Тем не менее, с уважением,
математик.

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

M>Не сомневаюсь. Но сегодня мало просто описать. Нужно описать так, чтоб можно было легко и просто изменять.
Нет нужно просто правильно описывать.
M>Причём желательно с минимальным вмешательством программиста. Реляционные структуры данных очень негибкие. Именно об этом говорит Mamut здесь

Автор: Mamut
Дата: 11.10.05

, именно эти проблемы призваны решить различные workflow системы.
Там проблема в ДНК. База данных которая создана программистами, и БД созданная архитекторами — две разные вещи. О нужности разделение логической структуры БД и физической — пишется в каждой книге. Этого не было сделано. Ну и получили то, к чему стремились.

M>В идеале все изменения (любой сложности) в бизнес-логику системы должны вностится пользователями. Сейчас делаются попытки создать язык (например BPEL), который будет понятен как владельцу процесса, так и программисту. А ещё лучше не программисту, а самой системе. Основная сложность при создании токго языка в том, что он должен быть достаточно сложен чтобы описать предметную область и достаточно легко формализуем.
UML — был построен с примерно такими же требованиями. Какая фигня получилась, уже говорено переговорено.

M> Сейчас программисты пытаются создать подобие такого "языка" в РСУБД. Вот Зверёк пишет:
ЗХ>> ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]

M>Кто-то рисует структуры посложнее, но при этом приобретает геморрой с сохранением универсальности/адаптируемости и риск, что в один прекрасный день новое бизнес-правило невозможно будет описать в этой структуре данных и придётся вносить в неё изменения. Может и удастся создать достаточно универсальную структуру данных, в которой все изменения бизнес-логики будут отражать только добавлением записей, а не правкой триггеров/хранимых процедур и применением ALTER TABLE.
Зачем? У тебя есть реляционная структура которая доказанно универсальна. Она уже готовая. Зачем вводить новую универсальность? Да, при изменении бизнес-логики придется править реляционную модель. Это один из ее недостатков. Но существует теорема о невозможности универсальной функции. Зачем ее опровергать?

M> С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL).

Если говорить о недостатках РСУБД, то могу сходу назвать следующие: невозможность менять модель в runtime(точнее неэффективность изменения схемы), неэффективность при многомерных запросах, отсутсвие недекларативного навигационного доступа, ну и проблемы дубликатов, хотя это не проблема реляционной теории, а проблема именно SQL. Что касается многомерных запросов, то дополнительные инструменты уже придумали, OLAP(и кстати описал не кто иной как Кодд). В OODB, хотя она вынуждает пользователя выполнять именно такие запросы, проблема полностью не решена.

С уважением, Gleb.

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

M>> С объектами же программисты привыкли делать всё, что им заблагорассудится.
M>Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость. Сегодня мы данные трактуем так — у нас один объект, завтра надо по другому — не вопрос, объект поменяли, данные остались. А как только мы пытаемся работать с данными как с объектами, то тут же вся гибкость идет лесом и на поверку оказывается, что реляционное представление данных, на данный момент, по гибкости еще никому превзойти не удалось, не смотря на то что из соображений производительности приходится в некоторой степени завязывать струтуру БД на семантику данных.

Мои 5 копеек, в Oracle есть Object, у него даже есть методы, но они не привязаны к экземпляру ( если так можно выразиться ). И в целом от этого одни проблемы ИМХО.

Здравствуйте, ansi, Вы писали:
A>Здравствуйте, beroal, Вы писали:
B>>Из чего можно сделать вывод, что у математиков вместо мозгов — ...
A>Сам такой
От вы меня поняли полностью наоборот. Я хотел сказать, что если математик может придумать что-то, что не может понять человеческий мозг, значит у математика мозг уже нечеловеческий?