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

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


Т.е. если я правильно понял - если надо проверку наличия при выписке накладной, то ООСУБД будут эффективней?


Я бы сказал не просто "проверку", а "твердую гарантию" (когда цена ошибки очень высока, например, это чревато остановкой большого конвейера).

SergSuper

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



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

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

Обычно складские программы строятся на базе РСУБД, поскольку, как я уже отмечал выше, логика работы кладовщиков не ложится в приведенную схему. Однако для компаний, склады которых содержат большое количество наименований товара с большим числом разнообразных (зачастую индивидуальных) характеристик, а сами товары отгружаются либо малыми партиями, либо поштучно, объектная СУБД в качестве платформы для учета товарных потоков будет весьма полезна. Подходящим примером может быть торговля антиквариатом, где каждая вещь индивидуальна и требует специфического описания.
14 фев 05, 18:44    [1320508]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
Что такое СУБД?

СУБД это

М. Р. Когаловский
14 фев 05, 18:47    [1320518]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896
BaZa
Что такое СУБД?
СУБД это
М. Р. Когаловский
Я даже больше скажу! (С)
Тынц!
14 фев 05, 18:55    [1320536]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Alexey Rovdo
SergSuper

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


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

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


А можно поподробней про 2, 3, 4(который после 3-го), 5 и 6-й пункты? Про это еще ни слова не было
14 фев 05, 19:14    [1320567]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

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

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

Мне честно говоря не особо хочеться искать по всему форуму высказывания Алексея на основании которых я сделал такой вывод, но я позволю себе процитировать Дейта:"РСУБД предстает перед пользователем в готовом к употреблению виде... ОО система, наоборот, представляет собой некую разновидность набора инструментов для работы с СУБД..." По моему мнению, самые простые вещи, озвучивавшиеся раннее, например аналитика, требует чтобы их делало некоторое звено, получив все необходимые объекты. Согласитесь, что такую благодать не повесишь на клиента. Следовательно требуется некоторая промежуточная вещь - что-то вроде сервера приложений. Если вы изучали EJB то это очень здорово смахивает на эту технологию, ИМХО. Честно говоря, всем маркетинговым лозунгам не особо доверяю. Зайдите например на сайт какой-нибудь D3 или MUMPSA - истерические лозунги о том что как можно работать без нашей системы. Может мы за 10 лет ООБД не осознали, закостенели в развитии, но посмотрите вокруг, где гиганты ООБД? Gemstone, Versant и прочие производители держаться на плаву благодаря старым контрактам. Новые клиенты, появляються, только если их кто-то хорошо окучит. Истерия ООБД закончилась и лопнула как мыльный пузырь. Посмотрите 3-ий манифест и что пишут его создатели об ООБД. Еще одна из таких важных вещей как наличие спецов по данному продукту. Похоже что кроме пары-тройки человек не найдешь. Не проще разрабатывать на чем-то более известном и доступном. Задайте производителям вопрос если вы такие умные, то почему такие бедные. Я бы стал смотреть в сторону РБД + использование сервера приложений. Но это чисто мое мнение, вам решать и в итоге работать с этим продуктом. И еще, если не жалко времени прочтите Дейта и его измышления, по поводу ООБД. Там страниц 20-30 по этому поводу, но они очень хорошо открывают глаза на эту технологию.
14 фев 05, 20:27    [1320680]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

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

Переходим к сравнению количества кликов мышой при построении отчетов. С сервером, надо понимать, все ясно.

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

В который раз пытаюсь и не могу понять логику: а зачем строить идентичную реляционную схему? Тем более что "исторически" сложилось совсем наоборот: сначала появилось реляционное решение SergSuper-а, а только через месяц - ОО решение Alexey Rovdo, т.е. возможности подогнать реляционное решение под ОО не было даже в принципе. Лучше Вы бы в своем решении показали отличия ОМД, это можно было бы понять.

С линейными алгоритмами поиска, приводящими к заведомому проигрышу РСУБД в скорости мы уже разобрались? Еще есть вопросы?
15 фев 05, 03:21    [1320932]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
с127
>Прилагаю пример отчета, "на раз" сделанного в Qint ReportWeaver для представленного выше решения в FastObjects.

Переходим к сравнению количества кликов мышой при построении отчетов. С сервером, надо понимать, все ясно.

Microsoft Access - 16 кликов мышкой и 14 нажатий на клавиатуру. Наверное можно и меньше, оптимизацией не занимался :)

Интересно, сколько у Алексея?
15 фев 05, 03:53    [1320937]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
блин, сам отчет не приложился

К сообщению приложен файл. Размер - 0Kb
15 фев 05, 03:53    [1320938]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
Alexey Rovdo
Обычно складские программы строятся на базе РСУБД, поскольку, как я уже отмечал выше, логика работы кладовщиков не ложится в приведенную схему. Однако для компаний, склады которых содержат большое количество наименований товара с большим числом разнообразных (зачастую индивидуальных) характеристик, а сами товары отгружаются либо малыми партиями, либо поштучно, объектная СУБД в качестве платформы для учета товарных потоков будет весьма полезна. Подходящим примером может быть торговля антиквариатом, где каждая вещь индивидуальна и требует специфического описания.

Ну-ка, ну-ка, расскажите ка поподробней - чем это ООСУБД может быть полезней для складского учета? Последние шесть (или семь) лет занимаюсь складским учетом для компаний, склады которых содержат "большое количество наименований товара с большим числом разнообразных (зачастую индивидуальных) характеристик", а сами товары отгружаются как охеренными фурами, так и малыми партиями либо поштучно, и тут вдруг выясняется, что РСУБД для таких задач и не подходит совсем... вах-вах-вах.
15 фев 05, 04:24    [1320944]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Злой Хорёк
Member

Откуда:
Сообщений: 24
А Oracle Reports вообще круче всех будут Позволяют делать такие вещи которые остальным средствам не снились Я не понял что мы тут сравниваем - средства разработки отчетов или БД??? Alexey, давайте выделим отдельный топик для вашей рекламы и вы там спокойно иезуитствовать будете Что у вас на очереди следующее MS Word против Multi Edit?
15 фев 05, 05:48    [1320960]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Мне честно говоря не особо хочеться искать по всему форуму высказывания Алексея на основании которых я сделал такой вывод, но я позволю себе процитировать Дейта:"РСУБД предстает перед пользователем в готовом к употреблению виде... ОО система, наоборот, представляет собой некую разновидность набора инструментов для работы с СУБД..." По моему мнению, самые простые вещи, озвучивавшиеся раннее, например аналитика, требует чтобы их делало некоторое звено, получив все необходимые объекты. Согласитесь, что такую благодать не повесишь на клиента. Следовательно требуется некоторая промежуточная вещь - что-то вроде сервера приложений. Если вы изучали EJB то это очень здорово смахивает на эту технологию, ИМХО. Честно говоря, всем маркетинговым лозунгам не особо доверяю. Зайдите например на сайт какой-нибудь D3 или MUMPSA - истерические лозунги о том что как можно работать без нашей системы. Может мы за 10 лет ООБД не осознали, закостенели в развитии, но посмотрите вокруг, где гиганты ООБД? Gemstone, Versant и прочие производители держаться на плаву благодаря старым контрактам. Новые клиенты, появляються, только если их кто-то хорошо окучит. Истерия ООБД закончилась и лопнула как мыльный пузырь. Посмотрите 3-ий манифест и что пишут его создатели об ООБД. Еще одна из таких важных вещей как наличие спецов по данному продукту. Похоже что кроме пары-тройки человек не найдешь. Не проще разрабатывать на чем-то более известном и доступном. Задайте производителям вопрос если вы такие умные, то почему такие бедные. Я бы стал смотреть в сторону РБД + использование сервера приложений. Но это чисто мое мнение, вам решать и в итоге работать с этим продуктом. И еще, если не жалко времени прочтите Дейта и его измышления, по поводу ООБД. Там страниц 20-30 по этому поводу, но они очень хорошо открывают глаза на эту технологию.


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

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

Почему я так считаю, и что может служить доказательством моей точки зрения? Взгляните на существующие сегодня технологии O/R-отображения (Versant Open Access Suite). Их возможности в полной мере демонстрируют один простой факт. ОО-приложение, написанное для ООСУБД, можно с легкостью прицепить и к любой распространенной РСУБД (причем зачастую вообще без изменения кода этого приложения). О чем это говорит? Это подтверждает позицию Дейта - объектные данные можно разместить в реляционной схеме. Но ведь верно и обратное - реляционные схемы прекрасно преобразуются в объектные. Т.е. вопрос сводится к методам организации и хранения данных в самом хранилище, а приложения для работы с этими данными могут иметь любую архитектуру. Но если приложение уже написано на ОО-языке на основании исходной ОО-модели предметной области, то зачастую может оказаться более эффективным и использование ОО-хранилища (ООСУБД). В противном случае мы вынуждены будем ввести дополнительный уровень O/R-отображения, который будет уменьшать общую эффективность системы (или писать само приложение, используя иные методики и подходы).

Вот выше вы говорите: "Я бы стал смотреть в сторону РБД + использование сервера приложений". Так ведь именно развитие технологий серверов приложений и подхлестывает переход на объектные технологии и, как следствие, объектно-ориентированные инструменты разработки и ООСУБД.

Посмотрим, к примеру, на EJB и такие сревера, как BEA WebLogic, JBoss, Tomcat (и любые другие, поддерживающие JCA). ОО-язык программирования Java стимулирует переход на ОО-методы проектирования и разработки. Для доступа к данным в этом случае очень удобным оказывается использование технологии JDO. Т.е. связка Java-EJB-JDO в серверах приложений становится совершенно естественной при реализации ОО-подхода к проектированию и разработке. И многие клиенты Versant сегодня приходят к ООСУБД именно через JDO (используя при разработке своих приложений средства O/R-отображения и инструментарий Versant Open Access JDO, который позволяет взаимодействовать с самыми разными РСУБД, а также с ООСУБД VDS). Где-то такой переход осмыслен, где-то - нет, но сама возможность легко (с разумными издержками) переключаться на любую СУБД из широкого набора многим пользователям JDO просто греет душу.

Обратимся теперь к платформе .NET. Выше, когда я упомянул Web-сервисы, некоторые меня не поняли. Но ведь и здесь ситуация аналогичная. Наиболее распространенный сегодня язык платформы .NET C# является ОО-языком программирования (есть также и managed C++). Сами Web-сервисы, использующие стандарты WSDL/SOAP/XML, очень удобно строить именно в объектной парадигме. И традиционная "несогласованность импедансов", характерная для взаимодействия ОО-приложений с РСУБД здесь проявляется в полной мере. Все это и подхлестывает итерес к продвинутым средствам O/R-отображения для платформы .NET (например, Versant Open Access .NET или близкий по назначению продукт от Developer Express). А вслед за этим возникает интерес и к ООСУБД. К слову сама идеология работы с отсоединенными данными, заложенная Microsoft в ADO .NET во многом провоцирует интерес именно к таким ООСУБД, как VDS или FO, из-за того, что они поддерживают специальные механизмы для реализации длительных транзакций. Такие механизмы позволяют заблокировать (по чтению и/или по записи) соответствующие объекты в базе данных, которые были отправлены удаленному пользователю для редактирования.
15 фев 05, 11:26    [1321596]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
Злой Хорёк
2 Guest_New

Мне честно говоря не особо хочеться искать по всему форуму высказывания Алексея на основании которых я сделал такой вывод, но я позволю себе процитировать Дейта:"РСУБД предстает перед пользователем в готовом к употреблению виде... ОО система, наоборот, представляет собой некую разновидность набора инструментов для работы с СУБД..." По моему мнению, самые простые вещи, озвучивавшиеся раннее, например аналитика, требует чтобы их делало некоторое звено, получив все необходимые объекты. Согласитесь, что такую благодать не повесишь на клиента. Следовательно требуется некоторая промежуточная вещь - что-то вроде сервера приложений. Если вы изучали EJB то это очень здорово смахивает на эту технологию, ИМХО. Честно говоря, всем маркетинговым лозунгам не особо доверяю. Зайдите например на сайт какой-нибудь D3 или MUMPSA - истерические лозунги о том что как можно работать без нашей системы. Может мы за 10 лет ООБД не осознали, закостенели в развитии, но посмотрите вокруг, где гиганты ООБД? Gemstone, Versant и прочие производители держаться на плаву благодаря старым контрактам. Новые клиенты, появляються, только если их кто-то хорошо окучит. Истерия ООБД закончилась и лопнула как мыльный пузырь. Посмотрите 3-ий манифест и что пишут его создатели об ООБД. Еще одна из таких важных вещей как наличие спецов по данному продукту. Похоже что кроме пары-тройки человек не найдешь. Не проще разрабатывать на чем-то более известном и доступном. Задайте производителям вопрос если вы такие умные, то почему такие бедные. Я бы стал смотреть в сторону РБД + использование сервера приложений. Но это чисто мое мнение, вам решать и в итоге работать с этим продуктом. И еще, если не жалко времени прочтите Дейта и его измышления, по поводу ООБД. Там страниц 20-30 по этому поводу, но они очень хорошо открывают глаза на эту технологию.


Как мне кажется, дело в том, что ООБД появились слишком рано. На мой взгляд в настоящее время наблюдается начало их нового подъема.

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

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

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

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


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

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

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

Я уже писал, что сегодня ООСУБД приходят к нам (в Россию) в основном в составе готовых продуктов и решений. Забавно иногда наблюдать удивление администраторов телекоммуникационных сетей, которые узнают, что внутри используемого ими ежедневно оборудования или софта сидит ООСУБД от Versant. Взглянем на тот же Sabre Availability Processor, построенный на базе Versant Developer Suite. Но это же типичный склад, где каждый товар уникален - каждое место на каждый авиа-рейс продается только один раз и только в одном экземпляре. А для получения развернутой статистики в той же Sabre строятся отдельные системы уже на базе реляционных СУБД. И именно в этом случае никакой особенно любопытный администратор, аналитик или маркетолог не подвесит систему супер-сложным запросом, и основное ее назначение - обеспечить бесперебойную выдачу свободных мест по запросам многих тысяч кассиров и агенств по продаже билетов - никак не пострадает (это кстати тот случай, когда цена ошибки - отмена или перенос рейса - может быть очень высока).
15 фев 05, 11:55    [1321718]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
Вот-вот, при использовании Versant VDS созданы современные продукты, которыми пользуется каждый из нас:

Все программное обеспечение вшитое в оборудование Nortel
Вся система (и ресурс) Factivia
Borland CaliberRM

Так что говорить о смерти ООСУБД пока еще рановато...
15 фев 05, 12:09    [1321792]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
2 Alexey Rovdo
Для компаний, склады которых содержат большое количество наименований товара с большим числом разнообразных (зачастую индивидуальных) характеристик, а сами товары отгружаются либо малыми партиями, либо поштучно, объектная СУБД в качестве платформы для учета товарных потоков будет весьма полезна.

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

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

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

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


оффтоп....
Взглянем на тот же Sabre Availability Processor, построенный на базе Versant Developer Suite. Но это же типичный склад

Надо же, а я и не знал... вот ведь блин какой типичный склад...
каждое место на каждый авиа-рейс продается только один раз и только в одном экземпляре.

ээээ... ыыыы....
а билет никак нельзя вернуть, а? дяденька, мне уже не надо никуда лететь...
15 фев 05, 12:58    [1321991]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
О, есть момент для высказывания:
автор
Обратимся теперь к платформе .NET. Выше, когда я упомянул Web-сервисы, некоторые меня не поняли. Но ведь и здесь ситуация аналогичная. Наиболее распространенный сегодня язык платформы .NET C# является ОО-языком программирования (есть также и managed C++).

При чем тут язык программирования???
автор
Сами Web-сервисы, использующие стандарты WSDL/SOAP/XML, очень удобно строить именно в объектной парадигме.

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

Где здесь?
автор
Все это и подхлестывает итерес к продвинутым средствам O/R-отображения для платформы .NET (например, Versant Open Access .NET или близкий по назначению продукт от Developer Express).

Перечислите чтоли письменно процес между дано и получено, а то никак не выходит.
автор
А вслед за этим возникает интерес и к ООСУБД.

Чего-то не возник до сих пор. Или это типа аргумент для перехода на ООБД? Или это просто вы так думаете?
автор
К слову сама идеология работы с отсоединенными данными, заложенная Microsoft в ADO .NET во многом провоцирует интерес именно к таким ООСУБД, как VDS или FO, из-за того, что они поддерживают специальные механизмы для реализации длительных транзакций.

А это тут причем? Причем тут транзакции и ООСУБД?
автор
Такие механизмы позволяют заблокировать (по чтению и/или по записи) соответствующие объекты в базе данных, которые были отправлены удаленному пользователю для редактирования.

Бред какой-то. Полный бред почти все, что было сказано про вебсервисы!!!
Санитааааааарыыыыыыыы!!! Скорее сюдааааа!!!

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

-- Tygra's --
15 фев 05, 13:14    [1322058]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Один1
Guest
Alexey Rovdo
Но сегодня взгляд на эти вещи изменился, а мы же (в России) наконец получив возможность почитать кнугу Дейта (вышла на русском в 2004г.), как нам кажется прозрели и готовы с ним согласиться. Весь этот наш топик по своему содержанию повторяет споры 10-ти (а то более) летней давности уже отбушевавшие и затихшие на западе. Сегодня нет жесткого противостояния между РСУБД и ООСУБД. Есть споры о том, насколько рациональны те или иные системы в конкретных прикладных областях и в конкретных условиях эксплуатации, а также разнообразные маркетинговые ходы компаний, с помощью которых они пытаются проникнуть (удержать) определенные сегменты
:) Ну да, пока мы тут щи лаптем хлебали, прекрасный запад ушел далеко вперед. Это сильный аргумент, бесспорно.

Alexey Rovdo, вы всерьез полагаете, что
а) все присутствующие на форуме и в частности в данном топике живут в России ?
б) и поэтому книгу Дейта прочли в 2004 году ?

PS: не имею ничего против многочисленных объектных надстроек, в т.ч. и рекламируемой здесь, но похоже дискуссия опять ушла в просторы высокой теории, т.е. в никуда.
15 фев 05, 13:19    [1322071]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
AI
Member

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

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

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

Я уже писал, что сегодня ООСУБД приходят к нам (в Россию) в основном в составе готовых продуктов и решений. Забавно иногда наблюдать удивление администраторов телекоммуникационных сетей, которые узнают, что внутри используемого ими ежедневно оборудования или софта сидит ООСУБД от Versant. Взглянем на тот же Sabre Availability Processor, построенный на базе Versant Developer Suite. Но это же типичный склад, где каждый товар уникален - каждое место на каждый авиа-рейс продается только один раз и только в одном экземпляре. А для получения развернутой статистики в той же Sabre строятся отдельные системы уже на базе реляционных СУБД. И именно в этом случае никакой особенно любопытный администратор, аналитик или маркетолог не подвесит систему супер-сложным запросом, и основное ее назначение - обеспечить бесперебойную выдачу свободных мест по запросам многих тысяч кассиров и агенств по продаже билетов - никак не пострадает (это кстати тот случай, когда цена ошибки - отмена или перенос рейса - может быть очень высока).


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

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

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

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

Разумеется, в таких условиях "ООСУБД" будут иметь громадное преимущество в производительности на элементарных коротких транзакциях, но не обеспечат разумной производительности или не дадут корректных данных на долгих запросах (всем выйти, мы будем делать отчет за день, а потом бэкап). И "гигантские базы", действительно, будут иметь место и "обрабатываться".
15 фев 05, 13:21    [1322078]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

...
Говорят, Декарт беспощадно бил своих собак с наслаждением повторяя при этом: "Они автоматы, и не чувствуют боли, но они сделаны так премудро, что поведение их вполне совпадает с поведением чувствующих существ". Статуя Лаокоона не страдает. Без чувства мир был бы статуей Лаокоона. Лицо его выражало бы боль, прекрасное гибло бы в петлях уродливого, но самой муки не было бы, и в математических уравнениях ничего не изменилось бы. Между тем к кинематографу бытия приложена страшная музыка чувства, аккомпанирующая каждому его явлению. Так как в мире чувств страдание, по признанию огромного большинства, значительно преобладает, а в пропорции этой мы ничего не в состоянии изменить, ибо мы не можем двигать, а нами движет хаос - "Du glaubst zu schieben und du wirst geschoben" (Гете), - то остается только "почтительнейше вернуть билет" (Достоевский). Кому только? Режиссера не найдешь. Вернуть его в пустоту и самому низринуться в хаос? Как же случилось, что такое страшное миросозерцание созрело вместе с победами человека над природой.
...

А. ЛУНАЧАРСКИЙ
САМОУБИЙСТВО И ФИЛОСОФИЯ
15 фев 05, 14:11    [1322288]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
них.. не понял
простите мне мой французкий
15 фев 05, 14:16    [1322309]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

:) Ну да, пока мы тут щи лаптем хлебали, прекрасный запад ушел далеко вперед. Это сильный аргумент, бесспорно.

Alexey Rovdo, вы всерьез полагаете, что
а) все присутствующие на форуме и в частности в данном топике живут в России ?
б) и поэтому книгу Дейта прочли в 2004 году ?


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

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Я тоже нихрена не понял...
Может, потому что башка болит, аж раскалывается....

Хотя, в остальных топиках вроде все понимаю...... :)
Значит в чем-то другом дело.

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

Откуда: Новосибирск
Сообщений: 2402
Блог
Alexey Rovdo
Многие - несомненно.
Но все-таки я не хотел бы обобщать. Это был мой ответ Злому Хорьку, который уж очень страстно апелировал именно к Дейту.
А вы вот сюда посмотрите (http://www.dbdebunk.com/), а потом уж говорите о том, что "споры давно стихли" и "Сегодня нет жесткого противостояния между РСУБД и ООСУБД.".
15 фев 05, 15:31    [1322680]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

А вы вот сюда посмотрите (http://www.dbdebunk.com/), а потом уж говорите о том, что "споры давно стихли" и "Сегодня нет жесткого противостояния между РСУБД и ООСУБД.".


Шикарная ссылка! Спасибо вам за нее.
И вот что я сразу же нашел на этом сайте.

(источник)

From: Jesper Larsson, Apptus Technologies
To: Editor
Date: 17 Oct 2004

...

I find no conflict whatsoever between the relational model and the object paradigm. They belong to separate domains and it is hard to see how there could be a conflict. The concept of "object databases" is strange however. There are no "object word processors" for instance, so why should there be object databases? The user of the system has no reason to know about such implementation details, unless he or she is a programmer rooting around deeper below the surface than any secure system could allow. This is not to say that object techniques are not suitable when it comes to implementing database systems. On the contrary, they are just as powerful tools in this as in other programming tasks.

In some of your writings you touch on topics that are quite controversial among people who endorse object oriented techniques, such as for instance what inheritance should really mean (extension or specialization) and how it should be used. These topics are indeed relevant and should be discussed in their own right, and the programming field could certainly use someone clearing out the concepts like you are doing for databases. However, in my opinion the object wars are hardly relevant for database theory. The relational model is not really affected by the inheritance mechanisms (if any) of the data type system. I think that the impact of your work suffers when you take sides on these issues, since it distracts people from the principles of database theory, and distances people who find themselves on the other side. Also, as I am sure many people have pointed out, it makes you seem a bit careless when you allow some object mechanisms to be discredited (rightly or not) based only on how they are implemented in current products. This is like dismissing the relational model based on the fallacies of SQL. I think you would do better if you would stick to addressing the fundamentals.


C. J. Date Responds:
Larsson's message is very good! I agree with almost everything in it. I'd just like to make it clear that my criticisms of objects and "object orientation" have always been aimed at their usefulness or otherwise in a database context and not necessarily in any other. The following is a direct quote from the forthcoming third edition of the book by Hugh Darwen and myself on THE THIRD MANIFESTO (DATABASES, TYPES, AND THE RELATIONAL MODEL (to be published by Addison-Wesley next year):

[We are] interested in this book in the field of database management. We are therefore interested in—among many other things—the applicability of object concepts and technology to that field. Please note, therefore, that all remarks made in this book concerning object concepts and technology must be understood in this light. We offer no opinion whatsoever regarding the usefulness of object ideas in any other context.


Но это же во многом (хотя и не во всем) соответствует тому, о чем пишу я.
15 фев 05, 15:47    [1322735]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить