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

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

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


Здесь я достаточно четко описал все свои претезии к модели SergSuper. Если вы с ними согласны - согласитесь. Если нет, то напишете, с чем именно вы не согласны. Я согласен работать с этой моделью, но мне нужна конкретная работающая модель. Устраиват ли вас выбранный мною вариант 1 (или мы должны ставить эксперименты на варианте 2)? Согласны ли вы с поправками, внесенными мною в Запрос 1 (добавление еще одного JOIN)? Если не согласны - аргументируйте.
10 фев 05, 10:58    [1312789]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

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

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

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

-- Tygra's --


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

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

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

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

-- Tygra's --
10 фев 05, 11:31    [1312932]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Если бы вы внимательно читали мои рассуждения, то увидели бы, что я вовсе не рассматривал случай 1:1 в ОМД.

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

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

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

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

Я всего лишь утверждал, что анализируя работу одного СКЛ сервера вообще то нельзя делать вывод обо всех СКЛ серверах. ДАЖЕ если МССКЛ в данной ситуации что-т ищет, то другой какой-нибудь может в аналогичной ситуации и не искать. С Вашей стороны это спекуляции и демагогия.

Кроме того я бы хотел увидеть план запроса, который выдает фастобджектс. Если Вы собрались сравнивать планы запросов, то давайте возьмем этих планов хотя бы два. А то получается сравнение планов на основании одного плана.

>В РМД запрос любого параметра из таблицы Fly для заданного значения в таблице Shedul будет сопровождаться операцией JOIN и поиском той самой записи в таблице Fly, которая соответсвует заданной записи в таблице Shedul.

Это неверно в данной ситуации JOIN не обязателен. Опять Вы делаете общие выводы на основании очень частной ситуации и запроса, написанного Вами. Этот запрос можно было написать и по-другому.

>В ОМД при обращении посредством навигации Item.Flight никакого поиска (включающего циклические операции) проводиться не будет, т.е. выборка искомого значения будет происходить быстрее.

Планчик покажите. А то это только слова.

Есть ссылка - есть поиск. Вы же не физический адрес в памяти храните. А что касаестся поиска в РСУБД, то там может быть хеш индекс, он имеет константное время поиска и очень небольшое. И совсем не очевидно, что будет искаться медленне чем происходит разадресация в ОМД.
10 фев 05, 11:53    [1313019]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Я смотрю на код, в котором вы определяете количество свободных мест
while (iter.hasNext() )
   {
      Item itm = (Item) iter.next(); // считываем объект
      System.out.println( itm.id + "   " + itm.day + " " +
                          itm.flight.description + "          1-st     " +
                          Integer.toString(itm.flight.crafttype.seats1.size() - itm.tickets1.size()) );
      System.out.println( itm.id + "   " + itm.day + " " +
                          itm.flight.description + "          2-nd     " +
                          Integer.toString(itm.flight.crafttype.seats2.size() - itm.tickets2.size()) );
   }
.. и вижу, что собственно размер массива определяется через size(). Это должо работать быстро.
А если вам надо проводить более сложные агрегатные вычисления? Например, каждый проданный билет был продан по собственной цене. Надо подсчитать общую сумму вырученных от продажи билетов на рейс средств и сравнить ее с некоей средней величиной, основанной на количестве билетов на самолет и средней ценой продажи за предыдущий период (пусть для определенности цена уже задана). Формула будет примерно следующей sum(seats[ i].price) - tickets.size() * const_average_price)
Как будет выглядеть решение? Насколько оно усложнится?
10 фев 05, 12:51    [1313267]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

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


Но это не будет связью 1:N - это будет 1:1 (и никакого выигрыша в скорости ни у РСУБД ни у ООСУБД в этом случае не обнаружится - все будет одинаково).

c127

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


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

c127

Я всего лишь утверждал, что анализируя работу одного СКЛ сервера вообще то нельзя делать вывод обо всех СКЛ серверах. ДАЖЕ если МССКЛ в данной ситуации что-т ищет, то другой какой-нибудь может в аналогичной ситуации и не искать. С Вашей стороны это спекуляции и демагогия.


Выше вы упомянули PostgreSQL. Вот конкретная реализация модели SergSuper для PostgreSQL:

CREATE TABLE "Race" (
       race    int NOT NULL PRIMARY KEY,
       caption varchar(255) NULL
) WITHOUT OIDS;
ALTER TABLE "Race" OWNER TO postgres;

CREATE TABLE "Fly" (
       fly    int NOT NULL PRIMARY KEY,
       caption   varchar(255) NULL
) WITHOUT  OIDS;
ALTER TABLE "Fly" OWNER TO postgres;

CREATE TABLE "Shedul" (
       race    int NOT NULL REFERENCES "Race"  (race),
       date    char(10) NOT NULL,
       fly     int NULL REFERENCES "Fly"  (fly), 
       UNIQUE (race, date)
) WITHOUT OIDS;
ALTER TABLE "Shedul" OWNER TO postgres;

CREATE TABLE "Sold" (
       race                 int NULL,
       date                 char(10) NULL,
       class                int NULL,
       cnt                  int NULL,
       fio                  varchar(255) NULL,
       flag                 int NULL,
       price                money NULL, 
       FOREIGN KEY (race, date) REFERENCES "Shedul"  (race, date)
) WITHOUT OIDS;
ALTER TABLE "Sold" OWNER TO postgres;

CREATE TABLE "Place" (
       fly                  int NULL,
       class                int NULL,
       cnt                  int NULL, 
       FOREIGN KEY (fly) REFERENCES "Fly"  (fly)
) WITHOUT OIDS;
ALTER TABLE "Place" OWNER TO postgres;

Запрос 1 будет выглядеть так:

select s.race, p.class, p.cnt - COALESCE(sum(d.cnt),0) AS free_seats
  from "Shedul" s 
  inner join "Place" p ON s.fly=p.fly
  left join "Sold" d on d.race=s.race and d.date='01.01.2005' and d.class=p.class  and d.flag=1
  left join "Race" r on s.race = r.race
  where s.date='01.01.2005' and r.caption='A-B'
  group by s.race, p.class, p.cnt 
  order by s.race;

Согласны ли вы проанализировать выполнение именно этого запроса на именно этой модели в PostgreSQL и сравнить это с FastObjects ? Вы можете предложить ЛЮБУЮ ДРУГУЮ реляционную СУБД и любые доработки в предложенную реализацию модели. Но чтобы проводить какие-то исследования и сравнения нужна конкретика. Так вот давайте - конкретизируйте, а не придумывайте новые отмазки.

c127

Кроме того я бы хотел увидеть план запроса, который выдает фастобджектс. Если Вы собрались сравнивать планы запросов, то давайте возьмем этих планов хотя бы два. А то получается сравнение планов на основании одного плана.


План какого запроса? В реализации Подзадачи 1 для FastObjects, которую а подробно описал здесь. Нет НИКАКИХ ЗАПРОСОВ. Разумеется, я бы мог представить вам план запроса FastObjects, если бы запрос был.

c127

Опять Вы делаете общие выводы на основании очень частной ситуации и запроса, написанного Вами. Этот запрос можно было написать и по-другому.


Так напишиете его по-другому. Вот и обсудим.

c127

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


В ОМД мы храним физический адрес объекта на диске (в файле).

c127

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


Хотите посмотреть как это будет с хеш индексами. На каком запросе будем смотреть (дайте текст запроса)?
10 фев 05, 13:30    [1313393]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
Я смотрю на код, в котором вы определяете количество свободных мест
.. и вижу, что собственно размер массива определяется через size(). Это должо работать быстро.
А если вам надо проводить более сложные агрегатные вычисления? Например, каждый проданный билет был продан по собственной цене. Надо подсчитать общую сумму вырученных от продажи билетов на рейс средств и сравнить ее с некоей средней величиной, основанной на количестве билетов на самолет и средней ценой продажи за предыдущий период (пусть для определенности цена уже задана). Формула будет примерно следующей sum(seats[ i].price) - tickets.size() * const_average_price)
Как будет выглядеть решение? Насколько оно усложнится?


В FastObjects нам прийдется вычислять сумму выбирая каждый объект Ticket из БД. Единственное, что мы сможем здесь сделать - это выбирать не весь объект целиком, а только значения поля price. Сам же подсчет суммы будет производиться в приложении (код не привожу, ввиду очевидности). Язык запросов, реализуемый FastObjects не поддерживает никаких агрегирующих функций (поддерживается только COUNT).
10 фев 05, 15:37    [1313803]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Юличка
Member [заблокирован]

Откуда:
Сообщений: 40
Alexey Rovdo
Язык запросов, реализуемый FastObjects не поддерживает никаких агрегирующих функций (поддерживается только COUNT).


Мальчики, только ни па почкам, он же сам презнался!
10 фев 05, 16:11    [1313950]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
Да ладно вам, Юленька.
Если есть способ ограничить набор перетягиваемых на клиента данных (в соответствии с условиями отбора) - то FastObject наверное может попытаться конкурировать с файл-серверными РСУБД. Там, хоть и SQL, и реляционная модель - а все равно на клиенте все считается

Чем дальше в лес - тем больше этот топик напоминает обсуждение файлмейкера
Одно лицо - не-SQL база, в которой смешались в кучу кони, люди, клиентское приложение и структура данных, все приправлено бредовыми (зачеркнуто) веселыми аргументами, и вся эта хуета выдается за окуенный плюс и грейт эдванс.
10 фев 05, 16:52    [1314159]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

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

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

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

Кстати, в примере был использован size(), как величина массива, а не COUNT, как количество
10 фев 05, 17:15    [1314254]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП
Да ладно вам, Юленька.
Если есть способ ограничить набор перетягиваемых на клиента данных (в соответствии с условиями отбора) - то FastObject наверное может попытаться конкурировать с файл-серверными РСУБД. Там, хоть и SQL, и реляционная модель - а все равно на клиенте все считается


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

Большей функциональностью, масштабируемостью и навороченностью (сложностью) отличается Versant Developer Suite. Эта ООСУБД уже ориентирована только на клиент/серверные (двух- и многозвенные) конфигурации.
10 фев 05, 17:28    [1314292]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Тююююю...... я тут говорил о нетривиальной функции, выполняемой над множеством значений, а оно даже Sum сделать не может? То есть, что бы сделать даже Sum атрибутов объекта экстента, ему таки придется тащит все объекты на клиент? Или таки можно обойтись хотя бы перетаскиванием одного атрибута, как написано здесь, хотя это тоже нехило.
10 фев 05, 17:34    [1314309]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

Кстати, в примере был использован size(), как величина массива, а не COUNT, как количество


Мне кажется ответ на это замечание присутствует здесь , здесь и здесь. Но готов и уточнить свое мнение.

Что же касается аналитики для FastObjects вообще, то я обязательно в ближайшее время приведу пример использования специального средства для этого (такое средство есть).
10 фев 05, 17:42    [1314325]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
>>Язык запросов, реализуемый FastObjects не поддерживает никаких агрегирующих функций (поддерживается только COUNT).

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

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

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

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

2 Юленька

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

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

Зато FastObjects прост как грабли и поддерживает множество языков и платформ.

Ну и что? SQL прост как грабли, а клиентов к sql-ным базам можно писать на любом языке под любую платформу.
А уж по скорости и удобству разработки - всех порву, кто против аксеса слово скажет
Так что не тем вы начали меряться, не тем...

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

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

Например, любимая мозоль в споре версионник vs блокировочник - снятие согласованных отчетов по большому объему данных при условии постоянных мелких изменений. Тут уж как бы ни хотелось, а в версионнике гемор обеспечен (хотя бы с разделением OLAP и OLTP частей системы). Не в тему, но надеюсь понятно, какого рода (какой убойной силы) пример хочется увидеть?
10 фев 05, 18:01    [1314386]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
2Alexey Rovdo
Я преклоняюсь перед упорством, с которым Вы отстаиваете FO.
Но наверно следует все же признать, что возможности FO покрывают лишь малую область потребностей бизнеса.
Я просмотрел указанные ссылки, действительно ASCRUS уже задавал подобный вопрос, но я не увидел подобного ответа. Был лишь отвлеченный рассказ на тему встраиваемых/невстраиваемых объектов.

Таким образом, мы обнаружили еще одну (вдобавок к уже известным) слабость FO - аналитические запросы и агрегатные функции - их нет.

Что касается использования специального средства, то я боюсь даже думать о его цене, если только FO стоит таких денег. Раз уж зашла речь об аналитике, то как в продуктах VDS и FO обстоят дела с DSS? Если нет собственных средств, то есть ли возможность интеграции с тем же MS AS (или любым другим, это не важно)?
10 фев 05, 18:33    [1314468]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Один1
Guest
ЛП
а в версионнике гемор обеспечен (хотя бы с разделением OLAP и OLTP частей системы).
Эээ... блокировочнике имелось ввиду ? Ибо построение отчетов - любимый аргумент строннников "версионник рулез форева"

ЗЫ: оффтопа недопустим, спорить не буду.
ЗЫЫ: меня постоянно удивляет с каким фанатизмом поклонники продукта N отстаивают его. Так было в приснопамятном "Filemaker брр..", так и тут. Всегда интересовало - зачем ??? Я этого не могу понять
10 фев 05, 19:02    [1314558]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ЛП
Guest
Один1
ЛП
а в версионнике гемор обеспечен (хотя бы с разделением OLAP и OLTP частей системы).
Эээ... блокировочнике имелось ввиду ?

Канэшн! Мысль заблудился мало-мало :(
10 фев 05, 19:04    [1314563]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
2_Andreww

Эхххххххх понеслася.....

По поводу того, как работает кэширование (это насчет таскания :)):

Вот, наслаждайтесь (Это уже не про FO, а про VDS):

When you start a session, VERSANT uses three kinds of memory.

Object cache

The application memory area includes an object cache for objects accessed in the current transaction and related object cache management tables.

Server page cache

The database memory area includes a page cache for recently accessed objects and related database cache management tables.

Process memory

Either one or two processes (depending upon circumstances) are used to manage database and application memory.

Following are explanations of each of these kinds of VERSANT memory usage.

Object Cache

To improve access to objects in a short transaction, when you start a database session, VERSANT creates an object cache.
Also created are various information tables to track your processes, connected databases, and long and short transactions. One of these information tables is the cached object descriptor table, sometimes abbreviated as "cod table." It is a hash table keyed on logical object identifiers.

Object cache purpose

Object caches are for the sole use of a particular application.
Usually the object cache is in process virtual memory on the machine running the application. If you start a special kind of session, called a "shared session", the object cache will be in shared memory where it can be accessed by multiple processes in an application.
Normally, the object cache contains objects accessed in the current transaction and is cleared whenever a transaction commits or rolls back.
When an application requests an object, VERSANT first searches the object cache, then the server cache for the database to which the object belongs, and then the database itself.
Since VERSANT uses an object cache, both transient and persistent VERSANT objects and transient non-VERSANT objects created within a session are no longer valid when the session ends. Similarly, instances created outside a session are no longer valid when a session begins. For this reason, you should avoid using in a session any objects that were created outside a session.
Also, since most VERSANT classes make use of the object cache, you should avoid using instances of VERSANT classes outside of a session. Exceptions are the Vstr<type> and PString classes which have an alternative storage mechanism when the object cache does not exist. However, even for these exceptions, you cannot use in a session any instances created outside of a session.

C++/VERSANT example — For example, if you create an instance of PString before a session, it will be invalid when the session begins. If you create an instance during a session, it will be invalid after the session ends.
main()
{ dom = new PDOM;
// example of creating a PString before a session
PString s1 = "before session";
{ // example of creating a PString in a session
dom -> beginsession( "mydb", NULL );
// string s1 is now invalid
PString s2 = "inside session";
dom -> endsession();
// string s2 is now invalid
}
}

Pinning objects

When you access a persistent object by dereferencing a pointer or using the locateobj() method, it is retrieved from its database, placed in the object cache, and "pinned" in the cache. "Pinning" means that the object will physically remain in the cache until the pin is released.
Pins are released when a transaction commits or rolls back. Pins are held when a transaction checkpoint commits.
You can explicitly unpin a persistent object with the unpinobj() method. If you unpin an object, it becomes available for movement back to its database. Whether or not it will actually be removed from memory and returned to its database depends upon available virtual memory and internal VERSANT logic. When you unpin an object, a pointer to the object may become invalid, as its location in memory is no longer guaranteed.
Unpinning an object does not abandon any changes made to the object, and regardless of its location, all transaction safeguards of object integrity still apply after an object has been unpinned.

Releasing the object cache

When you commit or rollback a transaction, the object cache is cleared, but the object cache table is maintained.
When the object cache is cleared, persistent objects marked as dirty are written to their database, and all persistent objects are dropped from object cache memory. To save changes but hold persistent objects in the object cache, you can perform a checkpoint commit.
Because clearing the cache removes all persistent objects from memory, all pointers to them are invalid.
However, after a commit or rollback, you can still use links and pointers to transient objects created or modified in the current session.

Releasing objects

You can explicitly release an object from the object cache with the releaseobj() method, even if the object was previously pinned or marked as dirty.
Releasing an object can be useful if you have no further use for the object in the current transaction.
Releasing an object does not return it to its database, it just releases it from the object cache. If you have previously modified the object in the current transaction, its state will be indeterminate if it was previously unpinned, since it may or may not have been moved back to its database before being released. If you have previously explicitly written changes to the database with a group write, the changes will be saved to its database at the next commit or checkpoint commit.
Because releasing an object can cause its state to become indeterminate, it is usually used only with objects accessed with a null lock.
If you need to use a released object later in a transaction, you should explicitly retrieve it from its database again, with locateobj(), or by selecting and dereferencing it.

Cached object descriptor table

Associated with object caches are tables that track their contents and information about the objects that they contain.
The memory table associated with an object cache is called the "cached object descriptor table," which is sometimes abbreviated to "cod table." It is a hash table keyed on logical object identifiers.
The cached object table contains an entry for each object accessed in the current database session. These entries are maintained regardless of the location of the object, either in memory or on disk, and survive the ending of individual short and long transactions.
The cached object table entry for an object is called the object's "cached object descriptor" and, among other things, contains space for a pointer to the object, if it is in memory, and the object's unique identifier, its logical object identifier. The term "cached object descriptor" is often abbreviated as "cod", and the term "logical object identifier" is often abbreviated as "loid".
When you use a link, you are using an indirect reference to a persistent object through the cached object descriptor for the object. If the object is in the object cache, dereferencing a link uses the pointer entry in the cod. If the object is on disk, dereferencing a link uses the logical object identifier entry in the cod.

Cached Object Descriptor

The pointer and loid entries in a cached object descriptor can be in one of four states:

pointer --> null loid --> null state meaning --> Link is null.

pointer --> null loid --> non-null state meaning --> Link is to an object on disk but not in memory.

pointer --> non-null loid --> null state meaning --> Link is to a transient instance in memory.

pointer --> non-null loid --> non-null state meaning --> Link is to an object on disk and in memory.

When a process requests an object using a link, VERSANT first checks the cached object descriptor table to determine whether the object has been previously accessed in the session. If the object is not in the cache, VERSANT will look for the object in all connected databases, bring it into memory, and return a cached object descriptor for the object.
For each object, besides a loid and a pointer, the cached object descriptor table also maintains the following information about the status of an object in the object cache:

Status of lock level When you access an object, you implicitly or explicitly set a null, read, update, or write lock. The C++/VERSANT default, which can be changed, is to set a read lock.

Status of pinning When you access an object in C++/VERSANT, you implicitly pin the object in the object cache. You can override this behavior with explicit pin and unpin methods. You can access objects with pointers only if they have been pinned. To access an unpinned object, you must use an object link.

Status of update When you change an object, you must mark it as dirty so that its database will be updated at the next commit.

Status of newWhen you create a new persistent object, it is automatically marked for creation in the default database at the next commit.

Status of deleted When you delete an object, it is automatically marked for deletion from its database at
the next commit.

Because of the information maintained in the cached object descriptor table, when you access an object, all relevant information about the object is immediately known to the application. The intermediate level of indirection of cached object descriptors also allows VERSANT to manage memory as needed without affecting the application.
The size of the cached object table is limited only by available memory. There is one cached object table for each active database session.
Since a session has only one short transaction active at any time, only that active transaction can access its cached object table. Since each transaction has its own object cache, it is possible to have duplicate copies of the same object residing in different caches of different transactions conducted by different applications.
When a transaction ends with a commit or rollback, cached objects and their short locks are released, but the cached object descriptors remain in the cached object table. Exceptions to this behavior are parent
transactions that inherit locks when a descendant terminates, or when you perform a checkpoint commit that saves changes but maintains locks.
When a database session ends, both objects and cached object descriptors are freed, and all short locks are released.
Cached object descriptors and their states are transparent to an application. You do not need to be concerned with the cached object descriptor table except in the following situations:

Large transaction By default, when you access an object, C++/VERSANT pins it in the object cache until the transaction ends.
If you are accessing an extremely large number of objects in a transaction, then it is conceivable that you might run out of virtual memory. In this case, you might want to control pinning explicitly.
If you do unpin an object, you need to remember that you then cannot access it with a pointer.

Long session The cod table maintains an entry for each object accessed in a session. The cod table is not cleared until a session ends.
In a continuous session over an extremely long period of time, it is conceivable that you might run out of memory for the cod table. In this case, you might want to clear the cached object descriptor table.
Clearing the cached object descriptor table is not necessary until after you have accessed several million objects in a session.
If you do clear the cached object descriptor table, you need to remember that you lose all information about the object, including its update status.

Object cache management

To clear the cached object descriptor table, you can use the following explicit routines.

c o_zapcods()
c++ zapcods()


To clear the cached object descriptor table with a "clean cods" option, you can use the following.

c

o_endpinregion()
o_gwriteobjs()
o_xact()
o_xactwithvstr()

c++

endpinregion()
gwriteobjs()
xact()
xactwithvstr()


Server Page Cache

To improve access to objects used frequently by multiple applications, when you start a database, either explicitly with the startdb utility or implicitly by requesting a database connection with connectdb() or beginsession(), VERSANT creates a page cache for that database.
The database page cache contains disk pages for objects recently requested by an application. The database cache is in shared virtual memory on the machine containing the database so that server processes associated with multiple applications can access the same pages.
Also associated with the database page cache are tables which tracks its contents, track which objects have been locked by which application, and log file buffers.
Pages in the database cache, like objects in the object cache, can have either a "dirty" or "clean" status, which means that a page either does or does not contain objects that have been updated.
Pages are always written to their database when a session ends or a database is stopped. You can also control whether dirty pages are immediately saved to disk when a commit or direct group write occurs by enabling the server process profile parameter commit_flush.
In any case, if logging is turned on, log files automatically track all changes so that the timing of page writing does not affect database integrity.
10 фев 05, 19:35    [1314621]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

Вы лихо выкладываете ссылки, но как-то очень избирательно. Мне все-таки хотелось бы увидеть ответы на следующие вопросы:

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

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

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

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


>Здесь я достаточно четко описал все свои претезии к модели SergSuper. Если вы с ними согласны - согласитесь. Если нет, то напишете, с чем именно вы не согласны. Я согласен работать с этой моделью, но мне нужна конкретная работающая модель.

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

Уточните, что значит работающая модель? У меня Ваша модель не работает.

Так меняем постановку задачи, чтоб все было по-честному или не хотите?

>Но это не будет связью 1:N - это будет 1:1 (и никакого выигрыша в скорости ни у РСУБД ни у ООСУБД в этом случае не обнаружится - все будет одинаково).

Это будет именно 1:N. Одина запись в родительской : много записей в дочерней таблице.

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

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

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

>Согласны ли вы проанализировать выполнение именно этого запроса на именно этой модели в PostgreSQL и сравнить это с FastObjects ?

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

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

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

>План какого запроса? В реализации Подзадачи 1 для FastObjects, которую а подробно описал здесь. Нет НИКАКИХ ЗАПРОСОВ. Разумеется, я бы мог представить вам план запроса FastObjects, если бы запрос был.

Неправда, их тут аж 2 как минимум:
1) com.poet.jdo.Extents.setFilter( iter,
"WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
"and this.flight.endpoint.name = \"B\" " );
2) itm.flight.description
Вот и выкложите для них планы.

Для РСУБД программа на языке высокого уровня Вас не устраивает, Вы требуете анализа алгоритмов. В то же время выводы о превосходстве FastObjects в скорости Вы делаете исключительно на основе анализа программы на языке высокого уровня и неких загадочных рассуждениий. Анализировать алгоритмы реализации в данном случае уже не обязательно. Это правильно, нормальный демагогический прием.
10 фев 05, 23:36    [1314884]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 ALL

ИМХО отсутвие продвинутых возможностей в СКЛ-е FastObjects не может считаться само по себе недостатком, поскольку там СКЛ не есть основно средство, для них оно скорее экзотика, ибо "использование OQL-запросов в ООСУБД, хотя и поддерживается, но является плохой практикой. Действительно эффективные объектно-ориентированные приложения не должны осуществлять выборку данных по значению (во всяком, случае этого следует всячески избегать) – они должны использовать прямую навигацию, что реализуется в программах на объектно-ориентированных языках программирования (Java, C++, C#, SmallTalk ... )." (Alexey Rovdo [1285687]).

Нужна сумма - пробегут по строкам, посчитают.
10 фев 05, 23:48    [1314899]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
c127
ИМХО отсутвие продвинутых возможностей в СКЛ-е FastObjects не может считаться само по себе недостатком

Правду глаголит сей юный отрок.
Ну нету агрегатов, что ж теперь, не жить что-ли? В SQL тоже нет некоторых нужных агрегатов. Никто от этого не умер.

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

c127
Нужна сумма - пробегут по строкам, посчитают.
11 фев 05, 00:22    [1314925]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Лох Позорный

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


В Sybase ASA есть агрегатная функция конкатенации строк. LIST называется.
11 фев 05, 00:56    [1314967]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Александр Гoлдун
В Sybase ASA есть агрегатная функция конкатенации строк. LIST называется.

Возможно. А возможно где-то не только суммирование, но и среднеквадратичное по строкам можно считать.
Это я к тому, что отсутствие или наличие каких-то фич в "диалекте sql" от Versant - суть минорная проблема.
В конце концов если FO позиционируется как нечто из файл-серверной оперы - то и гори огнем все агрегаты. Или будь их хоть мульён, пофигу.
11 фев 05, 01:03    [1314970]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Лох Позорный
Александр Гoлдун
В Sybase ASA есть агрегатная функция конкатенации строк. LIST называется.

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

Там же, в ASA. Агрегатная функция STDDEV. Правда, только в том случае, если строки в числа преобразуемы
11 фев 05, 01:12    [1314976]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
c127
2 Alexey Rovdo

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

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

>Согласны ли вы проанализировать выполнение именно этого запроса на именно этой модели в PostgreSQL и сравнить это с FastObjects ?

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

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

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


Прошу прощения, опечатка.

"Операции поиска в РСУБД могут реализоваться и линейными алгоритмами."

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

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