Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 74 75 76 77 78 79 80 [81] 82 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Я осторожно отверждаю, что система только на базах с таблицами была бы сложнее для понимания. Разрабочиков(Java) больше 500, ДВА всего 40.


Для понимания играет роль МД. Как могут понять помочь приложения в понимании тоий инфы что есть в БД? Они тока отдельные внешние аспекты дают. А они представляют данные только для отдельных групп пользователей. И теперь еще и их - приложения надо знать. Кроме того, они могут искажать. Т.е. полную картину о данных в БД дать не могут.
Действительно, РМД для понимания про данные в БД сама по себе может быть сложной. Она нуждается в ER для упрощения понимания того, что есть в БД. Но совсем плохо, если для того, чтобы у знать информационную модель нельзя было обойтись без приложений. Я про то писал. Нужно, чтобы приложения можно ваще выкинуть, а с БД можно было бы работать, напрмер, с другими приложениями.
Тут писали про уровни. Вы выкидываете уровень. Усиливаете зависимость данных от приложений.
Dimonische

Вы уверены, что переведя сотню мегабайт Джава кода в хранимки + хп система будет проще? Я уверен в обратном.

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

Dimonische


ДБА не обходятся, я обхожусь :)

Если ДБА не могут обойтись для решения своих задач без прог разработчика ИС, то скорей всего такая система неоправданно сложна. Они должны иметь возможность выбора любых специально заточенных прогг. Иначе получится из Петрбуга в Москву, через Оренбург. Возможно по бездорожью.
8 апр 05, 14:34    [1452415]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Гон. С помощью ХП можно только получь набор записей, потом опять через отдельные ХП надо звать вложенные коллеции

А вы что хотели получить то? Не данные, которыми представлен объект? Там кроме записей еще есть поля - явно к объекту отношение имеют. Да и запись одна, если объект один. Точнее - он всегда один. Экземпляр объекта в смысле.
А какие вложенные коллекции? Об чем речь?
Так вы их хотите сразу чтоли, одновременно? А зачем они вам? Траффик чтобы был больше? Дольше чтобы отрабатывало? Или еще для чего?

Вот до чего доводит ООП там, где его не нужно использовать - что такое записи не знают, вложенные коллекции подавай. :))

Объясните чтоли, чего сказать то хотели.

-- Tygra's --
8 апр 05, 14:37    [1452433]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
В вышеприведенном примере для хранимого в БД класса geometry_t, была бы приемлима (и удобна) эдакая иерархия:
 class  geometry_t {
    ....
  public:
     void rotate(vector_t * direction, float angle);
     void scale(float scale);
     void translate(vector_t * trans_vector);
....
 }
  class box_t : geometry_t {
    .... 
public:
...
     void rotate(vector_t * direction, float angle);
     void scale(float scale);
     void translate(vector_t * trans_vector);
...
  }
  class point_set_t: geometry_t {
  ...
  public:
     void rotate(vector_t * direction, float angle);
     void scale(float scale);
     void translate(vector_t * trans_vector);
  ...
 }
Тут вам и полиморфизм, и наследование, и методы, которые должна исполнять БД. :)
И действительно тогда удобнее получить экземпляр класса surface_t вместе с включенным объектом geometry_t. :)
8 апр 05, 14:38    [1452450]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну и что мешает представить выше приведенные классы без объектов - на таблицах и ХП? Вроде ничего не мешает.

-- Tygra's --
8 апр 05, 14:43    [1452477]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
Gowest

Гон. С помощью ХП можно только получь набор записей, потом опять через отдельные ХП надо звать вложенные коллеции

Один хрен - и ООБД за один присест "вложенные коллекции" получать не будет. Другое дело, что такие данные, вероятно, будут загружены только при обращении (прозрачный lazy load, скрывающий реальные запросы к БД от программиста).

tygra
Ну и что мешает представить выше приведенные классы без объектов - на таблицах и ХП? Вроде ничего не мешает.

Принципиально ничто не мешает :). Однако некоторые предпочли бы все-таки объекты, думая, что это облегчит жизнь и написание безошибочного кода :)
8 апр 05, 14:48    [1452507]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
tygra
Ну и что мешает представить выше приведенные классы без объектов - на таблицах и ХП? Вроде ничего не мешает.

-- Tygra's --


А вы можете себе представить вычислительные затраты и математическую сложность, скажем, метода scale() для разных объектов. И что будет с сервером БД, если он начнет делать это сам вместо всех клиентов? И как прийдется поизвращаться, чтобы втиснуть этот алгоритм в ХП.
8 апр 05, 14:54    [1452568]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
Alexey Rovdo

А вы можете себе представить вычислительные затраты и математическую сложность, скажем, метода scale() для разных объектов. И что будет с сервером БД, если он начнет делать это сам вместо всех клиентов? И как прийдется поизвращаться, чтобы втиснуть этот алгоритм в ХП.

Да ладно, данный пример принциально извращен. :)
А вычислительные затраты по расчету налогов с учетом отраженных в базе вновь принятых изменений в законы могут оказаться не меньше.....

2 tygra
Представь запрос на увеличение всех объектов geomatry_t в 2 раза и перенос координат вдоль вектора (2,3,4) :
UPDATE Geometry_t g CALL g.scale(2);
UPDATE Geometry_t g CALL g.translate(vector(2,3,4));

"Пашутыли, и хватыт - сказал Леонид Ильич, переклеивая брови под нос" :)
8 апр 05, 15:07    [1452666]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ИМХО сложность вычисления и количесво объектов в данном случае не играю особой роли. Важно принципиальная возможность сделать это. А влияние факторов сложности и количества уменьшаются со временем - в полном соответсвии с закном Мура.

И в конце концов! Неужели ежели эти объекты перместит на клиента,то объем работы волшебным образом уменьшится в 100 раз? Нет! Он останется таким же...однако к нему добявитсякуча здесьвышеописанных проблем связанных с перемещением....:)
8 апр 05, 16:03    [1453036]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 самопал

А что? Нормальные запросы.....
8 апр 05, 16:12    [1453090]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Есть определенное движение, господа. Но в двадцать лет вы так не уложитесь. На маленькую часть таблицы умножения (умножение на 1) ушла неделя. Красивый пример - "путь познания" Dimonische.

Dimonische, 30 марта, 18:32 (оптимистично): "дорогу осилит идущий"

[Это говорится о том, что специалист в области баз данных просто обязан знать, а не осиливать. Поясняю доступным языком (уже раз в десятый) ключевые "результаты" ОО-технологии, в том числе что "методы действительно никак не связаны с триггерами". Dimonische ничего не понимает, но, на всякий случай, повторяет, что я - шизофреник.]

Dimonische, 5 апр., 10:33 (пока продолжает говорить глупости): "Vadiminfo, уже неоднократно тут было сказано про хранимые процедуры и триггеры в Версанте. Что еще Вам нужно от целостности ? Может хватит уже неделями зацикливаться на проблеме, которой нет ?"

"самопал" уже все понял, хотя обязан был знать, если он специалист в области баз данных (если он специалист в другой области, беру свои слова обратно и трижды извиняюсь). И просит подтверждения у партизана Alexey_Rovdo.

Dimonische, 5 апр., 13:51 (удивленно): "...вот это реальная засада, если это так. Я попросту не знаю."

Dimonische, 5 апр., 15:15 (обидно, что оказался дилетантом, но тяга к бесплатным знаниям есть): "... пусть Алексей все-таки покажет нам пример тригера а заодно и раскажет, будет ли он работать полько через обращение к Versant/SQL или через JDO тоже эти триггеры работают."

Dimonische, 5 апр., 15:51 (чистосердечно): "Знаю только что тригера есть."

Dimonische, 6 апр., 10:24 (проснулся): "Я хочу чтобы хранимки+триггера работали всегда... Похоже, это не так. Это печаль."

Dimonische, 6 апр., 13:44 (жизнь продолжается): "Ну с триггерами значит не прокатило. Ок."

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

Вот еще одна, невероятная для специалистов, но на полном серьезе обсуждаемая здесь, "проблема": "что является результатом запроса ?".
Результатом запроса, господа, независимо от модели данных и типа СУБД, является часть базы данных со всей, присущей базе данных, идентификацией и семантикой. А зависит от модели данных, используемой СУБД и инструментов не результат запроса, а его представление пользователю и/или программисту. Например, в "реляционной" системе с идентификацией и семантикой большие проблемы, мягко говоря. И навигации нет, то есть просмотреть результат в естественном виде не удастся (так как нет естественного вида). Поэтому результат представляется в виде отношения. При этом некоторые "специалисты" говорят, что они из существующих фактов получили НОВЫЕ факты. Прямо не СУБД, а система искусственного интеллекта...

Попытаюсь, все-таки, еще раз объяснить вам элементарные понятия из "вашей теории", которые вы не смогли понять в процессе обучения, а теперь уже глаз замылен...
9 апр 05, 01:18    [1454218]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Итак, берем статью Кодда [1979], раз уж здесь сказали, что реляционная модель в этой статье описана намного лучше, чем в [1970].

2.1. Structures

Сначала все идет хорошо. Математика. Отношение. Никаких вопросов. Каждый кортеж уникален. НЕТ ОДИНАКОВЫХ КОРТЕЖЕЙ в отношении по определению. И ничего не нужно дополнительно придумывать для уникальности кортежей. Замечательно. Нет никаких указателей. Связи между отношениями реализуются на значениях атрибутов отношений. Все стройно и замечательно.

И вот в середине этого благополучия появляются ключи. Сначала кандидаты, а потом первичные (внешние уже не появляются, чтобы уж совсем не разрушить формальную основу РМД). Зачем нужны ключи ? И вот, как гром среди ясного неба:

Rule 1 (entity integrity) ...

Да, в скобках, но Кодд вынужден был это написать !

Что за entity ???
Что за integrity ???
Выше эти понятия нигде НЕ ОПРЕДЕЛЕНЫ. У меня хватает интеллекта, чтобы не обзывать Кодда шизофреником, идиотом, демагогом, пустозвоном, уродом и клоуном. Но факт остается фактом.

Что за entity ???
Что за integrity ???
"Что-то подсказывает", что речь (вдруг !) пошла об окружающем мире (многие используют глупое словосочетание "предметная область", как-будто реляционная модель, как и любая другая, создавалась для какой-то предметной области). Который целостен, конечно же. И сущности в нем целостны. И хотелось бы, чтобы данные, представляющие сущности, были бы целостные...
Так что, господа, вы будете еще двадцать лет твердить, что отношения не представляют никаких сущностей и никаких связей между сущностями ? А добровольный помощник Кодда, mir, будет продолжать что-то бубнить про "факты" ?
Ну тогда давайте сразу перейдем на стр. 409:

The need for unique and permanent identifiers for database entities such as employeers, suppliers, parts, etc., is clear.

Вот это да ! Is clear ! Ну для Кодда понятно, что is clear. Для меня тоже is clear.
А больше здесь никто пока не признался, что для него is clear.

А теперь, после простого напоминания, что:

1) ключи, определяемые пользователем - это тупик;
2) пришлось ввести (причем это сделал не Кодд, а Кодд просто поддержал "правильное начинание") "суррогаты";
3) но выйти за пределы отношения невозможно;
4) и приходится отделять сущность от атрибутов сущности с помощью атрибутов сущности;
5) а это фундаментальная глупость;

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

Так для чего нужен (первичный) ключ ?

а) для обеспечения целостности абстрактных данных в реляционной базе данных;
б) для идентификации сущностей ?
в) концептуально для б), а логически для а) ?

И не обижайтесь, господа. От того, что вы меня еще как-нибудь обзовете, знаний у вас не прибавится, и "сравнить СУБД", следовательно, вы не сможете...
9 апр 05, 01:48    [1454230]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>А вы можете себе представить вычислительные затраты и математическую сложность, скажем, метода scale() для разных объектов.

Если речь идет об алгоритмической (она же вычислительная) сложности то она O(N), где N - количество опорных точек в объекте, который масштабируется. Далеко не самая плохая сложность, более того, одна из самых лучших.

>И что будет с сервером БД, если он начнет делать это сам вместо всех клиентов?

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

>И как прийдется поизвращаться, чтобы втиснуть этот алгоритм в ХП.

Если же речь идет каком-то хитром масштабировании, которое должно быть на сервере, то Я Вам уже пытался объяснить, но Вы не слушаете, что С в РСУБД никто не отменял, а в ДБ2 это вообще основной язык SP (как и многие другие, по выбору). Пишите себе scale на С.

Совершенно очевидно, что в случае, когда в задаче мало обращений в базу и много вычислений, то вычисления выгодно выносить из СУБД, в этом случае присоединение серверов приложений оправдано и с этим никто не спорит. Но такие задачи в чистом виде - большая редкость, к тому же этих серверов приложений обязательно должно быть несколько, иначе все преимущества пропадают, остаются одни недостатки.
9 апр 05, 02:59    [1454251]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 самопал

Все правильно, полностью согласен я не заметил Ваш ответ. С масштабированием гораздо короче и проще чем на джаве и C с их циклами. Примерно так:

update coord set x=x*:S, y=y*:S, z=z*:S where ...;
9 апр 05, 03:14    [1454253]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Ну, мне показалось, что в данном примере речь именно об этом и шла.

Впрочем, выше я уже указывал, что в идеале лучше всего иметь возможность выбора (что-то вроде дополнительного параметра при вызове метода), где этот метод исполнять. Возможно по мере распространения управляемых языков эта задача окажется вполне реализуемой.
9 апр 05, 09:27    [1454351]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Мимо пробегал....
Guest
Ув. ЧАЛ!
ГДЕ ПАРА ФОРМУЛ???
9 апр 05, 17:20    [1454677]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

И навигации нет, то есть просмотреть результат в естественном виде не удастся (так как нет естественного вида).

И новый бульбулятор на свалку выкинули.
9 апр 05, 18:23    [1454710]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>Ну, мне показалось, что в данном примере речь именно об этом и шла.

O(N) это не много вычислений.

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

Много выбора тоже плохо. Нет уж, лучше без выбора, но зато по науке.
9 апр 05, 23:49    [1454907]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonani
Guest
самопал

Один хрен - и ООБД за один присест "вложенные коллекции" получать не будет. Другое дело, что такие данные, вероятно, будут загружены только при обращении (прозрачный lazy load, скрывающий реальные запросы к БД от программиста).


Мега гон. Это объектные базы делают совершенно точно.
11 апр 05, 10:35    [1456119]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonani
Guest
c127

O(N) это не много вычислений.


По моему много, а вот O(log N) - это пятерка
11 апр 05, 10:41    [1456151]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonani
Guest
Dimonani - это я, Dimonische

Андрей Леонидович


... поскипан мегаанализ развития Dimonische...



Коллега ЧАЛ жжОт, пеши исчо.

Что лично мне не ясно, зачем проведен данный титанический труд? Доказать что конкретно Dimonische не все знает? Это я бы и сразу мог сказать - да, не все. Мы здесь что, поставили цель опустить друг друга? Отнюдь, коллега ЧАЛ. Мы здесь учимся.А вот что вы здесь делаете, абсолютно непонятно.
11 апр 05, 10:53    [1456194]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Рад за Вас, Dimonani. Учиться нужно всегда...
Но Вы меня несколько озадачили. Своим намеком на то, что я сообщаю что-то общеизвестное, и поэтому мне здесь нечего делать. Ну я рад, конечно, но ощущение, все-таки, что Вы не понимаете что я сообщаю, или понимаете, но не соглашаетесь, а сформулировать не можете. И поэтому решили (как Dimonische, например) именно опустить меня. А вовсе не друг друга. Я же, как раз, никого не опускал. Наверное Вы просто не читали эту дискуссию...
Я же не просто сообщаю людям о пробелах в их профессиональных знаниях (разве это "опускание" ?), но стараюсь эти пробелы восполнить...
И, если Вы были внимательны, наверное заметили - кое-что мне удалось. Но вместо признания очевидных вещей - только обзывания или профессиональные, конечно, но какие-то расплывчатые контраргументы, типа "и новый бульбулятор на свалку выкинули"...
11 апр 05, 19:34    [1458685]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Dimonani

>По моему много, а вот O(log N) - это пятерка

O(N) это очень хорошо, даже сортировка имеет O(N*log(N)). Если нужно что-то сделать со всеми точками, как в случае масштабирования, то лучше вообще не бывает.
12 апр 05, 03:46    [1459115]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
tygra
автор
Веротно это сильно зависит от специфики задачи, но ООСУБД реально используются в этой сфере и довольно активно. Полагаю, что не последнюю роль здесь играет быстродействие при записи больших объемов хоть как-то структурированных данных.

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


Пример приведен. Основной вывод таков:

Реляционные СУБД (Oracle) при записи больших объемов хоть как-то структурированных данных могут быть сравнимы по скорости с ООСУБД (Versant FastObjects t7) только в случае .... отказа от контроля ссылочной целостности !

В ином случае они отстают по быстродействию НА ПОРЯДКИ !
13 апр 05, 20:55    [1466343]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexey Rovdo

Реляционные СУБД (Oracle) при записи больших объемов хоть как-то структурированных данных могут быть сравнимы по скорости с ООСУБД (Versant FastObjects t7) только в случае .... отказа от контроля ссылочной целостности !

Просто теорема Вейрштрасса доказана. Вот тока осталось доказать, что Versant FastObjects t7 будет также не досягаема, если то же будет проделывать опытный Ораклист.
Надо, чтобы настраивал и сервер и проверял иили выбирал логику заинтересованный в успехе Оракла, а не в его проигрыше. Так можно доказать, что черные всегда выигрывают, сыграв самому с собой.
13 апр 05, 22:49    [1466468]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>Реляционные СУБД (Oracle) при записи больших объемов хоть как-то структурированных данных могут быть сравнимы по скорости с ООСУБД (Versant FastObjects t7) только в случае .... отказа от контроля ссылочной целостности !

Вы как всегда пытаетесь делаеть общие выводы на основе частых результатов. На самом же деле нужно было бы сказать примерно так:
"Реляционные СУБД (Oracle), которые сконфигурировал Alexey Rovdo и он же написал скрипты, при записи больших объемов хоть как-то структурированных данных могут быть сравнимы по скорости с ООСУБД (Versant FastObjects t7) только в случае .... отказа от контроля ссылочной целостности!"

И что за пошлые термины, типа "при записи больших объемов...". Нужно говорить "при добавлении.." или же "при вставке...". Потому как если брать например импорт, который тоже "запись" то ваши ООБД и рядом не стоят и Вам это уже много раз объясняли (например тут: https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=138641&pg=26#1466307 ), но похоже не доходит.
14 апр 05, 01:59    [1466590]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 74 75 76 77 78 79 80 [81] 82 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить