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

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

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

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

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

3) Вы вдруг стали игнорировать обсуждение линейного времени поиска в РСУБД, которое ведет к проигрышу производительности в сравнении с ООБД, хотя сами же подняли эту тему. Вы же сами сами говорили "Хотел бы увидеть ваш контрпример" (т.е. контсантный поиск). Так вот он, столь желанный контрпример приведен, время поиска константа, но реакции - 0. Загадка. Как я понял, проигрыш РСУБД в этом пункте был одним из основных аргументов специалистов Версанта в пользу ООБД (http://www.versant.com/solutions/industrial/customers_story/bosch), а тут оказывается, что никакого проигрыша на самом деле нет. Подозреваю что либо вопрос будет игнорирорваться, либо будет задержка с ответом по-существу, пока с вопросом разбирается кто-то из спецов.

Это не наезд, просто интересно разобраться. Еще раз повторяю, если Вы не технический специалист, а менеджер, то в этом разумеется нет ничего плохого, просто нужно было об этом сразу сказать.
16 фев 05, 00:27    [1323488]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Злой Хорёк
Member

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

Странно как-то у вас с книгами. Вы хотя бы в магазин заглядывали. Тот экземпляр, который у меня датирован 1999 годом. Я же из этой книги цитаты и приводил. Где вы там нашли, что ООБД хотя бы остались на том же уровне как и было во времена ОО истерии? Так загляните в книгу и посмотрите, главу 24 - там же черным по белому написано почему ООБД проигрывают РБД. Там же ответ на вашу фразу "быстрее ли работает прямая навигация в ООСУБД по сравнению с JOIN-запросами в РСУБД". Я еще раз для вас повторяю, перед тем как делать какие-то заявления прочтите для начала 3-ий манифест, Дейта и Кузнецова. Перед тем как начинать филосовствовать надо бы изучить других философов. А то вы кое с чем в калашный ряд лезете. А причем ваш скачек к средствам разработки? Мы же вроде БД рассматриваем только. А то уж давайте и на тему семантики языков программирования, раз пошла такая пьянка. А ваши измышления по поводу торговли, это просто абзац какой-то. Ей богу, цитатник Ким Ир Сена, по сравнению с вами, это образец гениальной философии. Это же надо придумать такое - шпионить за банкой йогурта Вы бы для расширения своего кругозора в Wal-Mart хотя бы заглянули, как там учет ведется...

2 BaZa

Прочтение одной книги не делает спецом. Но все равно одна книга Дейта лучше чем все измышления Алексея
16 фев 05, 06:27    [1323589]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
[quot Alexey Rovdo]Но это же во многом (хотя и не во всем) соответствует тому, о чем пишу я./quot]Нет, не соответствует.

Пара советов, еслипозволите. У Вас, насколько я понял, стоит совершенно конкретная задача продвижения на рынке конкретного продукта. Продукт этот позиционирует себя как ООСУБД. Вот Вы и пытаетесь доказать общественности, что "ОО" лучше, чем "Р". И делаете при этом ошибки, пытаясь противопостовлять их друг другу. А в приведённой Вами цитате сказано чёрным побелому - подходы эти ортогональны. ОО нечего делать на поле хранения, целостности и манипулирования данными. Вот инструмент мэппинга "реляционная структура - набор объектов" - это да, это жизненно. Продавайте на здоровье. А реляционную теорию нетрогайте лучше - Вас разорвут на части. Что, собственно и происходит.
16 фев 05, 06:44    [1323598]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

Вы вдруг стали игнорировать обсуждение линейного времени поиска в РСУБД, которое ведет к проигрышу производительности в сравнении с ООБД, хотя сами же подняли эту тему. Вы же сами сами говорили "Хотел бы увидеть ваш контрпример" (т.е. контсантный поиск). Так вот он, столь желанный контрпример приведен, время поиска константа, но реакции - 0. Загадка. Как я понял, проигрыш РСУБД в этом пункте был одним из основных аргументов специалистов Версанта в пользу ООБД (http://www.versant.com/solutions/industrial/customers_story/bosch), а тут оказывается, что никакого проигрыша на самом деле нет.
...
Это не наезд, просто интересно разобраться.


Хеш-индексы эффективны при отработке взаимосвязей many-to-many, иногда при отработке взаимосвязей one-to-many и никогда для one-to-one. В рассмотренном мною примере мы при отработке запроса:

SELECT Item.id, Item.day, Flight.description, Seat.level, Count(Seat.id)-Count(Ticket.id) free_seats
FROM Item 
INNER JOIN Flight ON Flight.id = Item.flight_id and Item.day = '01.01.2005'
INNER JOIN City AS City1 ON Flight.startpoint_id = City1.id and City1.name = 'A' 
INNER JOIN City AS City2 ON Flight.endpoint_id = City2.id and City2.name = 'B'
INNER JOIN CraftType ON CraftType.id = Flight.crafttype_id 
INNER JOIN Seat ON Seat.crafttype_id = CraftType.id 
LEFT OUTER JOIN Ticket ON Ticket.seat_id = Seat.id and Ticket.item_id = Item.id
GROUP BY Item.id, Item.day, Flight.description, Seat.level

Равно как и при отработке запроса по модели SergSuper:

select s.race, p.class, p.cnt-sum(isnull(d.cnt,0))
  from Shedul s 
  inner join Place p ON s.fly=p.fly
  left join Sold d on d.race=s.race and d.date='нужная дата' and d.class=p.class  and d.flag=1
  where s.date='нужная дата' and s.race='нужный рейс'
  group by s.race, p.class, p.cnt

Мы, к сожалению, при малом объеме данных использования хэш индексов в плане запроса не увидим. Но можно добавить в конце запроса
OPTION (HASH JOIN) и посмотреть план после этого.

А потом почитать вот это.

Не стану приводить здесь план полностью - вырежу из него только кусочек:

|--Hash Match(Inner Join, HASH:([Flight].[crafttype_id])=([Seat].[crafttype_id]))
   |--Hash Match(Inner Join, HASH:([Flight].[id])=([Item].[flight_id]))
      |--Hash Match(Inner Join, HASH:([City1].[id])=([Flight].[startpoint_id]))

В данном случае поведение оптимизатора несколько странное.
Он построит хэш-индекс по полям City1.id, Flight.id, которые, вобще говоря, имеют уникальные значения, а потом будет в этом индексе искать значения соответствующие хэш-функции от Flight.startpoint_id и Item.flight_id. Мне кажется, что по сути это будет эквивалентно поиску по B-tree индексу. Но может быть мы именно сбиваем с толку оптимизатор нашим навязыванием хэш-ндексов? По логике вещей их эффективность должна в первую очередь проявляться при обратном подходе, т.е. нужно строить хэш-индекс по Item.flight_id, а затем выбирать по нему значения исходя из хэш-функции от Item.id. Кстати, если упростить наш запрос до такого:

SELECT Ticket.*, Item.id, Flight.description
FROM Ticket 
INNER JOIN Item ON Ticket.item_id = Item.id 
INNER JOIN Flight ON Flight.id = Item.flight_id 
OPTION (HASH JOIN)

или по модели SergSuper:

SELECT Sold.*, Shedul.race, Race.caption
FROM Sold 
INNER JOIN Shedul ON Shedul.race = Sold.race and Shedul.date = Sold.date 
INNER JOIN Race ON Race.race = Shedul.race 
OPTION (HASH JOIN)

То план запроса примет более объяснимый вид:

  |--Hash Match(Inner Join, HASH:([Item].[flight_id])=([Flight].[id]))
       |--Hash Match(Inner Join, HASH:([Ticket].[item_id])=([Item].[id]))
       |    |--Clustered Index Scan(OBJECT:([test1].[dbo].[Ticket].[IX_Ticket_(item_id)]))
       |    |--Index Scan(OBJECT:([test1].[dbo].[Item].[IX_Item_(day_flight_id)]))
       |--Clustered Index Scan(OBJECT:([test1].[dbo].[Flight].[PK_Flight_(id)]))

 |--Hash Match(Inner Join, HASH:([Race].[race], [Sold].[date])=([Shedul].
             [race], [Shedul].[date]), RESIDUAL:([Shedul].[race]=[Race].[race] AND
             [Sold].[date]=[Shedul].[date]))
       |--Hash Match(Inner Join, HASH:([Sold].[race])=([Race].[race]), RESIDUAL:([Sold].[race]=[Race].[race]))
       |    |--Table Scan(OBJECT:([test2].[dbo].[Sold]))
       |    |--Index Scan(OBJECT:([test2].[dbo].[Race].[IX_Race]))
       |--Index Scan(OBJECT:([test2].[dbo].[Shedul].[IX_Shedul]))

Видно, что здесь уже SQL-сервер использует:
HASH:([Ticket].[item_id])=([Item].[id]) и HASH:([Item].[flight_id])=([Flight].[id]) .

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

SELECT item1.subitem1 FROM item1

и при этом возвращаемый массив данных весьма велик, то сравнимый запрос в РСУБД

SELECT Subitems.subitem1 FROM item1
INNER JOIN Subitems ON Items.item = Subitems.item

при использовании хэш-индексов может оказаться столь же быстрым
(но никак не быстрее).

Но вот при обращении из программы к конкретным связям конкретного объекта

my_sum = item1.subitem1.subsubitem1 + item2.subitem1.subitem1

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

Дополнительный минус хэш-индексов - трудоемкость обновления при обновлении данных.

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

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

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

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



Думайте, что хотите. На этот вопрос ответа не будет (просто потому, что он не имеет никакого отношения к этой дискуссии). В соседней ветке вы даже вычислили срок создания объектного решения (1 мес) и используете это как аргумент его трудоемкости. Если вы действительно считаете, что для подготовки этого решения кому-то может потребоваться месяц - пусть так - я вовсе не собираюсь вас переубеждать.
16 фев 05, 12:02    [1324297]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

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


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

c127

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


Но это вовсе не аргумент. Это простая констатация факта. Разумеется, этот факт можно поставить под сомнение и высказывать аргументы за и против (что и делает, к примеру, Al).

c127

Даже если это так, то что чтоб отвоевать кусок рынка у РСУБД быть просто "полезным" мало, необходимо, быть ПОЛЕЗНЕЕ, чем РСУБД.


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

Кто-то скажет - а давайте начнем именно с тех, пока нам непонятных, случаев. Но тогда они так и останутся непонятными, а я хочу навести мосты между двумя этими мирами (ООСУБД и РСУБД). В мире нет ничего абсолютного. Между терминами "полезный" и "более полезный" нам не найти разницы пока мы не приступим к анализу всех факторов в конкретной обстановке. Так и "полезность" использования ООСУБД возникает постепенно при совпадении ряда важных условий (вот мы и разбираемся сейчас - каких именно). "Постепенно" в данном контексте означает наличие большой зоны, где явного предпочтения нельзя отдать ни одной из двух технологий и выбор приходится делать именно с учетом предполагаемого (или предопределенного) изменения этих "условий" и планов развития системы в будущем.
16 фев 05, 12:24    [1324370]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

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

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

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


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

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

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

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

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


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

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

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

Кстати, я в субботу в самолете сел не на указанное в талоне место, а на "мое" место села женщина - непорядк в системе - объект не соответствует адресу.

На самом деле никому не нужно отслеживать каждую баночку или какой билет какому месту в самолете соответствует.


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

И снова привожу реальный пример:

Versant Corporation (www.versant.ru)
Современные высокотехнологичные пассажирские поезда компании Siemens Transportation Systems содержат множество решений, предназначенных для удовлетворения постоянно растущих требований к уровню комфорта и предоставляемым в пути услугам. Например, таким как видео по запросу, CD-музыка, радио, бронирование мест и разнообразные телекоммуникационные сервисы (телефон, голосовая почта, факс и т.д.). Эти и многие другие возможности сегодня реализуются Siemens в поездах серий ICT и ICE3. Для управления указанными сервисами Siemens оборудует поезда специальной интегрированной АСУ, которая построена на базе объектно-ориентированной СУБД FastObjects t7.
Пассажирские поезда ICT и ICE3 имеют множество специальных сервисов предназначенных для повышения комфорта пассажиров. Все эти сервисы контролируются через упомянутую выше интегрированную управляющую систему. A FastObjects t7 представляет собой встроенную базу данных этой системы, обеспечивая хранение эксплуатационных данных и другой важной информации о поддерживаемых сервисах.
Почему же Siemens Transportation Systems решила использовать именно технологии Versant и конкретно ООСУБД FastObjects t7?
Первое и основное — компании была необходима действительно встраиваемая система управления данными, допускающая автоматизацию всех задач своего обслуживания и администрирования. Реальный объем данных, обращающихся в системах управления пассажирскими сервисами поездов Siemens, может колебаться в значительных пределах и зависит от множества факторов. Здесь приходится принимать во внимание то, имеют ли соответствующие сервисы специфические настройки для каждого конкретного пассажира, как то: какие видеоролики или радиостанции были выбраны пассажиром, было ли его место предварительно забронировано, как много факсовых и голосовых сообщений им было отправлено и т.п. Для быстрого сохранения и оперативного доступа ко всем этим данным Siemens понадобилось встроить СУБД в управляющие системы своих поездов. Как и любое другое оборудование на борту поезда, такие управляющие системы и их базы данных должны быть максимально автономными и требовать минимального обслуживания. Ведь поезд может находиться в рейсе весьма значительное время, а возможности для сервисного обслуживания при этом зачастую отсутствуют. Применив для хранения данных FastObjects t7, Siemens получила возможность использовать богатый административный API этой ООСУБД для автоматизации всех задач по обслуживанию системы (таких, например, как регулярный бэкап), так что для их выполнения теперь не требуется привлечение технического специалиста. Повышая автономность всех систем и их компонентов, Siemens снижает издержки на их обслуживание и делает эксплуатацию своих поездов более простой и удобной.


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

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Я понимаю, что все привыкли к тому, что "места указывает проводник". Но не надо выдавать реальное незнание предметной области (современный пассажирский транспорт и его обслуживание) за истину в последней инстанции. Ведь помимо билета к конкретному месту может быть привязана масса услуг, которые транспортной компании хотелось бы "впарить" пассажиру (спецпитание, перевод входящих телефонных звонков на телефон у конкретного места, то же в отношении e-mail, предоставление доступа к интернет, продажа медиа-контента и т.п.).

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

И дальше бла-бла-бла про 2 (Два!) поезда во всем мире, которые оборудованы FastObjects t7..... и т.д.
Ну что-же, целых два поезда....
Я не сомневаюсь, что подобных вырезок можно привести тысячи, в которых будут упомянуты гораздо большие размеры задействования систем, но только названия там будут что-то типа: Oracle...MS SQL...Sybase ASA....InterBase (вот танки Абрамс на InterBase работают... :)).

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

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

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

Я вот никак не пойму: вы чего в этом конкретном топике добиваетесь?

А я вам не скажу - думайте что хотите.

tygra

Чего вы от нас хотите?


Лично от вас ? Ничего. Досвиданья.

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

Откуда: Москва
Сообщений: 913
И опять реальный пример (доп. информация):

...
The Origin and Destination application is the latest in a series of yield management systems for British Airways. This new application is able to optimise the financial performance of the airline network as a whole rather than optimising individual point-to-point links as in the previous system. The new system uses inventory status, models of demand, yield and no-shows, and proprietary business rules to optimise the availability of seats at different prices for each flight leg. Yield management has long been a critical part of airline economics, but in the aftermath of September 11, 2001, flexible and accurate Origin and Destination planning is more important than ever.

"The Versant object database stores complex object models of a complete year of airline operations, or about 380,000 flights, said Richard Ruffell, IT Programme Manager, British Airways. "Previous versions of the application based on relational database technology were not fast enough to handle the complex models needed to optimise operations to the accuracy demanded by British Airways."

"With Versant as part of the solution, our benchmarks showed a 5X total performance advantage, enabling reading 800 to 1000 distinct object graphs per second. Versant is used in the areas of our application with the most demanding performance requirements," said Ruffell.

...

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

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

Думаю. Даже страшно становится.
автор
Лично от вас ? Ничего. Досвиданья.

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

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

Как не несущие? Если вы на них отвечаете, значит несущие.
автор
А то мне уже немного надоело отвечать вам в стиле "сам такой"

Какой?
автор
(а как вам еще отвечать, если вы ни вопросов ни дельных аргументов не высказываете).

Я с вас беру пример - только у меня более понятно и кратко, и я не пытаюсь всех наставить на путь истиный.

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

-- Tygra's --
16 фев 05, 14:29    [1324919]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
Alexey Rovdo
Замечание:
Разумеется, все то же самое можно сделать и на базе РСУБД. Но в таком применении РСУБД будет менее эффективна (с точки зрения общей производительности системы и трудозатрат на разработку), чем ООСУБД, даже в том предположении, что в обоих случаях разработкой будут заниматься самые-самые профессиональные разработчики.

Это ваше замечание можно отнести к вашему упоминанию "складов с поштучным учетом движения товаров с большим набором характеристик"?
На такой вопрос вы способны ответить?

Если ответ "да" - будем это обсуждать (и порвем на куски), если ответ "нет, ООСУБД не будут более эффективны (с точки зрения производительности и трудозатрат) чем РСУБД" - то в чем преимущества ООСУБД для этих самых "складов с поштучным учетом движения товаров с большим набором характеристик"?
Утверждение, что дескать ООСУБД могут быть полезны - не несет никакой информации. Все может быть полезно. Абсолютно все.
16 фев 05, 14:38    [1324947]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

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

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

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

Обращу вам вашу же цитату:
автор
а ваши едкие замечания не несущие никакой информации оставьте при себе. А то мне уже немного надоело отвечать вам в стиле "сам такой"

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

Прямо сказочка про Белого Объектно-Ориентированного Бычка какая-то...

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

Откуда: Москва
Сообщений: 913
Кто-то интересовался тем, где это имеется большой ассортимент товаров с очень разными характеристиками.

Привожу реальный пример:

Qina

Private Trading Network for the furniture industry
Catalogs enabling consumer specified articles (complex product structures)
A chair has a specific fabric, is available with or without arms, ...
Manages Business Agreements between trading parties (suppliers, retailers, ...)
Exchanges business documents – XML
Manage subscriptions to other publisher’s catalogs
Provides a sector wide category management via an ontology

Qina решила использовать ООСУБД Versant.
...

Versant’s support for complex object models, including relations and inheritance, helped us in writing the application as we designed it.
No need for complex database mappings.
Easy, fast retrieval of information by navigating the data model
Transparent, data objects are regular java classes which are automatically enhanced.
Combining Versant with an application server provided us with a robust architecture
to build transactional processes: JTA binding
which are scalable: session pooling and caching architecture
This is indispensable in the context of the trading network we’re building.


подробнее о программном продукте
16 фев 05, 14:58    [1325042]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
Господи, да надоели вы со своими реальными примерами. Я сам себе реальный пример.

Сменив три торговые компании я не удивляюсь ни "consumer specified articles (complex product structures)", ни "chair has a specific fabric, is available with or without arms", ни "Business Agreements between trading parties ", ни "other publisher’s catalogs". Поштучному учету я тоже не удивляюсь, как и невозможности продать один товар два раза.

Я удивляюсь тому что оказывается для этого надо было использовать ООСУБД.
А мужики то и не знали. Все на MS SQL да на аксесе сваяли.

Вы на предыдущий мой вопрос будете отвечать? Будут ли ООСУБД более эффективны (с точки зрения производительности и трудозатрат) чем РСУБД - в случае складов с поштучным учетом движения товаров с большим набором характеристик?
Или будете продолжать выискивать в сети примеры внедрения Versant и пугать нас словами "session pooling and caching architecture"?

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


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

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

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


Это ваше замечание можно отнести к вашему упоминанию "складов с поштучным учетом движения товаров с большим набором характеристик"?
На такой вопрос вы способны ответить?
...


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

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

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



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

Если ткнуть пальцем в любой компьютер, то окажется, что он построен на базе Pentium IV, Pentium III или Celeron (ну может еще процы от AMD можно добавить). А вот комп на базе Itanium надо еще поискать. Однако это абсолютно ничего не говорит о качестве и возможностях, заложенных в процессор Itanium.

А вот еще. На мировом рынке СУБД доля Oracle оценивается в 30-40%. А в России она порядка 70%. И это в деньгах. А если считать методом "тыка" так наверное и побольше будет. И какие из этого можно сделать выводы в отношении самого продукта? По моему никаких - можно только в отношении маркетинговой политики высказываться.
16 фев 05, 15:42    [1325279]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32895

Привет, Alexey!
Ты пишешь:

Alexey
AR> Если ткнуть пальцем в любой компьютер, то окажется, что он построен на базе Pentium IV, Pentium III или Celeron (ну
может
AR> еще процы от AMD можно добавить). А вот комп на базе Itanium надо еще поискать. Однако это абсолютно ничего не говорит о
AR> качестве и возможностях, заложенных в процессор Itanium.
Не буквоедства ради, но смею заметить, ты пытаешься сравнить
разные категории процов.
Alexey
AR> А вот еще. На мировом рынке СУБД доля Oracle оценивается в 30-40%. А в России она порядка 70%.
AR> И это в деньгах. А если считать методом "тыка" так наверное и побольше будет.
AR> И какие из этого можно сделать выводы в отношении самого продукта? По моему никаких -
AR> можно только в отношении маркетинговой политики высказываться.

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

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

16 фев 05, 15:51    [1325329]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Я могу лишь говорить об этом в некотором приближении (так сказать "среднестатистически"). Т.е. на 10 реальных ситуаций с поштучным учетом движения товаров с большим набором характеристик в 7-8 случаях ООСУБД будут более эффективны, чем РСУБД.

Уже вот как? Уже не полностью, уже 8 из 10? Прогресс!
автор
И наоборот, если основной задачей системы будет информирование конечного покупателя о том, йогурт какой марки и на какой полке он покупал в прошлый раз (в этом месяце), то это будет фактором в пользу ООСУБД

Ой, а я и не знал. Мы вот используем РСУБД, но если вы оформите заказ у нас на сайте а потом будете просматривать товары, то на товаре из вашего заказа будет отметка: Это вы уже покупали. Айяйяй, как же мы без ООСУБД смогли???!!!
автор
Таких условий существует множество (предполагаемый объем базы, частота появления новых товаров и новых характеристик, сроки, отведенные на разработку и т.п.).

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

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

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

Т.е. в конкретику вдаваться не хочется, в чем эффективность тоже (в разработке, скорости или еще чего), но вот 7-8 раз всё равно :)

Но где-то я уже это видел:

Просто другая технология. Более эффективная, чем реляционная. Во всех отношениях.

а потом очевидно будет так:

Ваши приложения заведомо уступают нашим

Успехов на пути Андрея Леонидовича
16 фев 05, 16:07    [1325398]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
2 Alexey Rovdo
Если ткнуть пальцем в любой компьютер, то окажется, что он построен на базе Pentium IV, Pentium III или Celeron (ну может еще процы от AMD можно добавить). А вот комп на базе Itanium надо еще поискать. Однако это абсолютно ничего не говорит о качестве и возможностях, заложенных в процессор Itanium.

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

Вы постоянно приводите примеры систем, аналоги которых вполне успешно реализуются на РСУБД.
Быть может дело в маштабах, нагрузки не те? Сомнения. Лично меня слова "complete year of airline operations, or about 380,000 flights" не впечатлили.

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

Тогда почему 90% таких систем (цифра с потолка) реализуются на РСУБД? Глупые все?

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

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

--------------

Вы много раз повторяли слова "штучный учет" и "большой набор характеристик, зачастую индивидуальных"
Переспрошу еще раз. Что за индивидуальные характеристики в учете? В складском учете (раз уж вы упоминали склады), в бухгалтерском, в налоговом, в каком еще? Откуда там взялись эти индивидуальные характеристики и как вы их собираетесь учитывать?
Штучный учет - это штучный учет. С точки зрения штучного учета (складского, бухгалтерского, налогового, и всяких прочих учетов) по барабану - есть у объекта учета какие-то вспомогательные характеристики, или нет их.
16 фев 05, 16:09    [1325409]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
Да, сколько мышиных кликов потребовалось-то?
16 фев 05, 16:16    [1325432]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
пардон во второй ссылке ошибся

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=27#940588
16 фев 05, 16:23    [1325467]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

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

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

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

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


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

Конечный пользователь биллинговой системы обычно все-таки запрашивает уже консолидированную аналитику, которую удобнее держать в РСУБД. А вот сами биллинговые системы информацию откуда берут? Ответ - из оборудования. А вот в этом самом оборудовании ООСУБД стоят очень и очень часто. Т.е. как средство первичного сбора и накопления разнообразных данных низкого уровня ООСУБД весьма эффективны и хорошо себя зарекомендовали.
Подумайте кстати и о такой проблеме вполне типичной для современных биллинговых систем. А именно отслеживание в онлайне текущего баланса пользователя, имеющего доступ к массе разнообразных сервисов и своевременное его отключение именно в момент исчерпания этого баланса. И в этом опять-таки ООСУБД могут оказаться эффективнее РСУБД.
16 фев 05, 16:32    [1325520]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить