Здравствуйте, Merle, Вы писали:

M>Ну это-то вряд-ли , скорее причина в другом.
M>В чем именно станет известно после того, как появится документация на 10G. Но в целом, похоже, причина кроется в том, что в tpc-c тесте уже используются 64 процессорные машины,

Думаю не станет, у меня складывается ощущение, что проблема у Oracle 8-9 была в элементарном баге,
который они внесли в 8.0 и умудрились не замечать до выхода 10-ки, так что в этом они врят ли признаются.
Суть в том, что ошибка ORA-8177 (cannot serialize access for this transaction) в этих версиях возникает
не только когда положено, но и в некоторых других случаях (even though there is no DML on the tables
being queried.) (Bug 2728408 на металинке).
Т.е. откат и перезапуск транзакций по ORA-8177 при выполнении теста tpc-c вероятно происходил чаще чем нужно.
Это конечно догадки, но никаких изменений в механизме Concurency Control Oracle не объявлял, да и на 64-разрядной плотформе и восьмерка и девятка умели крутится, не думаю что в этом сумели сделать какой то прорыв.

Bug 2728408 False ORA-8177 possible SELECTING data with SERIALIZABLE
This note gives a brief overview of bug 2728408.
Affects:
Product (Component) Oracle Server (RDBMS)
Range of versions believed to be affected Versions >= 8.0 but < 10G
Versions confirmed as being affected 8.1.7.4 9.2.0.3
Platforms affected Generic (all / most platforms affected)
Fixed:
This issue is fixed in 9.2.0.4 (Server Patch Set) 10G Production Base Release
Symptoms:
* Error may occur <javascript:taghelp('TAGS_ERROR')>
* ORA-8177
Related To:
* (None Specified)
Description
Concurrent selects may get ORA-8177 (cannot serialize access
for this transaction) even though there is no DML on the tables
being queried.

Здравствуйте, KisA, Вы писали:

KA>Думаю не станет, у меня складывается ощущение, что проблема у Oracle 8-9 была в элементарном баге, который они внесли в 8.0 и умудрились не замечать до выхода 10-ки, так что в этом они врят ли признаются.
Не, баг действительно не самый крупный, к тому же там и другие есть, которые, правда, наоборот улучшают результаты тестов..
Я думаю, что они довольно давно о нем знали, и в тестах вполне удачно обходили, но исправление подобных вещей — это серьезное копание внутри ядра и в лет тут не поправишь.

KA>Суть в том, что ошибка ORA-8177 (cannot serialize access for this transaction) в этих версиях возникает не только когда положено, но и в некоторых других случаях (even though there is no DML on the tables being queried.)
Да, я знаю. О нем еще Sergey Ten писал некоторое время назад.
Видимо это следствие того, что версионность в Оракле на уровне страниц данных, и информация о версиях конкретных записей может быть утеряна. В этом случае, чтобы избежать некорректного поведения, Оракл решает перебдеть и откатывает транзакцию.

KA>Это конечно догадки, но никаких изменений в механизме Concurency Control Oracle не объявлял
Ну там действительно, скорее всего только баги поправили. Но про изменения в storage engine они все-таки писали, и думаю, что не с проста.

KA> да и на 64-разрядной плотформе и восьмерка и девятка умели крутится, не думаю что в этом сумели сделать какой то прорыв.
Умели, но не очень шустро, опять же и MSSQL2000, вполне на 64-разрядной машине крутился.
Но у MS еще проблема в том, что им и ОС надо под 64-разряда переписывать. А в распоряжении Оракла есть опыт написания аналогичных систем под спарки и проверенные 64-разрядные юниксы.
Так что прорыва никакого действительно не сделали, а просто удачно применили свой опыт в разработке софта под такие системы.

я сдаюсь ! да Мерле вы меня убедили — ваши доводы информативны и бесспорны (Как хорошо показывает практика), а аргументы убедительны (нет ответа — топик переносится) и подверждены ссылками на тесты и компетентные источники. мне нечем крыть (матом не дают, посты исчезают)

вы открыли мне глаза — блогодоря вашему опыту я узнал, что T-SQL не предназначен для бизнес-логики, джава не чать бд, DMO — это аналог Оракловской Явы и даже круче, а сервер малых рабочих групп оракл нервно курит когда на сцену выходит сиквел ...

Gt_

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> На самом деле это даже саме то, т.к. хранить объект в сериализованном виде неоптимально, да и с точки зрения хранения данных и модификации
M>С точки зрения хранения как раз очень оптимально...


M>>>Что есть в данном случае inline?
S>> В С есть понятие инлайн, когда всесто вызова процедуры подставляется ее код, тем самым сокращая время вызова метода.
M>Да что это такое inline в С — я знаю, что есть инлайн в данном случае? Я так понимаю, ты хочешь подставлять уже посчитанное значение, но так не всегда можно сделать.

Давай разбирать типичный SQL проход по записям с выставлением блокировок или сравнением версий. Для этого нужен один объект для навигации для объектов наследуемых от одного базового класса. Он же будет выбирать индекс выборки , считывать данные, в объект и накладывать блокировки если нужно или возложить эту обязанность на сам объект. Внутри этих объектов будет творится очень много действий, но выглядеть это будет как обычный объект
M>Давай считать так, если у нас константа, значит мы можем построить какой угодно индекс и добраться по бырому, но несли нет, то фиг ты чего построишь.

Опять же. Сначало нужно плясать от форматов хранения данных. Константа может представлять собой некую запись в таблице или Блоб данные. Можно абстракто описать модель, но она должна базироваться уже на какойто модели хранения данных

S>> Не совсем так, все зависит от алгоритма,
M>Фокус в том, что ты не знаешь алгоритм.. Ясен хобот, что когда алгоритм известен можно просто с бешенной силой все прооптимизировать. Но в общем случае алгоритм не известен, он скрыт внутри объекта и кроме объекта о нем никто не знает. Его там может вообще не быть, это может быть константа, но об этом никто, кроме самого объекта даже не догадывается.

Тогда это плохо продуманный объект. Всегда можно и нужно на этапе разработки продумать все возможные алгоритмы выборки (не так их уж и много) но уже дальше плясать только от них.
S>> Я выше объяснял, что объекты хранить не нужно, только его данные, это несколько другой подход, но все же ОО.
M>Если понимать под данными приватные поля, то это уже не ОО. А если результаты вызовов методов, то нет гарантии, что они актуальны.
Выше объснял, что доступ осуществляется через свойства, которые должны гарантировать актуальность результатов.

Здравствуйте, aston, Вы писали:

TK>>Вопрос. Какой смысл вкладывается в слова "Переключение контекста" (в контексте данного обсуждения конечно)?

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

Тут главное — без дополнителоных движений со стороны кого.
Например, если движок БД написан на java, и из него вызывается хранимая процедура на той-же java (все в рамках одной JVM), то тут да — никакого переключения контекста нет. А вот если движок БД написан в native коде какого-то конкретного процессора (оптимизации там и т.п), то тут без переключения контекстов не обойтись (например теже строки — в java это объект, подчиняются требованиям GC и т.п., а как эта строка может физически представляться в БД, это как бог на душу положит — скорее всего хранение из соображений оптимальности).

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

A>В гипотетическом C/SQL это могло бы выглядеть так:

Microsoft это делала еще в чертикаком лохматом году. Вот реальный код:

main()
{
   EXEC SQL INCLUDE SQLCA;
   EXEC SQL BEGIN DECLARE SECTION;
      int OrderID;         /* Employee ID (from user)         */
      int CustID;            /* Retrieved customer ID         */
      char SalesPerson[10]   /* Retrieved salesperson name      */
      char Status[6]         /* Retrieved order status        */
   EXEC SQL END DECLARE SECTION;

   /* Set up error processing */
   EXEC SQL WHENEVER SQLERROR GOTO query_error;
   EXEC SQL WHENEVER NOT FOUND GOTO bad_number;

   /* Prompt the user for order number */
   printf ("Enter order number: ");
   scanf ("%d", &OrderID);

   /* Execute the SQL query */
   EXEC SQL SELECT CustID, SalesPerson, Status
      FROM Orders
      WHERE OrderID = :OrderID
      INTO :CustID, :SalesPerson, :Status;

   /* Display the results */
   printf ("Customer number:  %d\n", CustID);
   printf ("Salesperson: %s\n", SalesPerson);
   printf ("Status: %s\n", Status);
   exit();

query_error:
   printf ("SQL error: %ld\n", sqlca->sqlcode);
   exit();

bad_number:
   printf ("Invalid order number.\n");
   exit();
}

Здравствуйте, Serginio1, Вы писали:

S> Давай разбирать типичный SQL проход по записям с выставлением блокировок или сравнением версий. Для этого нужен один объект для навигации для объектов наследуемых от одного базового класса. Он же будет выбирать индекс выборки , считывать данные, в объект и накладывать блокировки если нужно или возложить эту обязанность на сам объект. Внутри этих объектов будет творится очень много действий, но выглядеть это будет как обычный объект
Бррррр, к чему все это?
Механика хранения и доставания, на этом этапе, не имеет никакого смысла, давай плясать от свойств объекта.

S> Опять же. Сначало нужно плясать от форматов хранения данных. Константа может представлять собой некую запись в таблице или Блоб данные.
Зачем? Формат в общем случае не важен. Константа — она и в африке константа.

S> Можно абстракто описать модель, но она должна базироваться уже на какойто модели хранения данных
Да не нужна пока никакая модель. Пусть в первом приближении модель будет такая, как нам удобно. Как именно это будет храниться и как доставаться не важно абсолютно.

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

S> Выше объснял, что доступ осуществляется через свойства, которые должны гарантировать актуальность результатов.
За счет чего? Есть Get, есть Set. Допустим результат Get мы запомнили. Потом вызвали Set, и результат вызова Get будет другой, как база узнает, что Get поменялся? Даже объект знает, что поменялись лишь приватные поля, а вызовы каких методов при этом изменились — не известно.

Здравствуйте, Merle, Вы писали:

S>> Выше объснял, что доступ осуществляется через свойства, которые должны гарантировать актуальность результатов.
M>За счет чего? Есть Get, есть Set. Допустим результат Get мы запомнили. Потом вызвали Set, и результат вызова Get будет другой, как база узнает, что Get поменялся? Даже объект знает, что поменялись лишь приватные поля, а вызовы каких методов при этом изменились — не известно.
Вот как раз в вызовах Get и Set все взаимодействия с БД и прописываются, а не только простой доступ к полям.Так же как это делает SQL за счет блокироврк итд

Здравствуйте, Serginio1, Вы писали:

S> Вот как раз в вызовах Get и Set все взаимодействия с БД и прописываются, а не только простой доступ к полям.
Кем прописывается, разработчиком? Это получается реализация БД в рукопашную, кому это надо?. К тому же в этих методах еще и считать приходится. Проще как сейчас, в ручную распихать по табличкам, а потом собрать — так реляционный движек на себя всю рутину возьмет.
В идеале разработчик ничего не должен знать о том как, где, и за счет чего объект будет храниться. Максимум в нужных местах вызывается метод типа .Persist() и все, на этом ручное взаимодействие с базой заканчивается.

S> Так же как это делает SQL за счет блокироврк итд
Только у SQL'я для этих блокировок куча полезных вещей имеется и центральный менеджер, который все разруливает, а что в замен?

Здравствуйте, Аноним, Вы писали:

А>я сдаюсь !
Уважаю людей, которые открыто признают свои ошибки.

А>да Мерле вы меня убедили — ваши доводы информативны и бесспорны (Как хорошо показывает практика)
Угу, оценки сообщений, как правило, с достаточной степенью достоверности отражают мнение аудитории. Так что Ваша правда.

А> а аргументы убедительны
И тут нечего возразить, мы с Вами сегодня на удивление солидарны..

А>(нет ответа — топик переносится)
Честное слово это не я. Зарегистрированным пользователям, на сайте доступна так называемая "автомодерилка". Пользователи могут проголосовать за перенос того или иного топика в другой форум, если в текущем он им кажется оффтопиком. И если суммарный рейтинг проголосовавших за перенос выше какого-то порога, то топик переносится автоматически, без участия модератора, что и произошло в данном случае.
Я, честно говоря, хотел бы часть сообщений вернуть обратно, но поскольку в этом форуме я не модератор, то придется просить команду.

А> и подверждены ссылками на тесты и компетентные источники.
Безусловно, рад, что Вы наконец-то это признали.

А>(матом не дают, посты исчезают)
Естественно, это запрещено правилами сайта. Более того, это так же грозит закрытием доступа на сайт.

Вообще, если есть какие-то претензии к модерированию, то Вы всегда можете послать сообщение на moderator@rsdn.ru, с описанием сути Вашего недовольства. Нас около 20 человек, активных членов RSDN Team, и если команда признает, что в отношении Вас была совершена некая несправедливость, то перед Вами непременно извинятся, восстановят в правах и вернут все сообщение на надлежащие по Вашему мнению места.

А>вы открыли мне глаза
Всегда рад.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, theOne, Вы писали:

O>>Не вижу какая трудность по сохранению объектов и извлечению таковых?
M>Нууу.. В твоем примере нет
M>1. Наследования
M>2. Инкапсуляции
M>3. Полиморфизма
M>То есть, с точки зрения ООП, здесь и не объекты вовсе, а структуры. Я уже не говорю о виртуальных методах и прочих тонких материях.

Не буду спорить с тобой, поскольку ты прав, я же хотел контекстно намекнуть, что Оракл пытается сделать и что у него начинает появляться подобие хранения объектов, знаю что много еще надо сделать — даже одно из простейших: после создания CREATE TABLE .. OF sometype изменить или удалить тип при существующей таблице ну никак нельзя, но я не о этом. Просто по времени, пока microsoft будет делать что-то новое, то Оракл может уже сделает что-нибудь с поддержкой объектов.

Хотя мне все это по барабану. Поскольку в настоящее время меня MSSQL Server устраивает и хорошо, что он прост как две копейки. Если, что и просят сделать я громогласно заявляю: "Это же MSSQL!". Так, что в этом отношении все ОК.

Здравствуйте, theOne, Вы писали:

O> Просто по времени, пока microsoft будет делать что-то новое, то Оракл может уже сделает что-нибудь с поддержкой объектов.
Что-то меня очень большие сомнения по этому поводу одолевают...
Пожалуй единственное, что меня действительно серьезно не устраивает в Оракле, так это то, что он уже довольно долгое время вообще не развивается. Если MS свой сервер развивает очень активно, то Оракл вкладывает больше денег в маркетинг, нежели в саму БД. Ядру сервера уже около десяти лет, но ничего принципиально нового в нем с тех пор не появилось и не менялось. Такое впечатление, что Оракл расслабился и решил, что он всегда будет лучшим, ничего для этого не предпринимая, причем это длится уже довольно давно. Возможно, что Оракл и займется принципиальными переделками, но неизвестно, что из этого получится и оптимизьма по этому поводу у меня нет .

Здравствуйте, Vasiliy_Krasnokutsky, Вы писали:

V_K>Добрый день,
V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql.
V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных.
V_K>Желательно бы ссылки на статьи или книги.

V_K>Заранее благодарен, Краснокутский Василий

В одном из прошлых проектов использовали Oracle + .Net. Была проблема — в oraclt полностью отсутствовал механизм распределенных транзакций. Это не позволило использовать COM+...
Возможно с тех пор проблему решили, я не интересовался...

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Вот как раз в вызовах Get и Set все взаимодействия с БД и прописываются, а не только простой доступ к полям.
M>Кем прописывается, разработчиком? Это получается реализация БД в рукопашную, кому это надо?. К тому же в этих методах еще и считать приходится. Проще как сейчас, в ручную распихать по табличкам, а потом собрать — так реляционный движек на себя всю рутину возьмет.
M>В идеале разработчик ничего не должен знать о том как, где, и за счет чего объект будет храниться. Максимум в нужных местах вызывается метод типа .Persist() и все, на этом ручное взаимодействие с базой заканчивается.

S>> Так же как это делает SQL за счет блокироврк итд
M>Только у SQL'я для этих блокировок куча полезных вещей имеется и центральный менеджер, который все разруливает, а что в замен?

А в замен, все эти механизмы должны быть в самой БД встроены, что по сути не так и сложно. Тот же центральный менеджер может выполнять ту же работу только на объектном уровне. И какая разница разбирать SQL запрос или Некий алгоритм написанный с применением объектов ???? Во всяком случае для локальных БД это все легко прописывается автоматом. А SQL еще сидит на уровне 70 годов.
А те подвижки которые есть в Юкон нельзя назвать революционными. А вот пример SQLJ мне очень понравился.

Здравствуйте, Serginio1, Вы писали:

S> А в замен, все эти механизмы должны быть в самой БД встроены, что по сути не так и сложно. Тот же центральный менеджер может выполнять ту же работу только на объектном уровне.
Да в том-то и дело, что невозможно выполнять ту же работу на объектном уровне, с той же эффективностью. Причем производительность падает в разы, почему — см. топики выше.

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

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

S> А SQL еще сидит на уровне 70 годов.
А почему так, никогда не задумывался? До тех пор, пока хранилище само по себе реляционное, все самые эффективные способы работы с этим хранилищем будут оставаться реляционными.
Причем производительность здесь очень критичный параметр. Если в обычной программе падение производительности на 10-20% пользователь и не заметит, то в БД это не так.
По этому поводу приводился очень хороший пример: Если OLAP куб перестраивается с ноля часов до семи утра, то недостаток перфоманса выливается в неуспевчик к началу рабочего дня. И банальной железкой помощнее тут не отделаешься.

S> А те подвижки которые есть в Юкон нельзя назвать революционными.
А ничего революционного никто не обещал.

S>А вот пример SQLJ мне очень понравился.
Тот же SQL, только в профиль. То, что раньше делалось на клиенте или в среднем звене — теперь делается на сервере, но реляционная суть не изменилась. Те же реляционные запросы к хранилищу, опять-таки ничего революционного.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> А в замен, все эти механизмы должны быть в самой БД встроены, что по сути не так и сложно. Тот же центральный менеджер может выполнять ту же работу только на объектном уровне.
M>Да в том-то и дело, что невозможно выполнять ту же работу на объектном уровне, с той же эффективностью. Причем производительность падает в разы, почему — см. топики выше.
Интересно на локальных базах можно а на SQL нельзя??? Если туже таблицу рассматривать как коллекцию данных объекта являющимся одним их его его полей(а не объектов как таковых), то все прекрасно описывается не нужна никакая сериализация, т.к. запись просто считывается в объект итд.
И никаких потерь (запись можно и не считывать а держать ссылку на нее)

S>>И какая разница разбирать SQL запрос или Некий алгоритм написанный с применением объектов ????
M>Разобрать — не проблема, проблема в том, что объект надо достать, а чтобы определить нужный ли он — необходимо вызвать метод этого объекта, что убивает производительность напроч.
Интересно, насколько вышеописанный подход убьет все напрочь ?????
S>>Во всяком случае для локальных БД это все легко прописывается автоматом.
M>Агащазблин. Автоматом это прописывается, если ты пишешь БД под конкретную систему, а если нет, опять-таки см. выше. К тому же локальные БД сейчас мало кого интересуют.
С точки зрения хранилища данных чем SQL отличается от любой локальной БД????
S>> А SQL еще сидит на уровне 70 годов.
M>А почему так, никогда не задумывался? До тех пор, пока хранилище само по себе реляционное, все самые эффективные способы работы с этим хранилищем будут оставаться реляционными.
M>Причем производительность здесь очень критичный параметр. Если в обычной программе падение производительности на 10-20% пользователь и не заметит, то в БД это не так.
M>По этому поводу приводился очень хороший пример: Если OLAP куб перестраивается с ноля часов до семи утра, то недостаток перфоманса выливается в неуспевчик к началу рабочего дня. И банальной железкой помощнее тут не отделаешься.
Во во а может алгоритмы пересмотреть, если конечно речь не идет о миллиардах записей. На самом деле очень много поменялось с того времени особенно в железе и нужно применять другие подходы.
S>> А те подвижки которые есть в Юкон нельзя назвать революционными.
M>А ничего революционного никто не обещал.

S>>А вот пример SQLJ мне очень понравился.
M>Тот же SQL, только в профиль. То, что раньше делалось на клиенте или в среднем звене — теперь делается на сервере, но реляционная суть не изменилась. Те же реляционные запросы к хранилищу, опять-таки ничего революционного.

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

Здравствуйте, Serginio1, Вы писали:

S> Интересно на локальных базах можно а на SQL нельзя???
Да и на локальных-то не особо льзя.

S>Если туже таблицу рассматривать как коллекцию данных объекта являющимся одним их его его полей(а не объектов как таковых), то все прекрасно описывается не нужна никакая сериализация, т.к. запись просто считывается в объект итд.
Объект — это не только набор полей. Набор полей — это структура, а объект обладает поведением. И пока не вызовешь метод объекта, что означает набор полей объекта — неизвестно.

S> И никаких потерь (запись можно и не считывать а держать ссылку на нее)
Где держать?

S> Интересно, насколько вышеописанный подход убьет все напрочь ?????
Именно напрочь, вплоть до полной неприменимости в практических задачах.

S> С точки зрения хранилища данных чем SQL отличается от любой локальной БД????
С той, что в клиент-сервере приходится разруливать многопользовательский доступ.

S> Во во а может алгоритмы пересмотреть, если конечно речь не идет о миллиардах записей.
Думаешь OLAP/OLTP системы полные идиоты разрабатывают?
Они над эффективными алгоритмами круглыми сутками головы ломают, и уж в таких системах все вылизано до невозможного состояния.

S>На самом деле очень много поменялось с того времени особенно в железе и нужно применять другие подходы.
На самом деле — не так много как ты думаешь...


S> Не скажи. Применение объектных запросов это уже новая высокоуровневая абстракция,
Да нет там объектных запросов. Сам запрос все равно реляционный, хотя и используется из объекта напрямую..

S> Премущество SQL в краткой записи алгоритма, который затем разбрасывается на элементарные куски,
Преимущество SQL не в этом.
Дело в том, что на данный момент не существует универсального, более-менее эффективного алгоритма отображения любого объекта на реляционную структуру. И пока такового не появится придется работать руками с SQL'ем.

S> а для объектного подхода нужно разрабатывать свой синтаксис.
Он уже давно разработан, читай ODMG (OQL — Object Query Lang..)


S> Только в SQL этого еще очень долго не будет.
Да SQL'ю это и не нужно... С точки зрения объектов SQL — это костыли. Если появится нормальная OODBMS, то об SQL все забудут, как о страшном сне...

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Интересно на локальных базах можно а на SQL нельзя???
M>Да и на локальных-то не особо льзя.

S>>Если туже таблицу рассматривать как коллекцию данных объекта являющимся одним их его его полей(а не объектов как таковых), то все прекрасно описывается не нужна никакая сериализация, т.к. запись просто считывается в объект итд.
M>Объект — это не только набор полей. Набор полей — это структура, а объект обладает поведением. И пока не вызовешь метод объекта, что означает набор полей объекта — неизвестно.

Объект Это экземпляр класса, единственное его отличие от структуры (в C++ вообще нет разницы, а в Net нет наследование и может быть только в стеке или как поле объекта или элементом массива) это ссылка на VMT или некий ID по которому в некой хэш таблице можно найти адрес VMT данного типа. Все манипуляции с этой структурой идут на основании типа. А из этого следует что если тип известен, то и нет проблем манипулирования с ним. В Net часто приходится использовать массивы структур, для отказа от работы с объектами для ускорения работы и все механизмы БД там присутствуют, только вместо ссылок применяются структура
массив и индекс в массиве по которому получаем доступ к подчиненной записи.

S>> И никаких потерь (запись можно и не считывать а держать ссылку на нее)
M>Где держать?
Давай так. Таблица представляет собой коллекцию данных данных объекта. Можно работать считывая данные в поле или поле будет держать ссылку на запись в памяти. Организация работы с данными в SQL состоит в загрузке страниц в память.
S>> Интересно, насколько вышеописанный подход убьет все напрочь ?????
M>Именно напрочь, вплоть до полной неприменимости в практических задачах.
Ну это не доказуемый спор.
S>> С точки зрения хранилища данных чем SQL отличается от любой локальной БД????
M>С той, что в клиент-сервере приходится разруливать многопользовательский доступ.
А на Локальной БД не надо. Тем более речь идет о хранилище данных а не надстройкой над ней. И если я сделаю Свою клиент серверную надстройку над локальной БД с разруливанием многопользовательского доступа на сервере с транзакциями итд то она будет называться SQL ????
S>> Во во а может алгоритмы пересмотреть, если конечно речь не идет о миллиардах записей.
M>Думаешь OLAP/OLTP системы полные идиоты разрабатывают?
M>Они над эффективными алгоритмами круглыми сутками головы ломают, и уж в таких системах все вылизано до невозможного состояния.
О каких объемах идет речь как в записях так и байтах. Очень интересно смоделировать данную задачу но только ручками с применением других алгоритмов.



S>> Не скажи. Применение объектных запросов это уже новая высокоуровневая абстракция,
M>Да нет там объектных запросов. Сам запрос все равно реляционный, хотя и используется из объекта напрямую..

Ну а как ты хотел. На уровне ассемблера ООП тоже не пахнет
S>> Премущество SQL в краткой записи алгоритма, который затем разбрасывается на элементарные куски,
M>Преимущество SQL не в этом.
M>Дело в том, что на данный момент не существует универсального, более-менее эффективного алгоритма отображения любого объекта на реляционную структуру. И пока такового не появится придется работать руками с SQL'ем.
Да я уже сколько только и пишу, что ОО на РБД легко реализуется, единственно возникают проблемы когда полем объекта является неопределенный объект содержащее поле тип
struct НеопределенныйОбъект
{ int TypeID;// тип объекта а значит и таблицы где хранятся его данные
int ID;
}

А вот разбираться с этим простым запросом достаточно проблематично.
S>> а для объектного подхода нужно разрабатывать свой синтаксис.
M>Он уже давно разработан, читай ODMG (OQL — Object Query Lang..)
К чему толь его применить????


S>> Только в SQL этого еще очень долго не будет.
M>Да SQL'ю это и не нужно... С точки зрения объектов SQL — это костыли. Если появится нормальная OODBMS, то об SQL все забудут, как о страшном сне...

Здравствуйте, Serginio1, Вы писали:

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

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

S> А на Локальной БД не надо. Тем более речь идет о хранилище данных а не надстройкой над ней. И если я сделаю Свою клиент серверную надстройку над локальной БД с разруливанием многопользовательского доступа на сервере с транзакциями итд то она будет называться SQL ????
Она будет называться "клиент-серверная надстройка". Не надо никаких надстроек.
В обязанности реляционной БД входит разруливание многопользовательского доступа.

S> О каких объемах идет речь как в записях так и байтах. Очень интересно смоделировать данную задачу но только ручками с применением других алгоритмов.
В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу.

S> Ну а как ты хотел. На уровне ассемблера ООП тоже не пахнет
Но из C'шных объектов в ассемблер переводит компилятор, а тут все равно пишешь руками реляционные запросы.

S> Да я уже сколько только и пишу, что ОО на РБД легко реализуется,
Ну а я тебе пишу, что легко реализуется хранилище под конкретную систему, без большой конкурирующей нагрузки, а универсально — нет. Да и это "легко" — достаточно условно.

S> К чему толь его применить????
А это уже другой вопрос.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

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

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

S>> А на Локальной БД не надо. Тем более речь идет о хранилище данных а не надстройкой над ней. И если я сделаю Свою клиент серверную надстройку над локальной БД с разруливанием многопользовательского доступа на сервере с транзакциями итд то она будет называться SQL ????
M>Она будет называться "клиент-серверная надстройка". Не надо никаких надстроек.
M>В обязанности реляционной БД входит разруливание многопользовательского доступа.
На уровне Файл сервера с блокировками на уровне файла или Клиент сервера на абсолютно другом уровне с применением критических секций итд. Разница очень большая.
S>> О каких объемах идет речь как в записях так и байтах. Очень интересно смоделировать данную задачу но только ручками с применением других алгоритмов.
M>В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу.
Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек. А учитывая Кэши Raid массивов и их пропускной способности уложится в часы нужно сильно постараться.
S>> Ну а как ты хотел. На уровне ассемблера ООП тоже не пахнет
M>Но из C'шных объектов в ассемблер переводит компилятор, а тут все равно пишешь руками реляционные запросы.
А запрос куда переводится???? Теже Б деревья, Хэш таблицы итд наверное компилируются, иначе скорость выполнения запроса была бы как на Аксессе. В данном случае можно говорить о неком компилируемом языке, использующий оптимизатор запросов и статистику. Кстати данный подход применяется и в Net и Java.

S>> Да я уже сколько только и пишу, что ОО на РБД легко реализуется,
M>Ну а я тебе пишу, что легко реализуется хранилище под конкретную систему, без большой конкурирующей нагрузки, а универсально — нет. Да и это "легко" — достаточно условно.
Универсальную можно только на уровне SQL и ооочень примитвного использования ОО.
А может системы аля 1С только на уровне Сервера применимы ???? Не даром у M$ большие планы в данном направлении. Поживем увидим. Все равно ничего не остается делать, и копаться в Юкон.

Здравствуйте, Serginio1, Вы писали:

S> На уровне Файл сервера с блокировками на уровне файла или Клиент сервера на абсолютно другом уровне с применением критических секций итд. Разница очень большая.
Да какая разница на каком уровне, ты опять залез в конкретную реализацию. Просто по определению, чтобы иметь право называться СУБД система должна уметь разруливать параллельный доступ к данным.

M>>В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу.
S> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек. А учитывая Кэши Raid массивов и их пропускной способности уложится в часы нужно сильно постараться.
Ты хорошо себе представляешь, что такое OLAP и каким образом там кубы считаются? Это не массив int'ов, проиндексированый. Там очень большая избыточность, куб формируется из относительно небольшой OLTP системы, таким образом, чтобы последующие запросы к нему не требовали практически никаких объединений. И этот процесс занимает несколько часов. Зато когда на утро приходят клиенты и манагеры, запросы на чтение по такой системе летают не за 10 сек, а гораздо меньше.

S> А запрос куда переводится???? Теже Б деревья, Хэш таблицы итд наверное компилируются, иначе скорость выполнения запроса была бы как на Аксессе.
Компиляция запроса занимает вообще смешное время, дороже всего обходится расчет оптимального плана выполнения, поэтому планы кешируются.

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