Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Анализ выборки сложных данных в FastObjects

Содержание

Теперь проведем анализ работы FastObjects при выполнении Запроса 1. Соответствующий код:

txn = pm.currentTransaction(); // готовим транзакцию
txn.begin(); // открываем транзакцию

// itemExtent – пространство класса Item (все объекты этого класса)
Extent itemExtent = pm.getExtent( avia.model.Item.class, true );
// iter – итератор над пространством класса
Iterator iter = itemExtent.iterator();
// накладываем фильтр на итератор
com.poet.jdo.Extents.setFilter( iter,
   "WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
   "and  this.flight.endpoint.name = \"B\" " );
// теперь через итератор iter доступны только объекты, прошедшие фильтр

// Вывод данных на консоль
System.out.println("id  Date       Description  Class    Free seats");
while (iter.hasNext() )
   {
      Item itm = (Item) iter.next(); // считываем объект
      System.out.println( itm.id + "   " + itm.day + " " +
                          itm.flight.description + "          1-st     " +
                          Integer.toString(itm.flight.crafttype.seats1.size() - itm.tickets1.size()) );
      System.out.println( itm.id + "   " + itm.day + " " +
                          itm.flight.description + "          2-nd     " +
                          Integer.toString(itm.flight.crafttype.seats2.size() - itm.tickets2.size()) );
   }

txn.commit(); // закрываем транзакцию

Итак, что такое пространство класса (Extent)? Пространство класса – это объект, через который программа может получить доступ к любому объекту соотвествующего класса. Создание объекта Extent для класса (в нашем случае avia.model.Item) само по себе не порождает обращений к серверу БД (файлу БД).
Создание итератора (Iterator) над пространством класса - также вспомогательная операция. Хотя само создание итератора и сопровождается обращениями к серверу, но итераторы в реальных приложениях как правило инициализируются однократно, и многократно используются в разных задачах по ходу работы программы. При создании итератора сами объекты, доступные через него, из хранилища данных не выбираются.
Наконец, мы подошли к моменту, когда на серевер посылается некий запрос. Это происходит в момент наложения фильтра на итератор. Наложенный фильтр отрабатывается на сервере и сводится к ограничению пространства класса avia.model.Item объектами, прошедшими проверку WHERE ... ). Соответствующие индексы могут ускорить отработку этого фильтра на сервере. Никаких данных из хранилища в момент наложения фильтра на клиента не поступает.
Считывание объектов из базы данных происходит только в момент выполнения кода iter.next() , который приводит к загрузке на клиента того объекта Item, на который указывает в текущий момент итератор.
При обращении к другим объекта, связанным с объектом Item путем навигации по объектным ссылкам (например, itm.flight.description) соответствующие связанные объекты также считываются в память клиента (в нашем примере будет считан один соответствующий объект Flight). Но как ООСУБД FastObjects производит поиск такого связанного объекта в базе? На примере рассмотренного выше запроса для MS SQL мы выяснили, что в реляционных системах сервер просто ищет в связанной таблице объект с соответствующим идентификатором (с помощью индексов, если они определены). В объектной системе, такой как FastObjects, искать связанные объекты серверу БД не приходится! Дело в том, что сам родительский объект уже хранит точный адрес дочернего объекта. Т.е. встретив в программе обращение вида itm.flight.description ООСУБД FastObjects обращается к полю flight объекта Item. И в этом поле она сразу находит точный физический адрес соответствующего объекта Flight, т.е. никаких операций поиска нет. Далее этот объект по известному адресу выбирается из хранилища и передается на клиента.

продолжение следует ...
8 фев 05, 18:27    [1308854]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Сравнение эффективности MS SQL и FastObjects

Содержание

Итак, мы рассмотрели на одном конкретном примере плюсы и минусы двух решений. Выяснилось следующее:

Решение на базе MS SQL порождает множество операций поиска (Nested Loops) при обработке запросов, содержащих JOIN-конструкции. Количество таких операций тем больше, чем большее количество JOIN-конструкции присутствует в запросе.

Количество JOIN-конструкций в запросах можно сократить, но платой за это будет упрощение модели данных и внесение в нее не всегда оправданных ограничений.

Для оптимальной обработки запросов, содержащих JOIN-конструкции, MS SQL предполагает поддержание большого количества индексов.

Сложные SQL-запросы не всегда легко читаются и требуют высокой квалификации разработчика для построения оптимальных поисковых фраз.

Обращения к объектам посредством навигации в FastObjects не приводят к необходимости их поиска и необходимости поддержания индексов для этих объектов.

Навигация по цепочке объектов приводит к тому, что все объекты цепочки полностью загружаются из хранилища данных на клиента.

продолжение следует ...
8 фев 05, 18:28    [1308858]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Содержание

Какие же выводы можно сделать из приведенных выше фактов?
Обладая рядом преимуществ, объектные технологии порождают и определенные проблемы. И говорить о явном превосходстве FastObjects над MS SQL или наоборот (даже в рамках рассмотренного примера) не вполне корректно. Но можно констатировать следующее.

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

Указанные выше проблемы чистых SQL-решений обычно вынуждают разработчиков упрощать модели данных предметной области с тем, чтобы сократить трудоемкость написания SQL-кода. В некоторых ситуациях помогает перенос определенной части поведенческой логики системы с сервера БД на приложение (читай в клиентскую программу на Java, C++ ... ), но переход на ООСУБД делает такой перенос совершенно естественным и более-того – неизбежным (прошу не путать приложение-клиента ООБД с приложением конечного пользователя – это определяется общей архитектурой и количеством звеньев системы).

В любом случае стоит обратить внимание на то, что FastObjects позволяет решат разные задачи весьма эффективно, а иногда – гораздо эффективнее реляционных систем.

С уважением, Алексей Ровдо
8 фев 05, 18:29    [1308864]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alex.Czech
Guest
Вы бы еще в строгий квадрат первый запрос вписали, чтобы уж и лучшие специалисты не разобрались, что же там ошибочное, особенно без постановки задачи рядом с запросом :) Это Аксесс вам такое сгенерил что ли ? Он может
8 фев 05, 18:31    [1308868]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Alex.Czech
Вы бы еще в строгий квадрат первый запрос вписали, чтобы уж и лучшие специалисты не разобрались, что же там ошибочное, особенно без постановки задачи рядом с запросом :) Это Аксесс вам такое сгенерил что ли ? Он может


Постановка задачи здесь. (Задача 1)
Пример работающего запроса (выдающего именно то, что нужно) имеется в моем тексте. Описание модели данных здесь.
Вот и скажите мне (желательно на глаз). Что в этом запросе неправильно? А работает он именно неправильно - факт.

Кстати, можете предложить и свой вариант такого запроса - я их уже коллекционирую.
8 фев 05, 18:38    [1308883]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

Навигация по цепочке объектов приводит к тому, что все объекты цепочки полностью загружаются из хранилища данных на клиента.

А в MS SQL не все что нужно загружается клиенту?
Конечно, соединение одна из самых дорогих операций. И поэтому в конструкторских приложениях или др спец приложениях где может возникнуть несусветное кол-во табл даже и мелких - это не лучшее из лучшего для РМД. Вы могли взять и другие спец приложения, где само уже моделирование данных для РМД не очень хорошо. Однако, не забывайте про ОРМД – она может преодолеть это.
Для типовых бизнес приложений в запросах не очень много соединений. А с точки зрения выразительности - соединение более выразительно и читабельно, чем итерации в навигации, что Вы представили (тем более итераторы – классы всякие). И план запроса тот, что Вы написали тоже дает не все сведения об эффективности. Например, кроме Nested Loops, есть HASH JOIN и SORT MERGE. Есть оптимизаторы запросов в СУБД, которые могут подобрать эффективный план запроса. К тому же если мы говорим об эффективности, то это не всегда вопрос модели данных, которая есть нечто логическое. Это больше физический аспект. И здесь может большую роль играть вообще достижения в плане алгоритмов. Кроме того, для физического проектирования, есть и др средства. Для соединений есть -–кластеры. Есть секционирование таблиц, есть мат представления. Если, например, компы станут с несусветной оперативной памятью, то индексы станут не нужны, а если с ассоциативной то станет возможно значительное распараллеливание запросов и, возможно, указатели станут играть меньшую роль.
Модель данных все-таки важнее.
Я вот напоминал, что на своей заре РМД сильно уступала в производительности иерархическим системам, но сразу захватила часть рынка. А преимущества у иерархических систем ровно те же, что Вы здесь привели. Хотя для них много типов записей, наверное, тоже не лучшее из лучшего.
8 фев 05, 19:16    [1308969]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Я..эта... не могу понять одной весчи... вот Вы говорите, что дескать послали запрос и он нам вернул объекты очень быстро. А я как бы хочу взглянуть на систему целиком. То сеть ежели бы объекты постоянно висели в памяти сервера, то может проблем бы и меньще было. Но ведь они храняться на диске?... И ведь он должен загрузть объект в свою память? Иначе, например, станет невозможным выполнить НА СЕРВЕРЕ запрос типа вернуть из экстента (и кстати, ведь могут быть классы без экстенов...этиж экстенты еще как то формировать надо) класса объекты, у которых какой_то_метод() = какому_то_значению....ну не тащить же их на клиента для этого... Соответсвенно возникает необходимость всяческого чтения, всяческих отображений в память и привязок....и т.п. нехилых операций. Я не думаю, что там все так просто и быстро. (повотяю - я просто хочу рассмотреть систему в целом - начиная от дисков).

Потом..... касаемо индексов...ябы не стал прям так индексы с JOIN-ами связывать.... это всеж немножко разные и не совсем связанные весчи....Вот ежели в SQL мы сделаен некое (любое!) поле индексируемым, то скажем запрос "выбрать ... где это_поле > ... и это_поле <..." будет отрабатываться очень быстро, поскольку сервер не будет перебирать все записи, а, ориентируясь на индекс, выберет нужные. Я повторяю - индексировать можно любое поле, причем буквально на ходу... во всяком случае для этого не надо будет перекомпилять клиента :).... Перефразируя известную фразу, я бы осмелился утверждать, что индексы не только вредны, но и полезны, и рубить с плеча, что раз индексов нет, то это хорошо, это большая смелость. Что по этому поводу есть сказать о Ваших продуктах.

Далее. Предположим нам нужно сделать некую не очень тривиалную операцию над всего одним атрибутом многих-многих находящихся в экстенте. SQL по запросу (как вы сами понимаете, незапланированому...типа из консоли) вернёт табличку с одним(требуемым) атрибутом, и дальше делай с ней что хошь. А как ваша система? Не получится ли, что придется тащить все объекты, и на клиенте циклом доставать из них требуемое значение?

И, наконец, общие впечатление... Лично меня Ваши последние аргументы не впечатли. стиль слегка напминает небезизвестного Андрея Леонидовича, который сночала приводит программу на китайском языке У, утверждая .что это круто, а потом начинает опускать SQL СУБД, поскольку там не все гладко, и вообще это вчерашний день и субъект там не противопоставлен объекту. А прям так связывать индексы и JOIN-ы..это либо непонимание о чем речь, либо хитрый-хитрый........уууу....какой хитрый:) маркетинговый ход
8 фев 05, 21:06    [1309120]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>"говорить о демагогии" - это уже какая-то демагогия в квадрате получается.

Не хотите отвечать за свои слова - не надо, Вам же хуже.

>В условии задачи маршрут (рейс) задается своим началом и концом (две точки). Из представленной структуры следует, что полное описание маршрута (рейса) будет храниться в поле caption таблицы Race.

Там же написано: caption описание. Уже по этому можно было догадаться, что это не маршрут. Откуда же следует что там будет храниться маршрут? Да еще так безапеляционно. Нужно довольно безграмотным, чтоб подумать, что в реляционной базе маршрут вида [A,B] засунут в единственное поле.

>Короче говоря, учет ряда аналогичных поправок (например, в отношении поля «номер места» в таблице Sold) приведет нас ровно к той модели, которая выше была использована в моем примере.

Фразу "учет ряда аналогичных поправок" нужно дополнить словами "и моего ограниченного опыта работы с РСУБД", тогда будет похоже на правду.

>Замечу, кстати, что всячески пропагандируемое здесь c127 решение SergSuper не является ПОЛНЫМ и ПРАВИЛЬНЫМ хотя бы потому, что допускает двоякое толкование. Например, и следующая модель будет полностью соответствовать описанию:

Уважаемый, то что 2 разные модели удовлетворяют постановке задачи, то это не проблема моделей, это проблема постановки задачи. Поэтому нельзя сказать, что решение "не является ПОЛНЫМ и ПРАВИЛЬНЫМ", оно может быть и полным и правильным, нужно говорить что решение НЕ ЕДИНСТВЕННОЕ.

>Чтобы не быть раскритикованным за использование неоптимального запроса, я начинаю с детального его рассмотрения и оптимизации по ряду параметров. И пежде всего оказывается, что этот запрос вообще ОШИБОЧНЫЙ. Что же в нем не так ? Полагаю только очень немногие спецы высокого класса смогут увидеть ошибку в этом исходном коде без запуска запроса на контрольных данных (поясняю для малограмотных – вот для чего нужны тестовые данные – чтобы проверять на них корректную работу написанных запросов).

Мы тут малограмотные, поэтому не подозреваем о том, что проверка запроса на тестовых данных не гарантирует его правильности. Запрос может работать и выдавать правильный результат на тестовых данных и выдавать ошибку на реальных данных. Поэтому прогон запроса на тестовых данных, тем более содержащих 4 записи, по большому счету ничего не дает. Но шибко грамотные по-видимому даже не подозревают об этом.

>Таким образом, мы видим следующую особенность SQL: надо обладать сверхпрофессиональными знаниями и своего рода чутьем, чтобы из одного только вида SQL-запроса однозначно делать выводы о его работоспособности. Как результат, на практике при написании SQL-запросов сама проверка на контрольных данных становится необходимой частью процесса разработки, а не его логическим завершением на этапе тестирования.

Это шедевр. Самому написать неправильный запрос, и потом этот факт выдавать как доказательсво своей точки зрения.

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

>Но когда число JOIN-конструкций в запросе зашкаливает за 20, даже у самых высокопрофессиональных разработчиков возникаю серьезные трудности с отладкой и тестированием.

Это на своем примере, надо понимать. Скромный Вы.

А вот еще шедевр:
>Указанные выше проблемы чистых SQL-решений обычно вынуждают разработчиков упрощать модели данных предметной области с тем, чтобы сократить трудоемкость написания SQL-кода.

Кто знает, тот поймет.


А теперь по поводу Ваших измышлизмов об оптимизаторе МССКЛ. Работа проделана обширная, но бессмысленная. По-видимому по необразованности автора опуса не учтена одна маленькая деталь, которая перечеркивает все приведенные измышлизмы.

Ну да, именно так и есть, вот и подтверждение:
>Поэтому единственным выходом я вижу анализ порядка исполнения запросов и программного кода, а также оценку объемов вычислений и пересылаемых данных.

Дело в том, что оптимизатор в МССКЛ (как во всех серьезных СКЛ серверах) cost based. Для негоамотных объясняю, что это значит, что план выбирается с учетом количества и распределения данных в таблицах. На пальцах это значит, что для таблиц, где будет несколько сот тысяч записей план скорее всего будет отличаться от того, который оптимизатор построил для Ваших тестовых данных в 5 записей.

Я же Вам пытался сказать, что на данных в 5 записей в таблице сравнивать быстродействие - идиотизм. Но Вы никого слушать не хотите и продолжаете упорствовать ("К моему сожалению, мало осмысленный спор с c127 об абстрактных достоинствах и недостатках различных SQL-решений увел нас от сравнения эффективности (быстродействия) решений на базе MS SQL и FastObjects". (Alexey Rovdo)). На этих данных даже индексы не всегда используются, поскольку прямой перебор часто быстрее, отсюда и просмотры таблиц и гиганские объемы "вычислений и пересылаемых данных". Так что из Вашего аналаиза получилося очередной пшик. Хотите тратить время на подобный анализ - дело Вашие, но продать свои ООБД тут Вы уже врядли сможете.
9 фев 05, 04:09    [1309404]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

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

Сперва вы сомневались в самой возможности решения придуманной мною задачи средствами ООП или предполагали высокую трудоемкость разработки такого решения. Решение было мною представлено.

Затем вы пытались обгадить мое решение, утверждая, что оно намного длиннее. Я написал конкретный пример и для MS SQL и показал, что, если мы рассматриваем не "сферический сервер вакууме",а пару приложение+БД, то преимущество скорее у FastObjects.

Потом вы принялись утверждать, что примененная мною модель данных не имеет ничего общего с решением SergSuper, а само это решение ПОЛНОЕ и ПРАВИЛЬНОЕ и ничего правильнее быть не может. Я не поленился и показал вам, что это не точное решение, а скорее некоторое множество возможных решений. Более того, в Запросе 1 этого решения присутствует ошибка.

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

На мой взгляд ваши язвительные замечания пока приводят только к тому, что премущества FastObjects в конкретной рассматриваемой задаче проявляются все отчетливее.

Если вы действительно обладаете хотя бы какими-нибудь практическими навыками, то могли бы предложить свое (более правильное) конкретное решение, конкретные тексты запросов на SQL и конкретные планы этих запросов при больших объемах данных. А если не можете, то о чем тогда вообще с вами говорить - демагогия не моя стихия.
9 фев 05, 10:23    [1309780]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
На мой взгляд ваши язвительные замечания пока приводят только к тому, что премущества FastObjects в конкретной рассматриваемой задаче проявляются все отчетливее.

А если повторить выделенное мной еще эдак .... 300 раз, то преимущества, наверное, станут просто неоспоримыми А если разослать это еще тремстам адресатам, то ваще будет щастте. :)

ЗЫ Я с интересом наблюдаю за топиком. Почти ничего не пишу сюда - и есть кому писать, и смысл мне еще? Толку то нет. То, что название FastObjects уже рефлексорно вызывает приступы тошноты у присутствующих, кроме вас конечно - это уже точно неоспоримый факт.
В общем.... Как не помню кто тут написал, или в соседнем похожем топике, у меня есть достаточно большой запас попкорна и пепси, так что надеюсь, что досмотрю до конца это кино.


Ничего личного....

-- Tygra's --
9 фев 05, 11:22    [1310042]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
x
Guest
Alexey Rovdo
В объектной системе, такой как FastObjects, искать связанные объекты серверу БД не приходится! Дело в том, что сам родительский объект уже хранит точный адрес дочернего объекта. Т.е. встретив в программе обращение вида itm.flight.description ООСУБД FastObjects обращается к полю flight объекта Item. И в этом поле она сразу находит точный физический адрес соответствующего объекта Flight, т.е. никаких операций поиска нет.

Я думаю, Вы выдаете желаемое за действительное.
В объектных системах идентификатор объекта не является физическим адресом. Использование в качестве идентификатора объекта физического адреса порождает слишком много проблем при перемещениях объекта.
9 фев 05, 11:33    [1310063]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...

Я..эта... не могу понять одной весчи... вот Вы говорите, что дескать послали запрос и он нам вернул объекты очень быстро. А я как бы хочу взглянуть на систему целиком. То сеть ежели бы объекты постоянно висели в памяти сервера, то может проблем бы и меньще было. Но ведь они храняться на диске?... И ведь он должен загрузть объект в свою память? Иначе, например, станет невозможным выполнить НА СЕРВЕРЕ запрос типа вернуть из экстента (и кстати, ведь могут быть классы без экстенов...этиж экстенты еще как то формировать надо) класса объекты, у которых какой_то_метод() = какому_то_значению....ну не тащить же их на клиента для этого... Соответсвенно возникает необходимость всяческого чтения, всяческих отображений в память и привязок....и т.п. нехилых операций. Я не думаю, что там все так просто и быстро. (повотяю - я просто хочу рассмотреть систему в целом - начиная от дисков).


Все не просто. И говорить что ВСЕ БЫСТРО я не стану. Кое-что быстро, кое-что - нет.
Вы затронули одну из основных проблем ООСУБД, связанную с запросами, в которых критерий выборки включает вызов метода (какой_то_метод() = какому_то_значению....). В целом такая проблема до сих пор универсального решения не имеет и в разных продуктах предлагаются различные подходы. В FastObjects она фактически просто вынесена за рамки продукта. Дело в том. что FO не хранит методы в БД. Т.е. осуществить подобную выборку вы сможете только в своем приложении. Другое дело, что сама база данных физически может находиться не на отдельном сервере, а на том же самом компьютере, на котором вы запускаете ваше приложение. А такие конфигурации могут иметь место во многих случаях. Например, когда само это приложение не является собственно клиентским приложением, а играет роль промежуточного сервиса (например, Jboss-сервер позволяет подцепить FO через JCA-адаптер и если сама БД FO лежит на этом же компьютере, то излишнего трафика не возникает. Аналогично можно использовать FO .NET при написании Web-сервисов на C# под IIS и т.п.). Если же сервер БД находится на отдельном компьютере, то такая выборка в FO неизбежно приведет к пересылке всех объектов целиком на компьютер с приложением - тут уже ничего не поделаешь. Если количество таких объектов не очень велико и может уместиться в памяти клиента, то при следующем запросе к переданным объектам данные уже будут браться из кэша, а не повторно запрашиваться с сервера.
Про экстенты. Разумеется поддержание экстентов требует определенных (вполне разумных) ресурсов на сервере. Для экономии этих ресурсов можно отключать экстенты для определенных (или всех) классов. Доступ к элементам таких классов через итераторы становится невозможен - остается только доступ через навигацию. Само создание экстента не подразумевает загрузку всех его объектов (или ссылок на них) с диска в память сервера. Экстент это достаточно виртуальная конструкция - своего рода интерфейс к объектам одного класса (полагаю, что термин "пространство класса" как раз очень неплохо передает суть экстентов).

Мимо пробегал...

Потом..... касаемо индексов...ябы не стал прям так индексы с JOIN-ами связывать.... это всеж немножко разные и не совсем связанные весчи....Вот ежели в SQL мы сделаен некое (любое!) поле индексируемым, то скажем запрос "выбрать ... где это_поле > ... и это_поле <..." будет отрабатываться очень быстро, поскольку сервер не будет перебирать все записи, а, ориентируясь на индекс, выберет нужные. Я повторяю - индексировать можно любое поле, причем буквально на ходу... во всяком случае для этого не надо будет перекомпилять клиента :).... Перефразируя известную фразу, я бы осмелился утверждать, что индексы не только вредны, но и полезны, и рубить с плеча, что раз индексов нет, то это хорошо, это большая смелость. Что по этому поводу есть сказать о Ваших продуктах.


Вы не правильно трактовали упоминание мною индексов в связи с JOIN-ами. Я и не пытался утверждать что "раз индексов нет, то это хорошо". Вопрос в другом. Использование JOIN практически вынуждает нас создавать соответствующие индексы (естественно, мы можем и не делать этого, но тогда JOIN будет работать медленнее). В моем примере показано, что количество индексов, необходимых с точки зрения оптимизации быстродействия, в реляционной СУБД оказывается больше, чем в ООСУБД (в моем примере для оптимизации запроса 1 достаточно двух индексов). Но само поддержание индексов тоже требует определенных ресурсов и замедляет работу системы в моменты ввода и модификации данных. И именно с этой точки зрение уменьшение числа НЕОБХОДИМЫХ индексов является положительным фактором.

Мимо пробегал...

Далее. Предположим нам нужно сделать некую не очень тривиалную операцию над всего одним атрибутом многих-многих находящихся в экстенте. SQL по запросу (как вы сами понимаете, незапланированому...типа из консоли) вернёт табличку с одним(требуемым) атрибутом, и дальше делай с ней что хошь. А как ваша система? Не получится ли, что придется тащить все объекты, и на клиенте циклом доставать из них требуемое значение?


В FO прийдется тащить, если мы работаем через экстент (см. мой ответ на первый вопрос). Но мы можем сделать запрос именно к этому атрибуту (типа: SELECT person.first_name FROM Persons AS person) и получим коллекцию значений именно этого атрибута.
Замечу, однако, что это скорее административныа операция. В типовых приложениях мы обычно работаем с весьма ограниченными наборами объектов.

Мимо пробегал...

И, наконец, общие впечатление... Лично меня Ваши последние аргументы не впечатли. стиль слегка напминает небезизвестного Андрея Леонидовича, который сночала приводит программу на китайском языке У, утверждая .что это круто, а потом начинает опускать SQL СУБД, поскольку там не все гладко, и вообще это вчерашний день и субъект там не противопоставлен объекту. А прям так связывать индексы и JOIN-ы..это либо непонимание о чем речь, либо хитрый-хитрый........уууу....какой хитрый:) маркетинговый ход


Я вовсе не ставлю своей целью "опустить SQL БД". Я просто придерживаюсь того мнения, что SQL БД неправильно использовать для решения любых задач, предполагающих наличие некоторого хранилища данных. Причем я не оспариваю саму возможность использования SQL БД практически везде, но вот рациональность этого далеко не очевидна. Выше по топику было очень много сказано о чрезвычайной удобности и качественности популярнейших реляционных систем, а эффективность и удобство объектно-ориентированного подхода к разработке приложений с базами данных были поставлены под сомнение. Слепая вера некоторых апологетов реляционных систем в их безупречность и преимущество над всем "остальным" в конечном итоге может сослужить им плохую службу. Приведенные примеры и замечания показывают, что в любых продуктах и технологиях (MS SQL, Oracle, FastObjects, VDS ...) существуют свои изъяны, а правильный выбор во многом зависит и от предметной области и от конкретной задачи и от пристрастий и вкусов разработчика.
9 фев 05, 11:46    [1310125]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
x
Alexey Rovdo
В объектной системе, такой как FastObjects, искать связанные объекты серверу БД не приходится! Дело в том, что сам родительский объект уже хранит точный адрес дочернего объекта. Т.е. встретив в программе обращение вида itm.flight.description ООСУБД FastObjects обращается к полю flight объекта Item. И в этом поле она сразу находит точный физический адрес соответствующего объекта Flight, т.е. никаких операций поиска нет.

Я думаю, Вы выдаете желаемое за действительное.
В объектных системах идентификатор объекта не является физическим адресом. Использование в качестве идентификатора объекта физического адреса порождает слишком много проблем при перемещениях объекта.


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

К сообщению приложен файл. Размер - 0Kb
9 фев 05, 12:05    [1310202]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Alexey Rovdo
Я вовсе не ставлю своей целью "опустить SQL БД". Я просто придерживаюсь того мнения, что SQL БД неправильно использовать для решения любых задач, предполагающих наличие некоторого хранилища данных.
Эта фраза говорит только о том, что Вы не понимаете назначения СУБД. Просто как хранилище SQL СУБД действительно использовать неразумно - слишком большой overhead. А вот если нужно, чтобы данные оставались самосогласованными и защищёнными вне зависимости от количества и качества систем (читай - программ), их использующих и/или изменяющих, тогда да. В монолитной системе применение ООСУБД или XML СУБД или ещё какой-нить супер-пупер-новой или старой (IMS к примеру) технологии может быть и оправдано. Кто б спорил...
9 фев 05, 12:32    [1310345]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Вы затронули одну из основных проблем ООСУБД, связанную с запросами, в которых критерий выборки включает вызов метода (какой_то_метод() = какому_то_значению....). В целом такая проблема до сих пор универсального решения не имеет и в разных продуктах предлагаются различные подходы. В FastObjects она фактически просто вынесена за рамки продукта. Дело в том. что FO не хранит методы в БД. Т.е. осуществить подобную выборку вы сможете только в своем приложении. Другое дело, что сама база данных физически может находиться не на отдельном сервере, а на том же самом компьютере, на котором вы запускаете ваше приложение. А такие конфигурации могут иметь место во многих случаях. Например, когда само это приложение не является собственно клиентским приложением, а играет роль промежуточного сервиса (например, Jboss-сервер позволяет подцепить FO через JCA-адаптер и если сама БД FO лежит на этом же компьютере, то излишнего трафика не возникает. Аналогично можно использовать FO .NET при написании Web-сервисов на C# под IIS и т.п.). Если же сервер БД находится на отдельном компьютере, то такая выборка в FO неизбежно приведет к пересылке всех объектов целиком на компьютер с приложением - тут уже ничего не поделаешь. Если количество таких объектов не очень велико и может уместиться в памяти клиента, то при следующем запросе к переданным объектам данные уже будут браться из кэша, а не повторно запрашиваться с сервера.

У вас тут очень много если. От них аж глаза рябит.

А в РСУБД этих всех если нет - она одинаково хорошо будет работать, как бы вы чего не размещали.

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

В общем..... Ыыыыыыыыыыыыыы........ Кууууууууу....

-- Tygra's --
9 фев 05, 12:35    [1310358]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

У вас тут очень много если. От них аж глаза рябит.

А в РСУБД этих всех если нет - она одинаково хорошо будет работать, как бы вы чего не размещали.

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

В общем..... Ыыыыыыыыыыыыыы........ Кууууууууу....

-- Tygra's --


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

А говоря по существу топика - о СУБД Versant, я ведь не ратую за использование этих средств всюду. Более того, я согласен и с тем, что большинство типовых систем лучше строить на традиционных реляционных СУБД. Но тенденции сегодня таковы, что информационные системы усложняются. Усложняются и структуры хранимых и обрабатываемых в них данных, а требования к скорости разработки в то же время ужесточаются. И упомянутые мною "если" вовсе не являются конструкцией возможной лишь в теории - они регулярно встречаются в реальной жизни. И по моим представлениям 5-10% разрабатываемых в настоящее время систем вполне удовлетворяют этим "если", поэтому переход на объектные технологии хранения и обработки данных для них более чем осмыслен и при грамотном подходе способен принести немалые дивиденды.
9 фев 05, 14:35    [1310847]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Павел Воронцов
Просто как хранилище SQL СУБД действительно использовать неразумно - слишком большой overhead. А вот если нужно, чтобы данные оставались самосогласованными и защищёнными вне зависимости от количества и качества систем (читай - программ), их использующих и/или изменяющих, тогда да. В монолитной системе применение ООСУБД или XML СУБД или ещё какой-нить супер-пупер-новой или старой (IMS к примеру) технологии может быть и оправдано. Кто б спорил...


Начнем с того что некоторые спорят.
Ну а требование "чтобы данные оставались самосогласованными и защищёнными" вообще говоря нуждается в пояснении. На мой взгляд существует не так уж много ситуаций, когда данные сами по себе могут кого-то интересовать без приложений, обеспечивающих работу с этими данными. Модель, в которой данные оторваны от приложений (а именно эта модель лежит в основе популярных РСУБД), обладает как достоинствами, так и недостатками. И в разных ситуациях они вылазят по разному.
Что касается самосогласованности и защищенности, то в моей практике встречалось мало систем, в которых все правила обеспечения целостности данных были корректно определены в самой СУБД. Разработчикам зачастую удобнее выносить это на уровень бизнес-логики, который как-раз может реализовываться в виде приложения. Разумеется, они могут использовать и все возможности СУБД, но нет никаких причин делать это в обязательном порядке (если по регламенту использования системы никто не лазит в ней с помощью Query Analyzer или SQL+).
Сегодня системы с публичным неконтролируемым доступом (читай с доступом из разных не всегда качественно написанных приложений) ориентируются на использование сервисов (Web-сервисы). А в таких ситуациях, как я уже отмечал, ООСУБД очень даже уместны, поскольку хорошо согласуются с идеологией сервис-ориентированной архитектуры и XML.
9 фев 05, 14:51    [1310915]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Забавно, что некоторые считают ООСУБД (или, возможно FastObjects и Versant Developer Suite) чем-то супер-новым, в то время как этой технологии (и этим продуктам) уже более двух десятков (10-15) лет.
9 фев 05, 15:06    [1310995]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
ЭЭххххх ЁЁёёёёёёёёёё..........

автор
Ну а требование "чтобы данные оставались самосогласованными и защищёнными" вообще говоря нуждается в пояснении.

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

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

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

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

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

А зачем вам тогда СУБД вообще? Есть же dbf, чего СУБД коверкать? Или 1с под SQL для вас идеал? Тогда об чем разговор?
автор
Сегодня системы с публичным неконтролируемым доступом (читай с доступом из разных не всегда качественно написанных приложений)

это что за звери?
автор
ориентируются на использование сервисов (Web-сервисы).

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

Вы видать подумали, да не сказали, потому как я не пойму что-то, в каких таких ситуациях и главное почему уместны ООСУБД и причем тут вебсервисы?

Напрашивается плохой, но нужный вопрос:
Вы вообще видели человечески сделанные к-с системы на основе РСУБД? Вы сами пытались хоть что-нибудь сделать?

И еще один ответ: похоже, что вы не понимаете, для чего используется РСУБД. Потому как вы даже не поняли вопрос:
Павел Воронцов
Эта фраза говорит только о том, что Вы не понимаете назначения СУБД. Просто как хранилище SQL СУБД действительно использовать неразумно - слишком большой overhead. А вот если нужно, чтобы данные оставались самосогласованными и защищёнными вне зависимости от количества и качества систем (читай - программ), их использующих и/или изменяющих, тогда да. В монолитной системе применение ООСУБД или XML СУБД или ещё какой-нить супер-пупер-новой или старой (IMS к примеру) технологии может быть и оправдано. Кто б спорил...

О чем мы тут все тогда говорим???????????????????????????????????????
==================

автор
Забавно, что некоторые считают ООСУБД (или, возможно FastObjects и Versant Developer Suite) чем-то супер-новым, в то время как этой технологии (и этим продуктам) уже более двух десятков (10-15) лет.

Так какого ж %;№ они до сих пор в полной ж....??? В отличие от РСУБД.

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

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

-- Tygra's --
9 фев 05, 15:48    [1311174]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Alexey Rovdo
Забавно, что некоторые считают ООСУБД (или, возможно FastObjects и Versant Developer Suite) чем-то супер-новым, в то время как этой технологии (и этим продуктам) уже более двух десятков (10-15) лет.


Не знаю как некоторым, а я посмотрев как Вы реализовали вспомнил как я писал лет 15 назад. Возвращаться желания нет.

Ну и конечно эта фраза настоящего маркетолога, предлагаю поместить в музей:

этой технологии (и этим продуктам) уже более двух десятков (10-15) лет
9 фев 05, 17:32    [1311502]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Им год за два идет

-- Tygra's --
9 фев 05, 17:47    [1311542]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Так какого ж %;№ они до сих пор в полной ж....??? В отличие от РСУБД.

Им год за два идет

-- Tygra's --


Знаете, есть очень хорошее высказывание на эту тему.

Если вы нагнулись и увидели, что у вас четыре яйца, то не спешите радоваться - просто вас кто-то е***.

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

Что же касается ООСУБД и продуктов Versant, то незнание вами истории вовсе ее не отменяет.
А уcпешное применение этих решений на западе в крупнейших компаниях говорит многим о многом, но не вам. Игнорируя реальные факты можно до бесконечности поносить любой продукт и технологию. Поэтому см. сначала.
9 фев 05, 18:48    [1311745]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

> демагогия не моя стихия

Кстати о демагогии:

Alexey Rovdo>На примере рассмотренного выше запроса для MS SQL мы выяснили, что в реляционных системах сервер просто ищет в связанной таблице объект с соответствующим идентификатором (с помощью индексов, если они определены).

На примере ничего выяснить нельзя, за исключением того случая, когда это контрпример. MS SQL ищет, а например постгреСКЛ может и не ищет. Но это к слову, идем дальше.

Alexey Rovdo>В объектной системе, такой как FastObjects, искать связанные объекты серверу БД не приходится! Дело в том, что сам родительский объект уже хранит точный адрес дочернего объекта. Т.е. встретив в программе обращение вида itm.flight.description ООСУБД FastObjects обращается к полю flight объекта Item. И в этом поле она сразу находит точный физический адрес соответствующего объекта Flight, т.е. никаких операций поиска нет. Далее этот объект по известному адресу выбирается из хранилища и передается на клиента.

Вот вам один из примеров демагогии. Сравнивается случай 1:N в РМД и 1:1 в ОМД. Просто автор своим "while (iter.hasNext() )" прошел по таблице, о чем упомянул намного выше, но в данный момент уже забыл. Вот так и получается, что "В объектной системе, такой как FastObjects, искать связанные объекты серверу БД не приходится!". Создайте в РСУБД курсор по таблице с тем же критерием, что у Alexey Rovdo в фильтре, напишите "FETCH NEXT curs into ....;" внутри этого цикла и обращайтесь к полям ТЕКУЩЕЙ записи сколько душе угодно без всякого поиска.


>Сперва вы сомневались в самой возможности решения придуманной мною задачи средствами ООП

Ссылку выложите. А то болтаете языком как Андрей Леонидович.

>или предполагали высокую трудоемкость разработки такого решения.

Оно дейтствительно примерно в 4 раза более трудоемкое.

>Решение было мною представлено.

Через месяц.

>Я написал конкретный пример и для MS SQL и показал, что, если мы рассматриваем не "сферический сервер вакууме",а пару приложение+БД, то преимущество скорее у FastObjects.

Вам не надоело спекулировать на этой сказке?

В Вашем ОМД решении параметры тоже приходят из вакуума, а вывод результатов не соответствует постановке задачи. Но Вас это не смущает. К тому же ввод результатов при сравнении решений не учитывался, если бы я по ошибке учел Ваш ввод данных, то превосходство реляционного решения было бы не в 4 раза а в 8 раз. Я на это уже обращал Ваше внимание.

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

>Потом вы принялись утверждать, что примененная мною модель данных не имеет ничего общего с решением SergSuper, а само это решение ПОЛНОЕ и ПРАВИЛЬНОЕ и ничего правильнее быть не может.

Ссылку, где я говорил, что правильнее быть не может? Опять болтаем языком.

Я говорил, что автор выбрал это решение, предложил его первым, с ним и нужно работать. В крайнем случае спросить у автора разрешения поменять. А не курочить в меру своего незнания реляционной модели. Вы это решение не поняли, а лезете с изменениями. Вы предложили свое реляционное решение, в результате получилось не сравнение моделей, а сравнение знаний Alexey Rovdo о разных моделях.

>Теперь вы нашли очередную точку - объем контрольных данных.

Вы знаете что такое cost-based оптимизатор? Зачем нести эту чушь.

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

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

Предложить много чего можно. Но есть решение, предложенное первым, так уж сложилось. Либо сравнивайте его, либо скажите что Вы придумали другое, не имеющее к первому никакого отношения. Тогда можно будет сравнивать Ваше.

>и конкретные планы этих запросов при больших объемах данных.

Очень интересно, а как Вы предполагаете сравнивать планы, вообще что с чем сравнивать? Что-то я до сих пор видел план запроса от FastObjects. Вообще-то эти планы запросов появились по-моему как средство спасения FastObjects.

Вот интересно, а что Вы там сумеете сравните при совршенно разных моделях данных? В РСУБД читаются поля и строки, а в FastObjects что? И как это все можно сравнить в плане производительности? Даже SQL сервера между собой сравниваются не по тому, как построен план запроса, а по скорости выполнения этих запросов, например по тестам TPC, но даже в этом случае далеко не все однозначно. А Вы предлагаете по планам запросов сравнивать производительность ОО серверов и SQL серверов. Смешно.
10 фев 05, 01:31    [1312134]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Вот вам один из примеров демагогии. Сравнивается случай 1:N в РМД и 1:1 в ОМД. Просто автор своим "while (iter.hasNext() )" прошел по таблице, о чем упомянул намного выше, но в данный момент уже забыл. Вот так и получается, что "В объектной системе, такой как FastObjects, искать связанные объекты серверу БД не приходится!". Создайте в РСУБД курсор по таблице с тем же критерием, что у Alexey Rovdo в фильтре, напишите "FETCH NEXT curs into ....;" внутри этого цикла и обращайтесь к полям ТЕКУЩЕЙ записи сколько душе угодно без всякого поиска.


Если бы вы внимательно читали мои рассуждения, то увидели бы, что я вовсе не рассматривал случай 1:1 в ОМД. Например, таблица Shedul содержит FOREIGN KEY fly. Это отношение 1:N между таблицами Fly и Shedul. В объектной модели ему соответствует включение ссылки на объект Flight в состав объекта Item. Т.е. любое количество объектов Item может содержать ссылку на один объект Flight. В РМД запрос любого параметра из таблицы Fly для заданного значения в таблице Shedul будет сопровождаться операцией JOIN и поиском той самой записи в таблице Fly, которая соответсвует заданной записи в таблице Shedul. В ОМД при обращении посредством навигации Item.Flight никакого поиска (включающего циклические операции) проводиться не будет, т.е. выборка искомого значения будет происходить быстрее. Вопрос может быть спорным, если JOIN-конструкций в запросе не много, но когда их 5-10-20 ... преимущества навигационного подхода выражаются несколькими порядками.
10 фев 05, 10:46    [1312722]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

На примере ничего выяснить нельзя, за исключением того случая, когда это контрпример. MS SQL ищет, а например постгреСКЛ может и не ищет. Но это к слову, идем дальше.


Итак, вы признаете, что в MS SQL запросы, содержащие JOIN-конструкции, приводят к неизбежным операциям поиска (содержащим некоторые циклические алгоритмы) !

Однако вы предполагаете, что такое поведение присуще именно MS SQL и не готовы делать обобщения на все реляционные системы. Ну что же, давайте выяснять, как поведет себя в таком случае PostgreSQL.
10 фев 05, 10:51    [1312743]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить