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

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

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

2 Path

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

2 Alexey Rovdo

Алексей, с вашими способностями по разработке ОО приложений мы разобрались. Вы не смогли внятно ответить ни один вопрос, предпочитая избегать их и разводить демагогию. Теперь вернемся к нашим овцам, к ООБД. Вы в предыдущем топике утверждали что ООБД лучше любых реляционных БД для определенного круга задач. Вы считаете что ваш продукт следует стандарту OMG? Если не следует то это просто тупиковое развитие, вроде Btrieve которое отжив свое упокоиться с миром. Если следует, то вопрос к вам - читали ли вы третий манифест ООБД? Позвольте вам напомнить что ООБД третьего поколения будут включать БД второго поколения. А какие это БД? Правильно реляционные БД. Ваша БД является ли реляционной по духу, ась? Теперь посмотрим, кто же такой беспредел написал - да отец всех ООБД - К.Дейт. Вам такой знаком? Ладно опустим этот печальный факт и посмотрим далее. Открываем книгу Дейта "Введение в системы БД" шестой редакции и смотрим стр. 680-695. Ах, какое богохульство он пишет, позвольте мне процитировать - "Низкая производительность- один из самых больших недостатков ОО систем". По сути ООБД являются шагом назад по сравнению с реляционными,потому что для их обработки используются языки 3-го поколения - процедурные, а нужны языки для обработки множеств. А в вашей волшебной системе вы достигли того, с чем борются лучшие умы планеты. Что и вызывает недоумение у меня. Все такие глюпие, как сурки, а Алексей со своей чудо программой разрешили все проблемы. Надо бы в OMG написать, что они все лохи, а ларчик просто отрывается. Или вы, Алексей, скажете, что C.Date для вас не авторитет? Почитайте тогда хотя бы наших авторов, например Кузнецова на может осознаете, что такое ООБД. Он то же самое пишет. И еще напоследок кинжал в спину. Раз мы уж сравниваем РБД и ООБД то как в вашей системе будет реализовываться следующий запрос. Вывести количество сотрудников по отделам с указанием сотрудника получающего наибольшую зарплату в данном отделе. Чую я, что вам целую программу писать надо. И как это весело - реализовывать руками операторы вроде Group BY... А по ваш спор по поводу ООБД напоминает мне спор [url=http://]https://www.sql.ru/forum/actualthread.aspx?tid=37044&pg=-1 Вы прямо вроде ALEX25 с удовольствием размазываете маркетинговые сопли по форуму.

И еще небольшой оффтоп, да простят меня глубокоуважаемые модераторы. Злые, злые вы люди, кроме Алексея. Затоптали всю чистую и пушистую мечту, по поводу программирования под ООБД. Вот еще и одну мечту вываляли в грязи. Я ведь хотел изучать GEMSTONE после Oracle. Придется на Ораклах сидеть всю жизнь. А ведь так хотелось почувствовать себя богом - по клику мыши писать целые программы.
11 фев 05, 05:46    [1315044]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Guest_New
Guest
Злой Хорек
Я не утверждал что ООБД исключают многозвенную архитектуру, но связывание базы данных и сервера приложений значительно увеличивает узкое место в системе.

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

>>Вы считаете что ваш продукт следует стандарту OMG?
Вы имеете ввиду ODMG?
11 фев 05, 11:36    [1315337]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
Злой Хорёк
Раз мы уж сравниваем РБД и ООБД то как в вашей системе будет реализовываться следующий запрос. Вывести количество сотрудников по отделам с указанием сотрудника получающего наибольшую зарплату в данном отделе. Чую я, что вам целую программу писать надо. И как это весело - реализовывать руками операторы вроде Group BY...

Немогу не вмешаться. Кто Вам сказал что в ODMG нет агрегатных функций? Это не так!!! Вы ссылаетесь на уважаемого мной Кузнецова, вот его статья, в которой в главе 2.2 приведен пример запроса на OQL с операцией группировки, во многом похожий на Ваш пример. И хотя с точки зрения технологии построения приложений под ОБД использование таких запросов не совсем корректно, но эти запросы не противоречат языку OQL. С моей точки зрения этот пример гораздо правильней реализовать на ОО языке програмирования, но думаю что OQL запрос будет для Вас более понятен.
11 фев 05, 12:13    [1315395]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

Если таблицы(коллекции, массивы и т.п), каждый раз для подсчёта сумм, среднего и т.п. по определённым группам придётся мне таскать с сервера на клиент сотни тысяч объектов (кортежей и т.п. как угодно) такую систему удастся внедрить только для учёта метёлок в шкафу у уборщицы, в любой другой отрасли (неважно какой) производительность важна не меньше чем гибкость и скорость разработки. Кроме того при таком таскании, очень очень быстро возникнет проблема с паралельностью и согласованностью,насколько актуальны и согласованны кешированные данные не знает никто (наверное, кроме коллеги ЧАЛ-а из ветки про "Сравнение объектно- ориентированных ...", но его языка - "!@#$@#@^^Перечеркнули&^$%@#@^Надписали->>::Готово" никто не понимает :)) ),ну это конечно шутка, а на самом деле будет или мало пользователей и быстро (на самом деле 1 пользователь :) ) или много, но "...все замерли Чапай будет делать отчёт..." (с) не помню чей.


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

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

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

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

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

Andreww

Можно конечно нафантазировать себе встраиваемых устройств - но там не нужны возможности и мощности полноценной СУБД, а вполне можно обойтись готовымим библиотеками (коих тысячи) или самописными решениями .


Интересно, если ЛИЧНО ВАМ прийдется выбирать, к примеру, кардиостимулятор. Какой вы предпочтете - дешевый, управляемый самописными библиотеками, или дорогой, содержащий встроенную промышленную СУБД, проверенную и обкатанную за долгие годы существования разрабатывающей ее компании?

Andreww

Можно сказать, что у меня не будет сетевого траффика, а будет крутой сервер приложений JBoss (вообщем не важно какой, но JBoss звучит солидно :)) ), тогда сразу вопрос - зачем мне лишняя сущность (ентот самый JBoss) под него ещё надо писать, и при этом можно ошибок наделать, кроме того всё равно таскать между процессами десятки мегабайт это не быстро, даже если согласиться что AS есть, почему бы не прикрутить его к имеющейся СУБД и не реализовать o/r-mapping самостоятельно, не отстёгивая килобаксы FastObject-у и язык запросов будет помощнее и с согласованностью\целостностью всё ок ?


Если вы готовы самостоятельно реализовывать полноценный o/r-mapping с возможностями, сопоставимыми с возможностями FastObjects или Versant Open Access, за суммы, меньшие килобакса, то разумеется эти продукты вам не нужны. Но как в этом случае вы собираетесь поступить с самими средами разработки? MS VS Prof тоже тянет более чем на штуку, а JBuilder Ent - и более чем на две. Тоже самописные предпочтете?
11 фев 05, 14:23    [1315701]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
[quot ЛП]
В ООСУБД, насколько я понял, для эффективного search по непонятным критериям - надо извращаться.
[\quot]

Можно извращаться, но те кому неохота используют готовый инструментарий и библиотеки. Об этих библиотеках вам может рассказать Злой Хорек.
11 фев 05, 14:32    [1315750]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Злой Хорёк


... то вопрос к вам - читали ли вы третий манифест ООБД? Позвольте вам напомнить что ООБД третьего поколения будут включать БД второго поколения. А какие это БД? Правильно реляционные БД. Ваша БД является ли реляционной по духу, ась? Теперь посмотрим, кто же такой беспредел написал - да отец всех ООБД - К.Дейт. Вам такой знаком? Ладно опустим этот печальный факт и посмотрим далее. Открываем книгу Дейта "Введение в системы БД" шестой редакции и смотрим стр. 680-695. Ах, какое богохульство он пишет, позвольте мне процитировать - "Низкая производительность- один из самых больших недостатков ОО систем". По сути ООБД являются шагом назад по сравнению с реляционными,потому что для их обработки используются языки 3-го поколения - процедурные, а нужны языки для обработки множеств. ... Или вы, Алексей, скажете, что C.Date для вас не авторитет?


А что Дейт пишет об SQL? И относит ли Дейт MS SQL и Oracle в их нынешнем виде к реляционным системам ? А в каком году он это писал ? А кто основной автор и вдохновитель третьего манифеста? Разработчиком (отцом-основателем) каких систем он является ?
11 фев 05, 14:39    [1315789]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Виталий Гаврилов
Немогу не вмешаться. Кто Вам сказал что в ODMG нет агрегатных функций? Это не так!!! Вы ссылаетесь на уважаемого мной Кузнецова, вот его статья, в которой в главе 2.2 приведен пример запроса на OQL с операцией группировки, во многом похожий на Ваш пример. И хотя с точки зрения технологии построения приложений под ОБД использование таких запросов не совсем корректно, но эти запросы не противоречат языку OQL. С моей точки зрения этот пример гораздо правильней реализовать на ОО языке програмирования, но думаю что OQL запрос будет для Вас более понятен.


А они форум не читают. Увидели, что FO агрегацию не поддерживает - вот и обобщают на все. Специально привожу выдержку:

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

PS: Кузнецова тоже читать на станут (наверное).
11 фев 05, 14:45    [1315827]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

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


Приписал вам чужие слова. Посему каюсь и приношу извинения.

c127

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


Достал - не спорьте. Считаете неподходящими мои эксперименты - предложите свои.

c127

ПостгреСКЛ я привел как пример, тратить время на него не собираюсь. Вы постоянно делаете общие выводы на основании очень частных наблюдений. Это логическая ошибка.

Единственное что можно было бы при таком подходе доказать, это то, что какое-то общее утверждение неверно. Свежий пример: "Alexey Rovdo> Операция поиска в РСУБД, в отличие от разадресации в ООСУБД, не реалицуется линейными алгоритмами...." Это утверждение ошибочно, поскольку можно привести пример оракла (это называется контрпример), где при поиске можно использовать линейные алгоритмы. Этим контрпримером полностью доказывается, что Ваше утверждение неверно.

А ДОКАЗАТЬ на частных примерах общие утверждения, как это пытаетесь делать Вы, можно только перебрав все без исключения варианты, а их ОЧЕНЬ много.


Ну что же, общностью можно пожертвовать. Давайте анализировать MS SQL, Oracle и DB2. Про остальные системы мы таким образом останемся в сомнении, а полученные выводы распространятся только на эти три.
Хотел бы увидеть ваш контрпример.

c127

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


В приведенном мною примере плана запроса MS SQL будет использовать поиск по бинарному дереву (B-Tree index). Дихотомический алгоритм поиска имеет сложность порядка T(log[2](N)), где N - число элементов массива. Разумеется cost-based оптимизатор может предложить и другой план запроса. Поэтому, разобравшись сначала с этим планом, я готов рассмотреть и другие возможные варианты выполнения данного запроса.

Полезные ссылки: О JOIN в MS SQL, Методы поиска, Бинарное дерево (наглядное пособие).

С уважением, Алексей Ровдо
11 фев 05, 15:19    [1315989]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Так я не понял про Sum() по атрибуту объектов экстента... Мож в стандарте ODMG и есть Sum (так много чего есть), но в данном конкретном продукте это всё же будет а) полностью на сервере сделано, или б) можно вытащить набор атрибутов и потом на клиенте суммировать или таки в) придеться все объекты целиком тащщить?

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

А то ведь что получаецца?.... ну даже ежели Вы так стремитесь продвинуть некий продукт, что ж Вы позволяете, себе высказывания типа "PS: Кузнецова тоже читать на станут (наверное)." Вы что - один такой начитанный? Например, я Вам заявлю, что СД весьма скептически относиться к перспекивам этого вашего.....ммммм..... Versant'а в том числе и на наших просторах ...мммм... во всяком случае у меня такое мнение сложилось (не скажу почему :) вам это приятно читать будет? Ну так и давайте грить по существу (о Вашем продукте и о его возможностях, в том числе в сравнении с близкими и далекими аналогами), а не разбрасываться не относящимися к этому суждениями об окружающих..... вобщем.... вот в таком аксепте.....
11 фев 05, 15:43    [1316090]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал....
Guest
Очепяточка...:)... Вместо "...я Вам заявлю..." следует читаь "если я Вам заявлю"
11 фев 05, 15:49    [1316133]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
Мдааа. Всё гораздо хуже чем я думал.

>>А вы когда-нибудь видели систему, в которой тысячи клиентов запрашивают аналитику по сотням тысяч объектов ?

Где я писал про тысячи клиентов ?
Представьте себе простенький склад ассортимента эдак тысячи на 2, в день 50-100 расходных документов, в каждом из которой по 10 позиций. Приход раз в месяц (примерно). И регулярно каждому кладовщику нужен отчёт по оперативным остаткам товара, дабы он мог выписать накладную. Представили ? Вот они и 100 000 объектов либо промежуточные суммы и алгоритмы по их вычислению-сохранению со всеми вытекающими проблемами. А если точек несколько по городу - вот вам 20 пользователей (только одних кладовщиков).
Я такие системы видел :)

>>Такие разумеется возможны, но тогда одновременно работающих клиентов будет 3-5 штук и не больше.

Не так надо. Надо говорить - я никогда не видел систем в которых одновременно работет много пользователей.

>>А иначе - сервер загнется считать для каждого свои агрегирующие функции по большому количеству объектов.

Представьте себе, считает! Просуммировать 100000 раз для современного процессора (даже для старенького) не составит труда.


>>Я вот на досуге лишний раз взглянул на разнообразные системы, с которыми мне приходится иметь дело. Так вот, если вычесть примитивный учет и бухгалтерию (я об этом просил многократно, но постоянно вынужден говорить снова - бухгалтерия на ООСУБД не ложится), то оказывается, что в пользовательских формах и приложениях НЕТ ДАННЫХ, АГРЕГИРУЕМЫХ из большого количества объектов.

Бухгалтерия - не ложится.
Склад - не ложится, причины выше.
Банк не ложится (там не 5 мест надо, это точно)
Производство (учёт) не ложится - по тем же причинам что и склад.
Производство (датчики) не ложится - там много пользователей одновременно и отчёты нужны в основном по сумме\среднему.
Наука - не ложится, там и объемы огромны и формулы посложнее суммы, которыми хочется нагрузить быстрый сервер.

Короче ничего не ложится, но продавать FO надо :))


>>А если и есть, то на практике приходится не вычислять эти данные динамически в запросе, а хранить их непосредственно в отдельных полях.

Получили на клиента, заблокировав "отдельное поле", посчитали, вернули на сервер. Здравствуй Fox Pro ! Только называешься ты теперь FO и стоишь на порядок больше !

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

Разработчики разные бывают. Некоторые вон до сих пор не знают к каким проблемам может привести кеширование данных на клиенте

>>Про кэширование вам выложили фрагмент руководства.

Ничего ПРИНЦИПИАЛЬНО НОВОГО в этих методиках нету, должен вас огорчить

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

Это как ? Это вы о чём ? Вы сейчас аутотренингом занялись или действительно считаете, что есть способ обеспечить 100 % согласованость данных в кэше , при их возможном изменении, без блокировки на сервере? Где про этот эффективный метод прочитать ? Что значит "достаточно эффективно" ?


>>Интересно, если ЛИЧНО ВАМ прийдется выбирать, к примеру, кардиостимулятор. Какой вы предпочтете - дешевый, управляемый самописными библиотеками, или дорогой, содержащий встроенную промышленную СУБД, проверенную и обкатанную за долгие годы существования разрабатывающей ее компании?

Выберу НАИБОЛЕЕ ПРОСТОЙ, предварительно посоветовавшись с хорошим специалистом. Очень-очень постараюсь, что бы внутри не было всякого .NET и прочего. Чем проще тем труднее сломать.


>>Если вы готовы самостоятельно реализовывать полноценный o/r-mapping с >>возможностями, сопоставимыми с возможностями FastObjects или Versant Open >>Access, за суммы, меньшие килобакса, то разумеется эти продукты вам не >>нужны.

"Полноценный" это какой ? Вот моё приложение на Java сохраняет объекты и загружает их из базы (Оракел), ничего особенного, всё по спецификации.
Никаких особых проблем, ничего особенного писать не пришлось. За 900 у.е. могу рассказать как (вернее ссылку дать где спецификации по Яве читать), и не нужен будет FO - выгодная сделка, торопитесь !!! :)



>>Но как в этом случае вы собираетесь поступить с самими средами разработки? MS VS Prof тоже тянет более чем на штуку, а JBuilder Ent - и более чем на две. Тоже самописные предпочтете?

Никакая самодеятельность в вопросах выбора средств недопустима, ИМХО.

Никаких поделок и новых супер-пуперских объектных ориентиров !!!

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

FO, кстати, из таких ?

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

И за них тоже надо доплатить ??? :[..........]

>>MS SQL будет использовать поиск по бинарному дереву (B-Tree index)

Уважаемый. Как бы это помягче сказать.
С каких это пор BTree == Binary Tree.
Не горячитесь.
11 фев 05, 16:04    [1316217]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Так я не понял про Sum() по атрибуту объектов экстента... Мож в стандарте ODMG и есть Sum (так много чего есть), но в данном конкретном продукте это всё же будет а) полностью на сервере сделано, или б) можно вытащить набор атрибутов и потом на клиенте суммировать или таки в) придеться все объекты целиком тащщить?


В данном конкретном продукте (FastObjects) чтобы сделать Sum() объекты (или только соответствующий их атрибут) прийдется тащить на клиента. Т.е. возможны варианты б) и в).

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

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


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

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

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


Лично я стремлюсь именно к разговору по существу.
Рад, что вы со мной в этом вопросе.
11 фев 05, 16:04    [1316219]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Andreww
Мдааа. Всё гораздо хуже чем я думал.

>>А вы когда-нибудь видели систему, в которой тысячи клиентов запрашивают аналитику по сотням тысяч объектов ?

Где я писал про тысячи клиентов ?
Представьте себе простенький склад ассортимента эдак тысячи на 2, в день 50-100 расходных документов, в каждом из которой по 10 позиций. Приход раз в месяц (примерно). И регулярно каждому кладовщику нужен отчёт по оперативным остаткам товара, дабы он мог выписать накладную. Представили ? Вот они и 100 000 объектов либо промежуточные суммы и алгоритмы по их вычислению-сохранению со всеми вытекающими проблемами. А если точек несколько по городу - вот вам 20 пользователей (только одних кладовщиков).
Я такие системы видел :)


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

Andreww

>>Такие разумеется возможны, но тогда одновременно работающих клиентов будет 3-5 штук и не больше.

Не так надо. Надо говорить - я никогда не видел систем в которых одновременно работет много пользователей.

>>А иначе - сервер загнется считать для каждого свои агрегирующие функции по большому количеству объектов.

Представьте себе, считает! Просуммировать 100000 раз для современного процессора (даже для старенького) не составит труда.


100000 раз для тысячи одновременно работающих пользователей, т.е. 100 млн. раз. При этом памяти для всех данных не хватит и нужно будет все время лазить на диск. Да ко всему речь не идет во всех случаях только о суммировании. А еще и данные надо возвращать (пользователи то не только суммы запрашивают). Сервер загнется. При чем, если запросы сложные, то и 5-10 пользовательских рабочих мест вполне может хватить, чтобы полностью загрузить сервер.

Andreww

>>Я вот на досуге лишний раз взглянул на разнообразные системы, с которыми мне приходится иметь дело. Так вот, если вычесть примитивный учет и бухгалтерию (я об этом просил многократно, но постоянно вынужден говорить снова - бухгалтерия на ООСУБД не ложится), то оказывается, что в пользовательских формах и приложениях НЕТ ДАННЫХ, АГРЕГИРУЕМЫХ из большого количества объектов.

Бухгалтерия - не ложится.
Склад - не ложится, причины выше.



Andreww

Банк не ложится (там не 5 мест надо, это точно)


Про пять мест вы что-то не так поняли и все с ног на голову перевернули. FastObjects может работать с большим числом пользователей одновременно.
Если их количество превышает 100, то Versant рекомендует переходить на использование более мощного продукта - Versant Developer Suite.

Andreww

Производство (учёт) не ложится - по тем же причинам что и склад.


Учет не ложится, а отслеживание цепочек поставок (Supply Chain Management) ложится и очень хорошо.

Andreww

Производство (датчики) не ложится - там много пользователей одновременно и отчёты нужны в основном по сумме\среднему.


Bosch Security Systems встроила ООСУБД FastObjects t7 в систему управления и мониторинга сетей безопасности RUBIN NT. RUBIN NT — это приложение для контроля состояния, визуализации структуры и событий и управления системами безопасности, с помощью которого один человек способен контролировать все системы, имеющиеся в здании (подробнее).


Andreww

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


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

Andreww

Получили на клиента, заблокировав "отдельное поле", посчитали, вернули на сервер. Здравствуй Fox Pro ! Только называешься ты теперь FO и стоишь на порядок больше !


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

Ко всему прочему, если уж вам так хочется считать на сервере. В FastObjects в конце-концов можно ведь и это устроить: напишите сервис и запустите его на сервере - пусть считает.

Andreww


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

Разработчики разные бывают. Некоторые вон до сих пор не знают к каким проблемам может привести кеширование данных на клиенте

>>Про кэширование вам выложили фрагмент руководства.

Ничего ПРИНЦИПИАЛЬНО НОВОГО в этих методиках нету, должен вас огорчить

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

Это как ? Это вы о чём ? Вы сейчас аутотренингом занялись или действительно считаете, что есть способ обеспечить 100 % согласованость данных в кэше , при их возможном изменении, без блокировки на сервере? Где про этот эффективный метод прочитать ? Что значит "достаточно эффективно" ?


Вот только почему вы решили, что "без блокировки на сервере"? Разумеется, с блокировкой. А для поддержания идентичности множества промежуточных кэшей (первый кэш на сервере БД, второй на сервере приложений и третий на клиенте) на множестве серверов приложений в FastObjects можно даже саму службу отслеживания блокировок вынести на отдельный сервер.

Andreww


>>Интересно, если ЛИЧНО ВАМ прийдется выбирать, к примеру, кардиостимулятор. Какой вы предпочтете - дешевый, управляемый самописными библиотеками, или дорогой, содержащий встроенную промышленную СУБД, проверенную и обкатанную за долгие годы существования разрабатывающей ее компании?

Выберу НАИБОЛЕЕ ПРОСТОЙ, предварительно посоветовавшись с хорошим специалистом. Очень-очень постараюсь, что бы внутри не было всякого .NET и прочего. Чем проще тем труднее сломать.


А я бы все же выбрал проверенный. Но это уже дело вкуса. А о вкусах, как известно, не спорят.

Andreww

>>Если вы готовы самостоятельно реализовывать полноценный o/r-mapping с >>возможностями, сопоставимыми с возможностями FastObjects или Versant Open >>Access, за суммы, меньшие килобакса, то разумеется эти продукты вам не >>нужны.

"Полноценный" это какой ? Вот моё приложение на Java сохраняет объекты и загружает их из базы (Оракел), ничего особенного, всё по спецификации.
Никаких особых проблем, ничего особенного писать не пришлось.


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

А по какой спецификации ?

Andreww

Никакая самодеятельность в вопросах выбора средств недопустима, ИМХО.

Никаких поделок и новых супер-пуперских объектных ориентиров !!!

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

FO, кстати, из таких ?


FO как инструмент разработки интегрируется c MS .NET, JBuilder, Forte, Eclips (включая IBM WSAD и др.), Sun One Studio и поддерживает множество компиляторов для разных платформ.

Andreww

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

И за них тоже надо доплатить ??? :[..........]


За сложные и многофункциональные - наверняка (и что ?).

Andreww

>>MS SQL будет использовать поиск по бинарному дереву (B-Tree index)

Уважаемый. Как бы это помягче сказать.
С каких это пор BTree == Binary Tree.
Не горячитесь.


Почитаю, разберусь, а пока no comments.
11 фев 05, 16:59    [1316507]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
SergSuper
Member

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


Т.е. если я правильно понял - если надо проверку наличия при выписке накладной, то ООСУБД будут эффективней?
Что б эту проверку осуществить нам надо прочитать объект "товар". Причем обязательно с сервера - с момента последнего кэширования он мог уже кончиться. Далее его надо заблокировать, записать накладную и обновить объект "товар". Если кто-то другой попытается тоже этот же товар отпустить - ему будет отказ и он должен периодически пытаться еще. А если допустим товар может быть еще поделён на разные партии...
Вы искренне считаете что так эффективне чем если б всё делалось внутри сервера?

Alexey Rovdo
100000 раз для тысячи одновременно работающих пользователей, т.е. 100 млн. раз. При этом памяти для всех данных не хватит и нужно будет все время лазить на диск. Да ко всему речь не идет во всех случаях только о суммировании. А еще и данные надо возвращать (пользователи то не только суммы запрашивают). Сервер загнется. При чем, если запросы сложные, то и 5-10 пользовательских рабочих мест вполне может хватить, чтобы полностью загрузить сервер.


У меня к примеру 1 млн записей складывается секунду, если б сервер был помощнее то и 100 млн складывалось бы за приемлемое время. Но согласитесь что пример надуманных - один пользователь делает за раз 100000 запросов... Как то странно
Но я так понял что Вы хотите сказать что ООСУБД эффективней. Но для них надо прежде чем данные сложить перегнать на клиента. А это (за исключением очень специфических задач) гораздо накладнее математических операций. Т.о. ООСУБД загнётся на порядки раньше.
Ах да, кэширование. Но только как узнать какие данные у клиента - актуальные или уже устаревшие? Т.е. прежде чем складывать данные объектов надо проверить их актуальность, для чего опять же надо запросить данные об их актуальности с сервера.

Alexey Rovdo
А в реляционных ситемах как ? Либо считаем динамически и загружаем сервер, либо же вводим отдельное поле и получаем ровно ту же проблему (разумеется, в разных системах есть разные способы ее преодоления).

Там как минимум таких пересылок данных нет

Alexey Rovdo
Ко всему прочему, если уж вам так хочется считать на сервере. В FastObjects в конце-концов можно ведь и это устроить: напишите сервис и запустите его на сервере - пусть считает.

За это отдельное спасибо.



Alexey Rovdo
За сложные и многофункциональные - наверняка (и что ?).

Дык как что... В обычные то СУБД это входит само собой. Типа бесплатно...

Alexey Rovdo
А я бы все же выбрал проверенный. Но это уже дело вкуса. А о вкусах, как известно, не спорят.

Ну вот и давайте сравним сколько установок у FastObjects и сколько у Оракла к примеру (я кстати и сам не знаю).


Но это всё эмоции, еще у меня есть 2 конкретных вопроса.

1. Я бы всё-таки хотел получить ответ на задававшийся уже мной вопрос об утечках памяти

2. Почему всё-таки FastObjects называется СУБД? По сути дела это же просто набор библиотек для ддоступак данным. Где там "система" то? АДО или VCL могут с не меньшей степенью называться СУБД
11 фев 05, 20:07    [1316984]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
НАХ...
Guest
я всего лишь просто программер... сижу читаю все то что тут понаписано, и понимаю, что костность мышления админов пока не побороть. это люди, чья обязанность заключается всего лишь в работе с "чисто" данными. при созданни приложения, в лучшем случае, с ними всего лищь консультируются... а пишем все мы... до ООП им дорости просто не дано... пока... но момент уже близок, и как только наши выскоуважаемые господа менеджеры осознают, что купить продукт независящий от процесса работы с данными "на языке данных" дешевле, нежели работать с админами (и проще для души и тела).

Всем привет, не комментируйте это и не обращайте внимания - это "синий" крик души, больше я здесь не появлюсь.
11 фев 05, 20:35    [1317018]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
НАХ...
я всего лишь просто программер... сижу читаю все то что тут понаписано, и понимаю, что костность мышления админов пока не побороть. это люди, чья обязанность заключается всего лишь в работе с "чисто" данными. при созданни приложения, в лучшем случае, с ними всего лищь консультируются... а пишем все мы... до ООП им дорости просто не дано... пока... но момент уже близок, и как только наши выскоуважаемые господа менеджеры осознают, что купить продукт независящий от процесса работы с данными "на языке данных" дешевле, нежели работать с админами (и проще для души и тела).

Всем привет, не комментируйте это и не обращайте внимания - это "синий" крик души, больше я здесь не появлюсь.

Вы серьезно считаете, что с SQL впервую очередь работают админы и все РСУБД в обязательном порядке требуют администрирования ? :)
11 фев 05, 20:45    [1317028]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
В догонку уж не обижайтесь, но получается, что Вы всего лишь кодер и Вам еще нужно дорасти до проектировщика БД.
11 фев 05, 20:46    [1317030]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

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

К примитивному учету сводятся в конечном счете все промышленые системы. Сюда же входит и управление, осуществляемое на основе накопленных данных.

>Учет не ложится, а отслеживание цепочек поставок (Supply Chain Management) ложится и очень хорошо.

Цепочки отслеживать и РСУБД очень хорошо умеют.

>Далее, вам и некоторым другим почему-то кажется, что при реализации сложного анализа данных в ООСУБД (и в частности в FastObjects) нужно с нуля писать подпрограммы для простейших действий типа группировок и суммирования. И это тоже не так. Существуют разнообразные библиотеки (короче все уже написано).
.....
.....
Интересно, если ЛИЧНО ВАМ прийдется выбирать, к примеру, кардиостимулятор. Какой вы предпочтете - дешевый, управляемый самописными библиотеками, или дорогой, содержащий встроенную промышленную СУБД, проверенную и обкатанную за долгие годы существования разрабатывающей ее компании?






>Bosch Security Systems встроила ООСУБД FastObjects t7 в систему управления и мониторинга сетей безопасности RUBIN NT. RUBIN NT — это приложение для контроля состояния, визуализации структуры и событий и управления системами безопасности, с помощью которого один человек способен контролировать все системы, имеющиеся в здании (подробнее).

А мне известна аналогичная промышленная система на сайбейзе ASA, работает уже много лет.

>Ну что же, общностью можно пожертвовать. Давайте анализировать MS SQL, Oracle и DB2. Про остальные системы мы таким образом останемся в сомнении, а полученные выводы распространятся только на эти три.

Все-таки проще и правильнее читать документацию, а не тыкать наугад в разные свойства разных СКЛ серверов, в надежде что получится желаемый результат.

>Хотел бы увидеть ваш контрпример.

Так что там приводить, думал все и так знают: хеш индексы, константное время поиска. В фастобджектсе разадресация наверняка тоже происходит через хеш таблицы. Пирнципы то одинаковые.

>В приведенном мною примере плана запроса MS SQL будет использовать поиск по бинарному дереву (B-Tree index). Дихотомический алгоритм поиска имеет сложность порядка T(log[2](N)), где N - число элементов массива. Разумеется cost-based оптимизатор может предложить и другой план запроса. Поэтому, разобравшись сначала с этим планом, я готов рассмотреть и другие возможные варианты выполнения данного запроса.

В который раз повторяю: ваш план построен COST BASED (!!!!) оптимизатором для таблиц в 5 записей. Дальше что? Покажите мне приложение с 5 записями в самой длинной таблице.

А что использует фастобджектс Вы так и не ответили. Хорошее сравнениие при наличии одного сравниваемого.

>Полезные ссылки: О JOIN в MS SQL, Методы поиска, Бинарное дерево (наглядное пособие).

Вы пытаетесь доказать, что "Операция поиска в РСУБД (причем во ВСЕХ БЕЗ ИСКЛЮЧЕНИЯ РСУБД! (c127)), в отличие от разадресации в ООСУБД, не реализуется линейными алгоритмами." (Alexey Rovdo), а приводите пример МССКЛ. Это просто глупость. Хорошо, предположим в МССКЛ операции поиска O(log2(N)). Дальше что, переходим к файерберду? Дальше в списке терадата (1 шт), сайбейз (2 шт), постгреСКЛ (1 шт), ...... Мало не покажется.

>Считаете неподходящими мои эксперименты - предложите свои.

Уже предлагал много раз, но Вы же не согласны. В наших условияй в реально проверяемых примерах имеет смысл сравнивать только 2 вещи:

1) общий подход. Для этого даже не обязательно писать рабочий код, достаточно принципов. Но вместо использования существенно объектной модели Вы выбрали структуру аналогичную таблицам в РСУБД, никакого наследования или что таме еще бывает. Поэтому превосходсво ОМД увидеть невозможно. Максимум удалось увидеть что ООСУБД позволяют строить структуры подобные реляционным.

2) длину кода, которая в конечном счете - трудозатраты программиста. С этим все ясно. Вы опять же выбрали наихудший для себя вариант, построив аналог реляционной модели. Поэтому Вам прихошлось бороться с СКЛ-ем на его поле и по его правилам, а это заведомый проигрыш. Нужно было строить объектную модель, тогда может быть был бы шанс.

Сравнивать производительность в принципе можно только непосредственно прогоняя тесты, но это требует много сил и времени, потому нереально. Сравнение планов себя не оправдывает. Нам даже при попытках сравнения планов МССКЛ-я и оракла не удалось получить убедительного результата, а тут вообще разные технологии. Тем более что планов фастобджекса Вы предоставить не можете.

И еще. Перебор записей в циклах, которое Вы называете навигацией, мы уже проходили в системах типа парадокса (а еще раньше в дореляционных БД, но я с ними не работал). Там был engine и процедурный язык, позволяющий ходить по записям, а СКЛ ограничивался простым select-ом. От такой навигации отказались в пользу СКЛ-я и поверьте мне, много сэкономили. Так что когда я говорю, что на обработке реляционных данных с СКЛ-ем тягаться сложно, я представляю о чем идет речь.
12 фев 05, 00:24    [1317230]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
Посмотрел ссылку с сайта versant, рекомендованную Alexey Rovdo (http://www.versant.com/solutions/industrial/customers_story/bosch).

> Industry Solutions: Bosch Success Story

• Need for a truly embedded data management system

Monitoring all the alarms of a large complex generates a huge amount of data that must be managed. Storing and retrieving the thousands of monitoring points and hundreds of thousands of measurements required Bosch to include a database within their application. Because RUBIN NT provides 24 hour monitoring and is commonly deployed at facilities with no IT staff available, Bosch could not use a typical database that would require maintenance technicians to shut down the RUBIN server on a regular basis to run special tools for backing up the database and performance tuning. The database had to enable RUBIN to be self-maintaining. Bosch chose to store their data using FastObjects because the FastObjects administrative API allowed them to automate all database maintenance, such as backups, and build a system that lets Bosch’s customers focus on monitoring their security, not on maintaining the security system.

Эти не шутят. Сразу видно, серьезные люди работают в versant. В информ-иксе ввели учет товара на предприятии по штрихкоду, в Bosch сделали автоматический бекап - давят РСУБД по всем фронтам.


Еще одно интересное, а главное агрументированное утверждение:
Using FastObjects required 50% less code to add persistence because FastObjects directly accepted their complex tree of objects instead of forcing them to be mapped to the relational model of rows, columns and tables.

Получить вдвое более короткий код для FastObjects нам пока не удалось, даже наоборот, получилось гораздо длиннее, но кто ж из настоящих спецов на такие мелочи обращает внимание.

Надо понимать что эту оценки выдали те же люди, которые добили РСУБД автоматическим созданием БД и бекапом.

А вот и выяснилось откуда растут ноги у легенды о join-ах:
FastObjects provided faster and more consistent performance because there was no need to execute performance-robbing JOINs to reconstruct objects from multiple tables.
12 фев 05, 03:34    [1317276]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Злой Хорёк
Member

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

Конечно имел в виду ODMG - очепятался.
У меня сложилось впечатление, что VDS это уродливо скрещеная ООБД и сервер приложений в одном флаконе. Поэтому и говорю о проблемах с масштабироемостью. Как в данном случае добиться, чтобы иметь что-то подобное Oracle RAC?

2 Виталий Гаврилов

Да знаю я что в стандарте ODMG имеются аргегатные функции. Просто не только у меня одного сложилось впечатление, что в Fast Object не имеется простого способа агрегирования. А то Alexey расписывал, что все надо делать, только через объектную навигацию. А это геморой согласитесь - недетский.

2 Alexey

А к чему эти вопросы? Они как то нам помогут сравнить удобство разработки под РБД или ООБД? Зачем вы перескакиваете на темы совершенно не относищиеся к топику? Если вы хотите меня уличить в незнании этих вопросов, то не получиться. Если уж вам хочется получить ответ на них, то вынесете их в отдельный топик и я там отпишу. Как знание того что SQL не следует стандартом реляционной модели поможет сравнить Versant и РБД? Вы предлагаете тащить все на клиента неважно объекты или аттрибуты и потом суммировать? Это же фоксофильство какое-то получается. А если клиент дохлый? Что толку в вашем сервере? Примитивный бух учет??? Если он такой примитивный почему такие проблемы с его реализацией? И не надо заливать про то, что он типично реляционная задача, я вам раньше ответил по этому поводу, что не бывает каких-то ОО или реляционных задач. По поводу согласованности данных,-вы помните что говорят по этому поводу? О том, что обычная методика управления транзакциями не совсем адекватна для ОО систем. Особенно это касается длительных транзакций? Как это решается в VDS? Как решается декларативная поддержка целостности данных? Или вы предлагаете мне писать методы на каждый чих? Вам еще задали вопрос эта библиотека позволяющая использовать агреггирование она идет в стандартной поставке или нет; вы утверждаете что за нее надо доплачивать. Какой смысл в приобретении продукта, который по стоимости приближается к Ораклу, а вот по фукциональности напоминает кастрированый FoxPro? У вас получается что продукт то впарить лоху можно, а потом пусть он платит за агрегирование, за ... и за прочий функционал... Как вы собираетесь развивать свой продукт, если в 3-ем манифесте основой являются РБД? Объясните каким образом?

2 НАХ...

Я абсолютно согласен с вами. Иметь дело с админами, архитекторами - это очень плохо отражается на здоровье. Тогда уж давайте и компы выкинем, с ними так много мороки и будем все на счетах обрабатывать. Ваше заявление, это даже заява не кодера, а просто проявление ламерства...
13 фев 05, 21:24    [1318435]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Guest_New
Guest
Злой Хорек
У меня сложилось впечатление, что VDS это уродливо скрещеная ООБД и сервер приложений в одном флаконе.


Почему у Вас сложилось такое впечатление? Хотелось бы узнать Ваше мнение.
Мы сейчас смотрим в сторону VDS. Может мы не видим очевидных вещей?
Единственно, что хотелось бы уточнить. Я говорю о Versant Developer Suit (VDS), а не FastObjects.
14 фев 05, 11:23    [1319127]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Guest_New
Guest
Злой Хорек
У меня сложилось впечатление, что VDS это уродливо скрещеная ООБД и сервер приложений в одном флаконе.


Почему у Вас сложилось такое впечатление? Хотелось бы узнать Ваше мнение.
Мы сейчас смотрим в сторону VDS. Может мы не видим очевидных вещей?
Единственно, что хотелось бы уточнить. Я говорю о Versant Developer Suit (VDS), а не FastObjects.
14 фев 05, 11:28    [1319143]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Выше я обещал рассказать о средствах генерации отчетов для FastObjects.

Представляю Qint Software и ее ReportWeaver Platform.

О самом продукте и его возможностях вы можете подробно ознакомиться на сайте Qint. Я же выделю основное:

1) Поддерка различных ООСУБД включая: FastObjects/JDO, VDS/Java, VDS/C++.
2) Создание сложных отчетов в визуальном редакторе.
3) Runtime API для генерации отчетов в приложениях.
4) Импорт/экспорт отчетов в различные форматы.

Прилагаю пример отчета, "на раз" сделанного в Qint ReportWeaver для представленного выше решения в FastObjects.

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

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

И еще такой вопрос: при работе с ОО языками постоянно возникает проблема утечек памяти и обращений к несуществующим объектам. Есть конечно где-то автоматическая сборка мусора - но она не может работать когда приложение "размазано" по уровням - сервер не может знать какие объекты нужны клиенту. Т.е. перейдя на ООСУБД, я поимею еще и такую проблему?


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

К сообщению приложен файл (FO_ObjDel.pdf - 43Kb) cкачать
14 фев 05, 18:00    [1320358]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Почему всё-таки FastObjects называется СУБД? По сути дела это же просто набор библиотек для ддоступак данным. Где там "система" то? АДО или VCL могут с не меньшей степенью называться СУБД


Основные причины, по которым FastObjects относится именно к СУБД:

1) поддержка ACID-транзакций;
2) поддержка конкурентного доступа;
3) авторизация пользователей и отслеживание их прав на доступ и модификацию данных;
4) обеспечение целостности данных средствами ООСУБД;
4) запросы (OQL, JDOQL);
5) поддержка мультипроцессорности и кластеров;
6) поддержка репликации и резервирования;
7) ...

Архитектура

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

В FastObjects t7 структура базы данных и весь код для доступа к данным формируются непосредственно из объектной модели приложения. Это позволяет осуществить прямое отображение Java или C++ объектов и их связей в хранилище данных.

Сервер баз данных FastObjects t7 взаимодействует с клиентами через стек протоколов TCP/IP. Разработанный специально для использования в двух- и трехуровневых приложениях, сервер позволяет осуществлять гибкое управление транзакциями в конкурентной среде, реализуя оригинальный механизм блокировки на уровне объектов. Для обеспечения быстрого доступа и эффективной обработки данных все хранимые C++ и Java объекты располагаются в хранилище в локальной файловой системе сервера, а внутрисерверные механизмы кэширования данных обеспечивают высочайшую производительность.

FastObjects t7 разработан специально для непосредственного встраивания в приложения. Конечный пользователь программы может даже не знать об использовании и месте размещения базы данных FastObjects t7. Разработчикам приложений достаточно только подлинковать runtime-библиотеки FastObjects t7 для получения готового к использованию продукта, не требующего сложного процесса инсталляции. Имеющийся в FastObjects t7 административный интерфейс прикладного программирования (API) дает разработчикам возможность полностью автоматизировать все процедуры по обслуживанию базы данных, обычно выполняемые администратором (например, такие как онлайновый бэкап и пр.).

FastObjects t7 обеспечивает широко масштабируемый конкурентный доступ к хранимым на сервере данным. Для трехуровневых приложений FastObjets t7 предусматривает использование в качестве серверов приложений таких систем как WebLogic, JBoss и Tomcat. Для двухуровневых систем, FastObjects t7 реализует самостоятельный сервер баз данных, а клиентскую часть предлагает в виде встраиваемого решения. Вне зависимости от избранной архитектуры, стратегия блокировки, применяемая в FastObjects t7, гарантирует целостность и сохранность данных при одновременной работе множества пользователей и процессов.
14 фев 05, 18:09    [1320380]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить