Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
ModelR

conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?


Насколько я понимаю, именно это пример как реляционщик понимает объетную базу. Не обижайтесь пожалуйста. В объектной базе по хорошему просто пишут
myOrder.addOrderLine( myLine )
1 сен 05, 13:26    [1836538]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Dimonische
ModelR

conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?


Насколько я понимаю, именно это пример как реляционщик понимает объетную базу. Не обижайтесь пожалуйста. В объектной базе по хорошему просто пишут
myOrder.addOrderLine( myLine )


Или если надо конкретно на первую позицию:

List orderLines = myOrder.getOrderLines();
orderLines.add(myLine ,0);
1 сен 05, 13:29    [1836558]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2406
Блог
Dimonische
Э, Павел, вы издеваетесь наверное?
Отнюдь. Вероятно просто не понимаю о чём речь и пытаюсь задать наводящие вопросы.
Dimonische
Можно запихнуть селект. Только таких классов у меня в программе ~ 500. И методов по 5 на класс. Ту факинг экспенсив.
И что? Вы не пишите факинг реализацию для своих факин экстенсив нумбер оф мефодс? Что значит этот самыё метод, который Вы написали, что за ним стоит?
Dimonische
Я уже не говорю о том, что выполнять такие запросы в цикле - за это я лично уволил человека 2 года назад. Не за конкретно это конечно, но просто это стало последней каплей.
В некоторых обстоятельствах я поступил бы точно так же.
Dimonische
Этот же метод реализованный базон данных, именно делает ПРЯМУЮ навигацию. По моему так.
Что значит "БД делает прямую навигацию"? Что это означает?
1 сен 05, 13:55    [1836730]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
хоть убей не вижу чем получение значения по ссылке отличается от получения значения по ключу (для разработчика, а не для СУБД). Чем сслыка не ключ?
и соответственно такая запись через точку для меня это просто как некая другая реализация SQL. Надо признать что то-то в этом есть.

Dimonische


Или если надо конкретно на первую позицию:

List orderLines = myOrder.getOrderLines();
orderLines.add(myLine ,0);

всё, дальше не надо
1 сен 05, 13:56    [1836742]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Павел Воронцов
Что значит "БД делает прямую навигацию"? Что это означает?


Сonnection conn = ...;
ResultSet result = conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'") ;

HashSet set = new HashSet();
while(result.next())
{
      Order o = (Order)result.nextObject();
      for (int i = 0; i < o.getOrderLines().length; i++ ) {
          set.add(o.getOrderLines().getCommodity());
      }
}


Так, основной вопрос, а что происходит при o.getOrderLines()?

В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

Варианты

1. o.getOrderLines() может через спрятанную ссылку (куторую добавили при возврате класса Order скрытым от нас образом внутри executeQuery) вызвать сервер Объектной базы и по ссылке получить список OrderLine (очень похоже на скрытый SQL)

2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

3. В случае, Commodity очевидно не находтся в домене Order, посему добавляется дополнительная конфигурация типа "функция getOrderLines() класса Order кэширует связь типа Commodity". Тогда получается что-то типа

conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'", new String[] {ORDER.ORDER_LINE.COMMODITY} );

Тогда сервер БД будет уже возвращать по функции getCommodity кэшированные товары
1 сен 05, 14:43    [1837003]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Dimonische


3. В случае 2, Commodity очевидно не находится в домене Order, посему добавляется дополнительная конфигурация типа "функция getOrderLines() класса Order кэширует связь типа Commodity". Тогда получается что-то типа

conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'", new String[] {ORDER.ORDER_LINE.COMMODITY} );

Тогда сервер БД будет уже возвращать по функции getCommodity кэшированные товары


Да, еще нюанс. Если
new String[] {ORDER.ORDER_LINE.COMMODITY}
не указано, то метод getCommodity() полезет брать объект по commodityId. Это все равно эффективней, т.к. все объектные ид специфичны для каждой объектной базы и "прямо указывают на сектор на диске откуда считать данные", ессно если данные не в памяти. В отличие от идентификатора 100001.
1 сен 05, 15:04    [1837141]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Dimonische

>>Так, основной вопрос, а что происходит при o.getOrderLines()?

>>В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

А если не Java ? Если .NET ? Там уже другой байт код, сл-но менять надо по-другому. Если работаем с Delphi7 или (о ужас!) VB6, там вообще native code, особо ничего не поменяешь. Т.е. получается, что «объектные» базы напрямую зависят от технологии разработки клиента, а может это и не базы в виде Клиент - Сервер, а просто некоторый инструментарий для конкретной платформы (нап. Java)?
Или эти «объектные базы» настолько круты, что у них есть интерфейс под большинство современных средств разработки и этот инструментарий поспевает за бесконечными обновлениями платформ ?
Как-то грустно звучит :( Т.е. если вляпались в «объект», будем тащить их до конца как до сих пор тащут COBOL и IMS. Безрадостно как-то. Oracle7-8-9-10g «выставляет "наружу" свой API и работай с ним из любой среды(хошь те Fortran хошь те VB), т.к. на уровне инструкций для подстройки платформы ничего «менять» не надо.


>Варианты

>1. o.getOrderLines () может через спрятанную ссылку (куторую добавили при возврате класса >Order скрытым от нас образом внутри executeQuery) вызвать сервер Объектной базы и по >ссылке получить список OrderLine (очень похоже на скрытый SQL)

«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.

>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с >классом Order" и при запросах всегда возвращаются.

Если хранятся вместе, тогда вопросов нет. Но это может привести к вырождению БД в файловую систему или в систему типа «Всё в одной таблице». Там с блокировочками накладно-с.

Вобщем-то, если наплевать на зависимость от платформы, можно и так работать, но вся фигня в том, что нужно не только получать Order и OrderLines. Это вобщем-то настолько тривиально сделать, что можно и с БД особо не заморачиваться. К сожалению, кроме всяких Интернет Магазинов и небольших складов, есть всякая аналитика и отчёты. Мерзопакастнейшая вешь.
Т.е. нужны всякие суммы, средние, макс. мин, группировки немыслимые, подзапросы нехилой вложенности и прочие «радости жизни».
Вот тут всё будет намного сложнее чем :

HashSet set = new HashSet();
while(result.next())
{
Order o = (Order)result.nextObject();
for (int i = 0; i < o.getOrderLines().length; i++ ) {
set.add(o.getOrderLines().getCommodity());
}
}

Потому как никакой МЕГАСЕРВЕР, не догадается как нужно getCommodity «поменять», тут язык запросов нужен и мощный, что бы на каждый отчёт всю базу с сервера не выкачивать, к языку запросов ещё оптимизатор необходим, что бы соотнести план выполнения с текущим состоянием базы, и без замкнутой реляционной теории у которой все операции производятся над множествами построить такой оптимизатор едва ли получится. Ещё хорошо, что бы отчёты целостные были, т.е. изоляцию обеспечить, хотя бы минимальную.

Попробуйте решить простенький пример, который у нас давнооо был
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=19#804604

С интересом взгляну на решение в навигационной среде. Был тут один ШПЕЦИАЛИСТЪ, объееееектный, аж жуть, только решения от него никто так и не увидел.

Потому и сдохли сетевые и иерархические СУБД в которых порядок перемещения по данным определялся программистом и зависел от физического размещения и состава данных (при появлении нового индекса надо вырисовывать новый способ получения данных который бы учитывал этот индекс, иначе никакого выигрыша навигация-то ручная и вбита разработчиком когда индекса ещё не было) .
1 сен 05, 17:30    [1838081]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Dimonische
ModelR

conn.ADD_FIRST_CHILD (myOrder,  myLine, 'OrderLinesList')
где 'OrderLinesList' - имя связи, раскраска, по которой идет навигация. Т.е какие-то ОО СУБД предоставляют такой навигационный интерфейс или это дело приложения?


Насколько я понимаю, именно это пример как реляционщик понимает объетную базу. Не обижайтесь пожалуйста. В объектной базе по хорошему просто пишут
.addOrderLine( myLine )

Так знал бы не спрашивал. Однако так по-моему пишут просто в Java. Где тут написано что это операция с БД, и с каким именно инстансом (коннектом) и что myLine теперь также должна ссылаться на myOrder , что автоматически должна бы делать гипотетическая ADD_FIRST_CHILD навигационной СУБД?
И где написано, что это именно список помеченный как 'OrderLinesList', ибо тот же myLine может входить в тот же myOrder по иным причинам.

Один дурак может задать столько вопрсов...
1 сен 05, 17:52    [1838231]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Andreww
2 Dimonische
А если не Java ? Если .NET ? Там уже другой байт код, сл-но менять надо по-другому. Если работаем с Delphi7 или (о ужас!) VB6, там вообще native code, особо ничего не поменяешь. Т.е. получается, что «объектные» базы напрямую зависят от технологии разработки клиента, а может это и не базы в виде Клиент - Сервер, а просто некоторый инструментарий для конкретной платформы (нап. Java)?
[quot]

Андрей, 2 вещи:

1. Байт код клиента меняет клиентский драйвер, который может быть на Яве/С#/языки с байткодом (тогда там bytecode instrumentation), С/C++/компилируемые языка (компиляция нового класса). На сервере данные хранятся в серверном виде, не зависимым от языка доступа.

2. Когда вы что-то говорите насмешливым тоном, вы должны быть мегагуру и быть уверенным том что Вы говорите. Иначе получится конфуз. Как сейчас. Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.

[quot Andreww]

«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.



Видимо, Вы не знаете что такое транзакции.


Andreww

>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с >классом Order" и при запросах всегда возвращаются.

Если хранятся вместе, тогда вопросов нет. Но это может привести к вырождению БД в файловую систему или в систему типа «Всё в одной таблице». Там с блокировочками накладно-с.


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

Andreww


(... Поскипана аргументация необходимости мощного языка запросов ...)
тут язык запросов нужен и мощный, что бы на каждый отчёт всю базу с сервера не выкачивать, к языку запросов ещё оптимизатор необходим, что бы соотнести план выполнения с текущим состоянием базы, и без замкнутой реляционной теории у которой все операции производятся над множествами построить такой оптимизатор едва ли получится. Ещё хорошо, что бы отчёты целостные были, т.е. изоляцию обеспечить, хотя бы минимальную.



Никто не против наличия подобного языка запросов в ООБД.
Реч идет о том, что аналитиков, которые делают SQL к базе данных (в центральном офисе ТНК например) - 25 человек. А людей, которые открывают Вебстранички или ЮАЙ - 1500 человек. И они даже не знают слова SQL. Зато для них функциональность делать на объектных базах быстрее. Потому что люди сами оперируют объектами - "а вот на это страничке откройте Заказ, а на следующей табе список Накладных, дайте возможность накидать накладные на заказ."
1 сен 05, 18:29    [1838407]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Dimonische, Вы это, задачку то, которую привёл Andreww решили бы сначала. Сдаётся мне что его насмешливый тон имеет под собой основания
1 сен 05, 19:01    [1838507]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
и вообще у вас несколько однообразная и недостаточно глубокая аргументация:

...Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.
...Видимо, Вы не знаете что такое транзакции.
...это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.
1 сен 05, 19:10    [1838548]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
SergSuper
Dimonische, Вы это, задачку то, которую привёл Andreww решили бы сначала. Сдаётся мне что его насмешливый тон имеет под собой основания


Andreww
нужно сделать выборку для отделений (dep_id) 100 и 200 для штатов (state) 'CA', 'UT', 'NY', 'AZ' заказов всех покупателей (emp_lname) с перечислением даты заказа (start_date), суммы заказа (salary) и нарастающего итога по суммам заказов для каждого отделения отдельно согласно сортировке по датам заказов


SELECT dept_id, emp_lname, start_date, salary,
  SUM(salary) OVER (PARTITION BY dept_id
    ORDER BY start_date
    RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;

Написать что надо, подобный запрос?

Пожалуйста: (пример без специфики видимо Оракла в виде UNBOUNDED PRECEDING AND CURRENT ROW)

SELECT dept_id, emp_lname, start_date, salary,
SELECT SUM(salary) FROM Employee e WHERE e.startDate > e.1start_date AND e.id = e1.id AS "Sum_Salary"
FROM Employee e1
WHERE e1.state IN ('CA', 'UT', 'NY', 'AZ') AND e1.dept_id IN ('100', '200')
ORDER BY e1.dept_id, e1.start_date;



Что, слишком похоже на SQL? А кто-же вам вдолбил, что нет объектных запросов?
В сад.
1 сен 05, 19:15    [1838558]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
SergSuper
и вообще у вас несколько однообразная и недостаточно глубокая аргументация:

...Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.
...Видимо, Вы не знаете что такое транзакции.
...это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.


Прокомментирую только один тезис - Видимо, Вы не знаете что такое транзакции.
Вот что писал Андрей -
Andreww

«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.


Что происходит в РСУБД в случае идентификаторов? Ответ ничего - изоляция транзакций не просто так придумана. Или может автор думает что в объектных базах не транзакций? Так надо так было и спросить.

В сад.
1 сен 05, 19:19    [1838572]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
serg99
Member

Откуда:
Сообщений: 422
Andreww

Попробуйте решить простенький пример, который у нас давнооо был
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=19#804604


Пример немного странный. Поле emp_lname думаю описывает имя сотрудника, а не покупателя, Salary - это зарплата, а не сума заказа. Столбец Sum_salary не имеет практического смысла (вернее смысл имеют только два значения из всего столбца).
1 сен 05, 20:00    [1838664]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Dimonische, вот Вы привели решение и какая картина видится из сада, какой напрашивается вывод? Только такой: т.е. получается на словах, потрындеть - вам эта навигация ну жуть как нужна, а вот как до дела доходит - то без неё задачи решаете.

Насчет транзакций
Что происходит в РСУБД в случае идентификаторов? Ответ ничего - изоляция транзакций не просто так придумана. Или может автор думает что в объектных базах не транзакций? Так надо так было и спросить.
Чесно говоря, не понял причем они тут. Говорилась что есть разница между ссылкой и идентификатором, который представляет собой некую неизменную абстракцию. Не нужно открывать транзакцию каждый раз при чтении идентификатора. А вот со ссылками похоже придётся
1 сен 05, 20:07    [1838679]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Мысли по поводу навигации...
Мысль1. Можно вспомнить статью Дейта где он рассуждает о существуенных конструкциях. Соответсвенно, возникает желанеи обозвать навигацией любое использование конструкция , не являющихся отношениями, как существуенных. Я с ним согласен.

Мысль2 Однако (это показано в НМРсорри, но тут уже я на белом коне :)) определение некоторых типов может рассматриваться как определение множества взаимосвязанных переменных отношений. То есть если мы определим отношение a и b явно, то мы конечно должны делать явный JOIN. Однако - как туту неоднократно намекал, SergSuper, выражение x.y тоже мона рассмтаривать как исключительно реляционную операцию - этакий неяный JOIN. Возможность этой неявности обуславливаеться тем, что ранее эти x и y были определные как составные части структуры этого типа (причем сложноть структуры никуда не делась - она отражена в сложных именах переменных отношений и их атрибутов)

Мысль3 Ни в коем случае нельзя забывать о том, как реализованы объекты. Все ОО-псевдоапологеты, говоря, что ОО-системы это дескать быстро, забывают о том что быстрыми является не какие то ОО-принципы, а адресуемая память... ООязыки и вслед за ними ООСУБД возникли как средство упарвления адресуемыми устроствами хранения - 1)ОЗУ и 2)файлы с прямым доступом. Ссылки при этом отображаютя в адреса. Соответсвенно, как сказал Andreww, "перемещения по данным зависит от физического размещения". При этом физически в памяти они размещены так-то на лиске по другому. Возникает вопрос синхронизации двух памятей. Потом, что бы объект мог пермещатся физичеки, но ссылка бы при этом не менялась, делают мягкие ссылки. Потом возникает проблема поиска объктов по атрибутам и доступа к этим объектам. Они - поклонники ОО"СУБД" - выдумают какие нибудь специальные индексы (я в этом уверен) если ужже не выдумали. Но ведь все это - таблица магких ссылок, таблица синхрноизации ОЗУ и диска, все эти индексы, это все - таблицы! - и чем дальше , тем их становиться больше! И выясняется, что(ежели подумать) что прямой доступ у файлу - это конечно быстро, но что бы найти данные на диске , так это надо в трех таблица концы свести...неявно конечно, но надо....А вам не кажется, чт оежели по этому пути идти далье, то можно прийти в ситуации, когда все данные таки будут как-то где-то представлены в каких то таблицах? И все эти таблицы решают одну задачу , а именно - сделать данные независимыми от их физического зранения. Так не прощели не ковыряться в этом, а воспользоваться тем, что уже как тридцать лет сделано? Как воспользоваться- я знаю, но никому не скажу :) Рел системы представляют собой независимую от физического размещения систему хранения данных. Создана мощная ассоцативная(по способу доступа к данным) машина, осталось для него сделать ОО интерпертатор - кто первый?
2 сен 05, 03:51    [1839084]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2406
Блог
Dimonische
Павел Воронцов
Что значит "БД делает прямую навигацию"? Что это означает?


Сonnection conn = ...;
ResultSet result = conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'") ;

HashSet set = new HashSet();
while(result.next())
{
      Order o = (Order)result.nextObject();
      for (int i = 0; i < o.getOrderLines().length; i++ ) {
          set.add(o.getOrderLines().getCommodity());
      }
}


Так, основной вопрос, а что происходит при o.getOrderLines()?

В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

Варианты

1. o.getOrderLines() может через спрятанную ссылку (куторую добавили при возврате класса Order скрытым от нас образом внутри executeQuery) вызвать сервер Объектной базы и по ссылке получить список OrderLine (очень похоже на скрытый SQL)

2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

3. В случае, Commodity очевидно не находтся в домене Order, посему добавляется дополнительная конфигурация типа "функция getOrderLines() класса Order кэширует связь типа Commodity". Тогда получается что-то типа

conn.executeQuery("SELECT FROM Orders o WHERE o.suppyDate < '2005-11-03'", new String[] {ORDER.ORDER_LINE.COMMODITY} );

Тогда сервер БД будет уже возвращать по функции getCommodity кэшированные товары
То есть (подводим итог) реализацию метода извлечения данных из хранилища Вы хотите переложить на сервер. Благое желание. Только непонятно зачем при этои диктовать серверу как он должен хранить данные? Дело в том, что СУБД предоставляет Вам множество способов доступа к данным, Вы вольны выбрать тот или иной, а сервер будет заботиться об их хранении и целостности. Как Вы устроите у себя процедуру извлечения нужной информации - дело Ваше. Можно каженный раз писать запросики и добывать то , что нужно, когда нужно. Можно написать объектную обвязку, кеширующую нужную информацию о тех же заказах, то есть прячущю эти самые запросы от программиста за удобным интерфейсом. Можно (в Оракле например) напложить кучку объектных типов, нарисовать объектные представления и доставать сразу всё одним запросом и не морочиться дополнительными запросами с клиента. Можно (много где) написать обвязку хранимых процеду и/или функций на сервере, возвращающих всё что нужно в нужном виде. Можно сочетать и то и другое и пятое и десятое. И данные будут таки храниться в самосогласованном виде - без разницы сколько приложений эту базу насилует и какими методами. СУБД не для приложения создаётся, а для хранения, манипулирования и отслеживания целостности данных, нужных приложению. Они же (данные) могут пригодиться и другому приложению. То, о чём Вы тут пишите - ограничение способов доступа. А заодно ещё и дополнительные требования к хранению, что ещё хуже.
2 сен 05, 08:18    [1839201]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Dimonische
SELECT dept_id, emp_lname, start_date, salary,
  SUM(salary) OVER (PARTITION BY dept_id
    ORDER BY start_date
    RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;

Написать что надо, подобный запрос?

Пожалуйста: (пример без специфики видимо Оракла в виде UNBOUNDED PRECEDING AND CURRENT ROW)

SELECT dept_id, emp_lname, start_date, salary,
SELECT SUM(salary) FROM Employee e WHERE e.startDate > e.1start_date AND e.id = e1.id AS "Sum_Salary"
FROM Employee e1
WHERE e1.state IN ('CA', 'UT', 'NY', 'AZ') AND e1.dept_id IN ('100', '200')
ORDER BY e1.dept_id, e1.start_date;


Увы, Ваше решение не имеет ничего общего с исходным запросом Прежде чем решать задачу, Вы бы все таки потрудились уточнить иодные данные (что именно дает эта самая специфика видимо Оракла.

Не серьезный подход
2 сен 05, 08:50    [1839252]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
U-gene

... прямой доступ у файлу - это конечно быстро, но что бы найти данные на диске , так это надо в трех таблица концы свести...неявно конечно, но надо....


Мне кажется у вас неверное представление о работе типичной ООСУБД. Раскажите ка по-подробнее, где вы там три таблицы увидели.
2 сен 05, 11:05    [1839792]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Dimonische

Если чем-то не понравился мой тон, извините. У меня не было цели вас обидеть или унизить, я просто хочу разобраться.

>>Андрей, 2 вещи:

>>1. Байт код клиента меняет клиентский драйвер, который может быть на Яве/С#/языки с байткодом (тогда там bytecode instrumentation),

Хммм. Т.е. вы всё-таки уверены, что именно КЛИЕНТСКИЙ код ИЗМЕНЯЕТСЯ. Т.е. (вспоминая пример в посте № 1837003, я уж не буду его весь приводить, желающие могут посмотреть), set.add(o.getOrderLines().getCommodity ()) этот самый getCommodity развернётся в код который вернёт список (?) и получится что-то вроде set.add(new OrderLines(){…тут код который «сгенерировал» (!?) драйвер для конструирования объета OrderLines…})

Есс-но это всё в байт коде. Верно понимаю ? Можно ссылочку на такой драйвер, который это умеет, ну и на ОСУБД для которой он предназначен ?

>>С/C++/компилируемые языка (компиляция нового класса).

Т.е. при каждом изменении Класса в Объектной БД, я должен заново скомпилировать все клиентские приложения, или как ? Я просто пытаюсь понять ….


>>На сервере данные хранятся в серверном виде, не зависимым от языка доступа.

Это не имеет особого значения, если для компилируемых языков нужна повторная компиляция при изменениях в БД, а для платформ с VM драйвер настолько «умён», что подстраивается под любой код.


>>2. Когда вы что-то говорите насмешливым тоном, вы должны быть мегагуру и быть уверенным том что Вы говорите.

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

>>Иначе получится конфуз. Как сейчас. Когда совершенно очевидно, что вы не знаете что такое JDBC/ODBC, клиентские драйвера и пр.

Пока никакого конфуза не вижу. Я спрашиваю, вы отвечаете, от ответа не уходите и подробно разжёвываете (за что большое спасибо). Если я где-то ошибусь, я это признаю.

>>Видимо, Вы не знаете что такое транзакции.

ОК. Транзакции (и заметье, я не утверждал что кто-то чего-то не знает, просто спрашивал), я действительно не представляю как они используются в объектных СУБД.
При получении объекта Order мы должны заблокировать все входящие в него объекты OrderLine т.к. в Order есть ссылки (ваши слова – «может через спрятанную ссылку которую добавили при возврате класса Order скрытым от нас образом внутри executeQuery» ?) если у сервера блокировочный механизм, или нужно сохранить где-то версии в случае версионника, что бы эти ссылки были действительными, но тут же возникает проблема , а что если у OrderLine есть ссылки на объекты SubLine, например? Их надо согласовывать ? И зачем мне чего-то блокировать или версии оставлять, если я беру Order и работаю только с ним ? В случае РСУБД, как вам уже обяснили в посте № 1838679 в случае чтения идентификатора, никаких действий по согласованности не требуется, т.к. идентификаторы в этом случае это ничего не значащий суррогат с ним работает разработчик он за него и отвечает, а вот «спрятаные» ссылки должны разрешаться БЕЗ ВМЕШАТЕЛЬСТВА РАЗРАБОТЧИКА (на то они и спрятанные) и иного механизма обеспечения согласованности кроме блокировки или хранения старой версии пока нет.

Дальше.

>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

>Откровенно говоря, это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.

Конечно нет ! Но я пытаюсь у вас про них узнать подробнее. Вы предлагаете решение ("OrderLines задекларированы как члены домена Order"), я вам рассказываю к чему это может привести, а вы в ответ – «это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта», странно как-то, не находите ? Вы сказали как, я сказал чем мне это не нравится, а мне в ответ «опыта нет». :-(

>Реч идет о том, что аналитиков, которые делают SQL к базе данных (в центральном офисе ТНК например) - 25 человек.

Ну тем хуже для ТНК. Я до сих пор не встречал аналитиков (бизнес-аналитиков) у которых SQL в качестве инструмента. Всё больше пакеты всякие для OLAP. А какой там внутри xyzQL это аналитиков мало волнует, им срезы всякие нужны, по кварталам, по месяцам, по-подразделниям и прочее. Прибыль и т.д. Им решения принимать и текущее состояние дел видеть надо. С ужасом представляю как финдиректор, что бы посмотреть сумму прибыли за квартал по подразделениям открывает SQLPlus и начинает писать SELECT …

>А людей, которые открывают Вебстранички или ЮАЙ - 1500 человек. И они даже не знают слова SQL. Зато для них функциональность делать на объектных базах быстрее. Потому что люди сами оперируют объектами - "а вот на это страничке откройте Заказ, а на следующей табе список Накладных, дайте возможность накидать накладные на заказ."

Странный подход :( Т.е. если у вас заказчик потребует реализовать возможность А и возможность Б вы скажете, берёмся за возможность «Б« а «А», ну как-нибудь потом, она всего-то нужна для 10 человек….

Теперь про задачу :

Условие вы видели –

нужно сделать выборку для отделений (dep_id) 100 и 200 для штатов (state) 'CA', 'UT', 'NY', 'AZ' заказов всех покупателей (emp_lname) с перечислением даты заказа (start_date), суммы заказа (salary) и нарастающего итога по суммам заказов для каждого отделения отдельно согласно сортировке по датам заказов

>Написать что надо, подобный запрос?

Да нет. Я хотел увидеть решение в навигационной среде, ну да ладно.

>Пожалуйста: (пример без специфики видимо Оракла в виде UNBOUNDED PRECEDING AND CURRENT ROW)

Дальше запрос (ваш) :

SELECT dept_id, emp_lname, start_date, salary,
SELECT SUM(salary) FROM Employee e WHERE e.startDate > e.1start_date AND e.id = e1.id AS "Sum_Salary"
FROM Employee e1
WHERE e1.state IN ('CA', 'UT', 'NY', 'AZ') AND e1.dept_id IN ('100', '200')
ORDER BY e1.dept_id, e1.start_date;


Ну наверное всё-таки «>=» вместо «>» , но смысла это не меняет, т.к. не решает исходной задачи. Простым переписыванием запроса к Ораклу тут не обойтись. Я так понял, что это и есть язык запросов к ОБД ? Очень напоминает SQL из РСУБД. Та же декларативность (без навигации) и ассоциативный доступ вместо навигационого. Зачем с проверенных РСУБД на нечто непроверенное перескакивать, когда возможности у языка запросов те же самые и явных преемуществ нет?

Может для вас ОСУБД эта некоторая прослойка (вроде сервера приложений) между рел. хранилищем и ОО средой разработки ? Отсюда и запросы на SQL и «странные» требования к драйверу JDBC ?

Кстати запрос на SQL (не ваш) не совсем верен, в постановке указывалось, что нужен НАРАСТАЮЩИЙ ИТОГ ПО ПОДРАЗДЕЛЕНИЮ? Т.е. :

SELECT dept_id, emp_lname, start_date, salary,
SUM(salary) OVER (PARTITION BY dept_id
ORDER BY start_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;
2 сен 05, 20:54    [1842916]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
U-gene
. ООязыки и вслед за ними ООСУБД возникли как средство упарвления адресуемыми устроствами хранения - 1)ОЗУ и 2)файлы с прямым доступом. Ссылки при этом отображаютя в адреса. Соответсвенно, как сказал Andreww, "перемещения по данным зависит от физического размещения". При этом физически в памяти они размещены так-то на лиске по другому. Возникает вопрос синхронизации двух памятей. Потом, что бы объект мог пермещатся физичеки, но ссылка бы при этом не менялась, делают мягкие ссылки. Потом возникает проблема поиска объктов по атрибутам и доступа к этим объектам. Они - поклонники ОО"СУБД" - выдумают какие нибудь специальные индексы (я в этом уверен) если ужже не выдумали. Но ведь все это - таблица магких ссылок, таблица синхрноизации ОЗУ и диска, все эти индексы, это все - таблицы! - и чем дальше , тем их становиться больше! И выясняется, что(ежели подумать) что прямой доступ у файлу - это конечно быстро, но что бы найти данные на диске , так это надо в трех таблица концы свести...неявно конечно, но надо....А вам не кажется, чт оежели по этому пути идти далье, то можно прийти в ситуации, когда все данные таки будут как-то где-то представлены в каких то таблицах? И все эти таблицы решают одну задачу , а именно - сделать данные независимыми от их физического зранения. Так не прощели не ковыряться в этом, а воспользоваться тем, что уже как тридцать лет сделано?


Любопытно, что Ваш тезис верен с точностью до наоборот. Именно в РБД используют деревья индексов для решения описанных Вами проблем абстрагирования от физического хранения данных. Если взять к примеру MS-SQL то можно нарисовать в нем запрос без bookmark lookup что приведет к отсутствию работы с таблицами - использоваться будут только деревья. Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?

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

Статья по этой теме доступна здесь: http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx.
3 сен 05, 15:15    [1843544]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Мимопроходивший
Member [заблокирован]

Откуда:
Сообщений: 114
OCL?
--
Мимопроходивший != Мимопроходящий
(Их разыскивает милиция)
3 сен 05, 16:22    [1843595]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Andreww
2 Dimonische

Если чем-то не понравился мой тон, извините. У меня не было цели вас обидеть или унизить, я просто хочу разобраться.


Вы меня тоже извините. Возможно, я чрезмерно реагирую.


Andreww

>>1. Байт код клиента меняет клиентский драйвер, который может быть на Яве/С#/языки с байткодом (тогда там bytecode instrumentation),

Хммм. Т.е. вы всё-таки уверены, что именно КЛИЕНТСКИЙ код ИЗМЕНЯЕТСЯ. Т.е. (вспоминая пример в посте № 1837003, я уж не буду его весь приводить, желающие могут посмотреть), set.add(o.getOrderLines().getCommodity ()) этот самый getCommodity развернётся в код который вернёт список (?) и получится что-то вроде set.add(new OrderLines(){…тут код который «сгенерировал» (!?) драйвер для конструирования объета OrderLines…})


Ээээ, getCommodity() возвращает объект типа Commodity (а не коллекцию) т.е это выглядит как:
Commodity tovar = o.getOrderLines().getCommodity();

Andreww

set.add(new OrderLines(){…тут код который «сгенерировал» (!?) драйвер для конструирования объета OrderLines…})


Черт, как же Ява оторвалась, а... Я вообще не понял что вы хотели написать .
Я в интерфейс Set (в яве хранит уникальные значения) хотел добавить Commodity...

Andreww

Есс-но это всё в байт коде. Верно понимаю ? Можно ссылочку на такой драйвер, который это умеет, ну и на ОСУБД для которой он предназначен ?


Это умеют все ОО базы, у которых есть Ява интерфейс. Как минимум Версант VDS. Что именно вас интересует? Я на вскидку на Версантовском сайте это не нашел, однако описание техники есть для Hibernate

http://www.hibernate.org/hib_docs/v3/reference/en/html_single/

Поишите все вхождения слова bytecode

Andreww


>>С/C++/компилируемые языка (компиляция нового класса).

Т.е. при каждом изменении Класса в Объектной БД, я должен заново скомпилировать все клиентские приложения, или как ? Я просто пытаюсь понять ….


Андрей, в ОО базах классов на с++, яве и пр. (в Версанте например) НЕТ. Они внутри версанта описаны на собственном версантовом языке типа CREATE TABLE, и могут предоставляться Ява доступом, как Явовские классы, С++ доступом как С++ классы и пр.

Одно надо ясно поимать. Есть поле грохнули из БД, надо перекомписять. С РСУБД также.

>>Видимо, Вы не знаете что такое транзакции.

Andreww

ОК. Транзакции (и заметье, я не утверждал что кто-то чего-то не знает, просто спрашивал), я действительно не представляю как они используются в объектных СУБД.
При получении объекта Order мы должны заблокировать все входящие в него объекты OrderLine т.к. в Order есть ссылки (ваши слова – «может через спрятанную ссылку которую добавили при возврате класса Order скрытым от нас образом внутри executeQuery» ?) если у сервера блокировочный механизм, или нужно сохранить где-то версии в случае версионника, что бы эти ссылки были действительными, но тут же возникает проблема , а что если у OrderLine есть ссылки на объекты SubLine, например? Их надо согласовывать ? И зачем мне чего-то блокировать или версии оставлять, если я беру Order и работаю только с ним ? В случае РСУБД, как вам уже обяснили в посте № 1838679 в случае чтения идентификатора, никаких действий по согласованности не требуется, т.к. идентификаторы в этом случае это ничего не значащий суррогат с ним работает разработчик он за него и отвечает, а вот «спрятаные» ссылки должны разрешаться БЕЗ ВМЕШАТЕЛЬСТВА РАЗРАБОТЧИКА (на то они и спрятанные) и иного механизма обеспечения согласованности кроме блокировки или хранения старой версии пока нет.


Все типы транзакций существуют с некоторыми малозначительными нюансами и в ООБД.

Условно говоря, например Order->OrderLine->OrderSubline можно объявить ка один домен (композитный объект). Пусть у нас полная изоляциию. Мы вытащили Orders из Connection неким запросом. Соответвственно, все вложеные объекты, которые будут доступны через навигацию тоже взяты как полная изоляция. Т.к. с точки зрения БД, это один объект. Чтобы было более яснее, что такое домен, пусть будут такие связи : Order->OrderLine->OrderSubline->Currency. Виден домен невооруженным взглядом - Order->OrderLine->OrderSubline. Видна внешняя связь - OrderSubline->Currency.


Andreww

>2. OrderLines задекларированы как члены домена Order, и потому хранятся "вместе с классом Order" и при запросах всегда возвращаются.

>Откровенно говоря, это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта.

Конечно нет ! Но я пытаюсь у вас про них узнать подробнее. Вы предлагаете решение ("OrderLines задекларированы как члены домена Order"), я вам рассказываю к чему это может привести, а вы в ответ – «это проблема разработчиков объектной БД. Сдается мне, у Вас нет такого опыта», странно как-то, не находите ? Вы сказали как, я сказал чем мне это не нравится, а мне в ответ «опыта нет». :-(
Andreww

Если хранятся вместе, тогда вопросов нет. Но это может привести к вырождению БД в файловую систему или в систему типа «Всё в одной таблице». Там с блокировочками накладно-с.



Фиг знает, я привел привем как я выделяю домены. у меня не вырождается.
А почему я взъелся на транзакции уже не помню.

Andreww

>>В яве есть такое понятие - Bytecode instrumentation.
Это значит, что код класса, который вернулся откуда либо (в нашем случае conn.executeQuery) поменян на уровне инструкций виртуальной машины Ява.

А если не Java ? Если .NET ? Там уже другой байт код, сл-но менять надо по-другому. Если работаем с Delphi7 или (о ужас!) VB6, там вообще native code, особо ничего не поменяешь. Т.е. получается, что «объектные» базы напрямую зависят от технологии разработки клиента, а может это и не базы в виде Клиент - Сервер, а просто некоторый инструментарий для конкретной платформы (нап. Java)?


НЕТ, не зависят. Есть объектный сервер, есть к ниму библиотеки доступа с разных языков. Ну возьмите Оракл. ODBC/JDBC - соответсвенно Microsoft языки + Ява, есть наверняка еще кучи библиотек доступа для PHP, Perl и прочее.

Объектные базы просто имеют значительно более сложные клиенские библиотеки.

ХОТЯ, есть и именно такие базы как вы и описали.


Andreww

Или эти «объектные базы» настолько круты, что у них есть интерфейс под большинство современных средств разработки и этот инструментарий поспевает за бесконечными обновлениями платформ ?


А что тут такого крутого? Ява 1.3.х-1.4.х-1.5.х не сильно менялась с точки зрения байт-кода, а это между прочим 7 лет развития явы.

Спросите кстати тоже себя про Оракл.

Andreww


«Добавили ссылку» кто ? Если сервер, то вопросов нет. Только на что ссылаемся то? Мы вроде как в многопользовательской среде (если я правильно всё понял) и если после получения экземпляра списка OrderLines ссылкИ на OrderLine поменяются и будут показывать куда ? Стрёмная вещь ссылки да ещё и в распределённой многопользовательской среде.



ТРАНЗАКЦИИ


Andreww


>Реч идет о том, что аналитиков, которые делают SQL к базе данных (в центральном офисе ТНК например) - 25 человек.

Ну тем хуже для ТНК. Я до сих пор не встречал аналитиков (бизнес-аналитиков) у которых SQL в качестве инструмента. Всё больше пакеты всякие для OLAP. А какой там внутри xyzQL это аналитиков мало волнует, им срезы всякие нужны, по кварталам, по месяцам, по-подразделниям и прочее. Прибыль и т.д. Им решения принимать и текущее состояние дел видеть надо. С ужасом представляю как финдиректор, что бы посмотреть сумму прибыли за квартал по подразделениям открывает SQLPlus и начинает писать SELECT …



Под аналитиками я имел в виду людей которые делают SQL + ессно и прочии кубы :)).

Andreww

Странный подход :( Т.е. если у вас заказчик потребует реализовать возможность А и возможность Б вы скажете, берёмся за возможность «Б« а «А», ну как-нибудь потом, она всего-то нужна для 10 человек….


Если требуемая функциональность для 10 людей требует перестройки всей системы, и мы об этом сообщим заказчику, то этих 10 людей попросят сделать это как нибудь по другому. Скорее всего.

Andreww

Может для вас ОСУБД эта некоторая прослойка (вроде сервера приложений) между рел. хранилищем и ОО средой разработки ? Отсюда и запросы на SQL и «странные» требования к драйверу JDBC ?


Спасибо, я отличаю компонентные фреймворки - cервера приложений (EJB), ОРМ - Хибернейт/Кайен и драйвера (JDBC) друг от друга.

Спасибо, в задачу вдаваться не хочу, скучно.
3 сен 05, 16:56    [1843616]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2406
Блог
shuklin
Любопытно, что Ваш тезис верен с точностью до наоборот. Именно в РБД используют деревья индексов для решения описанных Вами проблем абстрагирования от физического хранения данных. Если взять к примеру MS-SQL то можно нарисовать в нем запрос без bookmark lookup что приведет к отсутствию работы с таблицами - использоваться будут только деревья. Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?
Также Вам, вероятно, будет любопытно узнать, что РМД не требует хранения данных в таблицах. Единственное требование - это представление данных пользователю в виде переменных-отношений. И только в виде них. Всё, точка. Как сервер хранит и обрабатывает данные - его проблемы. Хоть сети, хоть деревья, хоть лес деревьев, связанный сетями.
3 сен 05, 18:41    [1843767]     Ответить | Цитировать Сообщить модератору
 Re: Объекты и навигация.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Павел Воронцов
shuklin
Любопытно, что Ваш тезис верен с точностью до наоборот. Именно в РБД используют деревья индексов для решения описанных Вами проблем абстрагирования от физического хранения данных. Если взять к примеру MS-SQL то можно нарисовать в нем запрос без bookmark lookup что приведет к отсутствию работы с таблицами - использоваться будут только деревья. Так вот, зачем организовывать данные в таблицы, если реальную независимость от аппаратного хранения и реальную скорость тех же JOIN дают именно деревья и сети, родные для ОБД?
Также Вам, вероятно, будет любопытно узнать, что РМД не требует хранения данных в таблицах. Единственное требование - это представление данных пользователю в виде переменных-отношений. И только в виде них. Всё, точка. Как сервер хранит и обрабатывает данные - его проблемы. Хоть сети, хоть деревья, хоть лес деревьев, связанный сетями.


В моей СООБЗ данные храняться в виде леса деревьев объектов, связанных сетями. На основе деревьев можно эмулировать табличные структуры. Спасибо за информацию! Теперь я со спокойной душей могу называть свою БД реляционно-объектно-сетевой системой управления знаниями ;)
3 сен 05, 22:28    [1843962]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить