Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 57 58 59 60 61 [62] 63 64 65 66 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
И в конечном итоге нет никаких причин делать разными методы в приложениях, работающих с одной базой данных (тем более, что есть специальные средства именно для таких случаев


Причины есть. Называется "забыли", "перепутали", "в лом было спец.средствами пользоваться" и вообще "достали эти версии" :) Если Вам это незнакомо, то Вы откуда то неотсюда....
29 мар 05, 11:48    [1422448]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Поэтому я сделаю приложение. которое будет писать в БД всякую муть - и все пройдет на ура, потому что данные в БД никак и ничем не контролируются - только кдиентским приложением, которое я сам и напишу :))


А я возьму отвертку и тыкну ей в плату компа, на котором крутится ваше "защищенное" и "контролируемое" приложение. Целостность данных в таком случае могут обеспечить только продвинутые средства журналирования и восстановления после сбоев. Являются ли по вашему мнению системами управления базами данных те программы, которые такими средствами не обеспечены (Access, MySQL и др ...)?
29 мар 05, 11:53    [1422479]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
U-gene
2 Alexey Rovdo


Или Вы хотите сказать, что объекты хранимые VERSANT'ом доступны для множества разных приложений? Например, в одном приложении создали объект и он может быть доступен для другого приложения только на основании данных полученных из хранилища объектовнапример с данными (в том числе и со схемой данных) РСУБД может работать множество разных приложений? Это можно сделать? замечу, что вопрос простой - достаточно ответа "ДА" или "НЕТ". Ответив на него, мы сразу получим ответ на вопрос, является ли Версант СУБД.


ДА, доступны

U-gene

Поймите, я не говорю что Версант - плохая система, или то, что она не нужна. ... Далее жестко поскипано, как базируещиеся на неверной предпосылке
.
29 мар 05, 11:54    [1422483]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Вы бы хоть чуточку на сайте Versant почитали. Здесь то я стараюсь не скатываться сильно на конкретику (все-таки тема ветки не только Versant посвящена). А то у вас понимание этих систем на уровне "мне кажется".

U-gene

Или Вы хотите сказать, что объекты хранимые VERSANT'ом доступны для множества разных приложений?

Доступны. Можно и из разных приложений и из разных потоков (процессов) и одновременно, и поочереди (блокировки, транзакции и все такое ... ).

U-gene

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

Да
29 мар 05, 12:01    [1422523]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Причины есть. Называется "забыли", "перепутали", "в лом было спец.средствами пользоваться" и вообще "достали эти версии" :) Если Вам это незнакомо, то Вы откуда то неотсюда....


Ну и чем это отличается от "забыли" и "перепутали" исходный код хранимой процедуры? Т.е. вот вчера он был одним, а сегодня его поменяли (например, дорабатывали в связи усложнением бизнес-логики) и случайно (недоглядели) изменился алгоритм работы и возвращаемые значения?
29 мар 05, 12:08    [1422571]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
U-gene


Причины есть. Называется "забыли", "перепутали", "в лом было спец.средствами пользоваться" и вообще "достали эти версии" :) Если Вам это незнакомо, то Вы откуда то неотсюда....



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



Такое осчусчение , что под моим "разные приложения", Вы подразумеваете "разные копии одного и того же приложения". Я говорю про разные приложения. Програмист а год назад создал приложение Х, програмист В вчера создал другое приложение У. Приложенеи Х и У работают с одной БД.

автор
U-gene


Или Вы хотите сказать, что объекты хранимые VERSANT'ом доступны для множества разных приложений?



Доступны. Можно и из разных приложений и из разных потоков (процессов) и одновременно, и поочереди (блокировки, транзакции и все такое ... ).


Объясните мне, как программа на С++ будет подгружать себе объекты созданные в другой (другой!!!) программе, ежели она описнаие этих объектов в глаза не видела. Тем mjktt что методы хранилищем не сохраняются (во сяком случае в FO :) )
29 мар 05, 12:27    [1422671]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
А я возьму отвертку и тыкну ей в плату компа, на котором крутится ваше "защищенное" и "контролируемое" приложение. Целостность данных в таком случае могут обеспечить только продвинутые средства журналирования и восстановления после сбоев. Являются ли по вашему мнению системами управления базами данных те программы, которые такими средствами не обеспечены (Access, MySQL и др ...)?

Т.е. ответить то больше нечего????? Облом?

Но даже если вы будете тыкать отверткой, данные сохранятся. Но не в этом смысл.
А смысл в том, что чтобы "испортить" данные РСУБД, вам нужен доступ к серверу и отвертка, а чтобы испортить данные ООБД, мне всего лишь нужен доступ к БД.
Неслабо!
А еще получается, что ничем ООБД не отличается от dbf.
Да и ООБД то нет на самом деле - есть отдельно хранилище данных, даже dbf, а есть отдельно клиент, который по каким-то принципам, ведомым только ему, работает с данными в тк называемом ОО стиле. Но отсюда 100% вывод - любое приложение, написанное на чем-то, поддерживающем ОО, плюс реализующее доступ к данным как к объектам - является ООБД (это по мотивам ваших выступлений так получается).

Далее.
автор
Ну и чем это отличается от "забыли" и "перепутали" исходный код хранимой процедуры? Т.е. вот вчера он был одним, а сегодня его поменяли (например, дорабатывали в связи усложнением бизнес-логики) и случайно (недоглядели) изменился алгоритм работы и возвращаемые значения?

Вы прям скоро нас уверите, что не косите под дурачка, а так и есть (извините конечно, но из песни слов не выкинешь).
Вам говорится про одно - вы про другое.
Если есть ХП - то как бы не хотел клиент, обойти логику ХП он не может.
А когда ничего нет - одни данные, клиентов 10 штук и пишут их разные люди, часть которых нихрена не понимает в логике работы с данными в конкретной системе - тогда вы будете иметь огромную жопу, которую я да и остальные не будут иметь никогда.

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

-- Tygra's --
29 мар 05, 13:17    [1422932]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Объясните мне, как программа на С++ будет подгружать себе объекты созданные в другой (другой!!!) программе, ежели она описнаие этих объектов в глаза не видела. Тем более что методы хранилищем не сохраняются (во сяком случае в FO).


1 вариант (облегченный)

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

2 вариант (тяжелый)

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

Пусть в ООБД есть объекты класса Product:

persistent class Product
{
   PtString title_;
   short year_;
   ondemand< Person > manager_;
};

Тогда в приложении мы можем добраться до них следующим образом:

// Get the Meta description of the class by name...
int err = pDictionary->Get( &pMetaType, PtString( "Product" ) );
if ( !err )
{
   // cast the meta object to the proper type...
   PtMetaPersClass * pMetaProduct = pMetaType->cast2PtMetaPersClass();

   // create an AllSet...
   PtAllSet * pAllSet = 0;
   if (pMetaProduct)
   pAllSet = pMetaProduct->MakeExtent( pDB );
   if ( pAllSet)
   {
      // read each object of type Product in the database...
      for ( long objIndex = 0; pAllSet && pAllSet->Get( pObj, objIndex, PtSTART ) == 0; objIndex++ )
      {
         // Member accessor objects for each data-member
         // in the Product class...
         PtMemberAccessor productTitleAccess( pMetaProduct, "title_" );
         PtMemberAccessor productYearAccess( pMetaProduct, "year_" );
         PtMemberAccessor productManagerAccess( pMetaProduct, "manager_" );

         // set the accessors for the particular object...
         productTitleAccess.Of( pObj );
         productYearAccess.Of( pObj );
         productManagerAccess.Of( pObj );

         // get the title_ data-member’s contents...
         PtString title;
         err = productTitleAccess.Get( title );
         if ( !err ) cout << " Title: " << title.StrGet() << endl;

         // get the year_ data-member’s contents...
         short year;
         err = productYearAccess.Get( year );
         if ( !err ) cout << " Year: " << year << endl;

         // get the manager_ data-member’s contents...
         PtOnDemand odPerson;
         err = productManagerAccess.Get( odPerson );

         // get the referenced object...
         // (you don’t need to know what type it is)
         PtObject * pObj = 0;
         if ( !err && odPerson.Get( pObj ) == 0 )
         {
            // get the meta description for the
            // referenced object (type Person)...
            PtMetaPersClass * pMetaPerson = pObj->GetMetaType();
            if ( pMetaPerson )
            {
               // set up a member accessor for a Person’s name_...
               PtMemberAccessor personNameAccess( pMetaPerson, "name_" );
               PtString name;
               personNameAccess.Of( pObj ).Get( name );
               cout << " Manager: " << name.StrGet() << endl;
            }
         }
         pAllSet->Unget( pObj );
      }
      cout << endl;
      cout << " Read " << objIndex << " object(s)." << endl;
      cout << endl;
      delete pAllSet;
   } // end if pAllSet

   else
   {
      cout << " (no AllSet)" << endl;
   }
} // end if pMetaType


Подробнее см. FastObjects™ C++ Generic Objects Programmer’s Guide.

В VDS существуют аналогичные возможности.
29 мар 05, 13:38    [1423048]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Я говорю про разные приложения. Програмист а год назад создал приложение Х, програмист В вчера создал другое приложение У. Приложенеи Х и У работают с одной БД.


Оба приложения должны опираться на одну метамодель - описание классов. Описание классов (кроме методов) хранится в БД. Т.е. приложение, опирающееся на другую метамодель либо не сможет получить доступа к данным, либо должно использовать специальные интерфейсы (предполагающие чтение хранимой метамодели), как показано выше на примере.
29 мар 05, 13:48    [1423104]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
можно более подробно об этой конструкции?
int err = pDictionary->Get( &pMetaType, PtString( "Product" ) );
if ( !err )
{
   // cast the meta object to the proper type...
   PtMetaPersClass * pMetaProduct = pMetaType->cast2PtMetaPersClass();
...
}
Дальше, рассмотрим класс
persistent class Product
{
   PtString title_;
   short year_;
   ondemand< Person > manager_;
};
Непонятно, почему атрибуты класса public, обычно они скрываются некими методами. Что будет, если добавить несколько методов?
29 мар 05, 14:40    [1423401]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Похоже, джентельмены не понимают толк в извращениях.

Так, еще раз про то что хранится в Версант:

Объекты с методами НЕ хранятся. Хранятся поля и связи с другими объектами.

Java:
Пусть будет иерархия:

Deal { [name],[ticker],[amount], [price], (Counterpart) , abstract getPnl()}
PhysicalDeal { [oil quality], ((OilCondition)), abstract getPnl()}
MultyDayPricingDeal { ((pricing days)), concrete getPnl()}

CounterPart { [name], [region]}
OilCondition{ [characteristic], [value], [measure]}

[] - обычные поля,
() - ссылки на объекты 1-1,
(()) - ссылки на объекты 1-* ,
abstract|concrete xxx() - абстрактная или реализованная функция подсчета прибыли или убытков.

Вы чешете в голове - думаете - как же это сохранять? Надо так:

Через Java доступ, в версанте:
Описываете - сначит пишете нечто похожее на CREATE TABLE

1.описываете CounterPart с полями
2.описываете OilCondition

3.описываете базовый объект Deal с полями и отношением 1-1 к Counterpart, внешний класс
4.описываете, что PhysicalDeal производный класс от Deal, имеет следующие поля ..., и отношением 1-* к OilCondition (каковой описываете как встроенный)
5. описываете MultyDayPricingDeal как производный класс от PhysicalDeal как имеющий массив полей pricing days.

Тут вдруг захотелось сохранить метод getPnl - и обнаруживаете что методы, а имеено JavaBytecode никак нельзя сохранить.

Начинаете работать и зажигать.

Тут приходят и говорят - брателлы, мы пешем ГУЙ на дотнете к этой базе. Че нам делать?

Вы показываете брателлам комманд лайн утилиту, которая из базы генерит все объекты, c полями и связями, только на языка C#. Брателлы используют их собственную .Net библиотеку чтобы сохранять и читать эти объекты, также как вы используете Java библиотеку, чтобы читать / писать Java объекты.

Уфф. Надеюсь, теперь вы сможете сами догадаться, что будет если добавить поле из Java и не обновить описание .Net классов. Будет также как в SQL при добавлении поля в таблицу: если есть триггеры мешающие вставлять в это поле null, старые приложения будут рушиться. Если нет такого тригера, то старые приложения работают на ура.

Тут брателлы обнаруживают, что метода getPnl у них нет. Очень печалятся. Пишут свой код.
29 мар 05, 15:02    [1423510]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Мимо пробегал...
Guest
автор
Тут брателлы обнаруживают, что метода getPnl у них нет. Очень печалятся. Пишут свой код.


....и делают маленькую ошибку Приехали....
29 мар 05, 15:05    [1423527]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Мимо пробегал...
автор
Тут брателлы обнаруживают, что метода getPnl у них нет. Очень печалятся. Пишут свой код.


....и делают маленькую ошибку Приехали....


Гы, гы

Щас все тоже самое Брателлы на перле наваяли нечно, тут мы на Яве наваяли свое. И что? никаких новых ошибок не пришло. Как уже сказано неоднократно, в Версанте есть триггеры/хп, но они к объектам никакого отношения не имеют
29 мар 05, 15:20    [1423590]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


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

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

Рассмотрим примеры

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

1) Предположим у нас есть таблица с полями v1, v2, v3, vAgr. В такой ситуации я безо всякого тригера наложу ограничения, которые запретят запись в поле суммы vAgr любых значений, не равных сумме полей данных (v1, v2, v3), а в поля данных - любых значений кроме тех, которые не противоречат существующему значению суммы. В результате целостность данных будет обеспечена, но приложение просто должно будет вычислять сумму самостоятельно и изменять соответствующее поле в рамках одной транзакции с изменениями полей данных.
2) Предположим теперь, что vAgr должно содержать наибольший общий делитель значений v1, v2, v3 или наименьший по модулю корень кубического уравнения, коэффициенты которого определяются значениями v1, v2, v3 или т.п.

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

Вопросы, вопросы, вопросы...

Где же та граница, за которой мы можем говорить, что вот «это» относится к целостности данных и должно отрабатываться внутри СУБД (с помощью триггеров, ХП или как-то еще), а вот «то» уже нет и имеет право быть перенесенным в приложение? По какому критерию мы относим одни правила к модели предметной области, а другие готовы признать функцией приложения?

По логике некоторых постов в этой ветке мы должны реализовать в виде хранимых процедур все. Причем реализовывать бизнес-логику в виде хранимых процедур даже правильнее, чем как-то иначе! Почему так? Что, кроме соображений быстродействия и удобства развертывания за этим стоит? Целостность данных? Но бизнес-правила могут измениться и тогда в процессе переписывания и доработки хранимых процедур целостность данных окажется под угрозой. А если обработка бизнес-правил вынесена на сервер приложений, то беспокойства по крайней мере за судьбу уже накопленных данных быть не должно. Читая посты некоторых товарищей вобще приходишь к выводу, что выделять отдельный уровень бизнес-логики в приложениях нет необходимости – за все в ответе СУБД?

Проблема распределения вычислительной нагрузки

Зачем же я задаю столько вопросов и не даю на них четких ответов? Мне кажется, что нет никаких четких критериев, по которым мы можем относить одни ограничения и правила к компетенции СУБД, а другие – к компетенции приложения. На практике все определяется задачами разделения вычислительной нагрузки и удобством разработчика. Т.е. когда разработчик хочет снять нагрузку с сервера БД, он включает вычисления и проверки в приложение, а когда ему хочется облегчить управление проектами, где множество разных приложений пишется для работы с одной базой, а нагрузка на сервер разрешена большая, он реализует многие обработки в виде хранимых процедур и триггеров. Очевидно, что в идеале мы должны иметь возможность гибко выбирать то звено приложения, на котором мы хотим исполнить наш код (проверка бизнес-правила, реакция на событие и т.п.). Т.е. вот захотели, чтобы эта процедура выполнялась на сервере приложений – поставили птичку и забыли. А эта на сервере БД – пожалуйста. На клиенте – нет проблем. В таком контексте хранимые процедуры на SQL становятся скорее тормозом, ограничивающим гибкоть приложений. Ведь не зря сейчас пошла волна встраивания в СУБД поддержки платформонезависимых языков (Java, да и .NET), выполнение кода которых можно легко перемещать между различными серверами/клиентами.

Выводы

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

Сегодня исходные тексты (или байт/IL-коды) процедур/методов, написанных на Java или языках платформы .NET в принципе можно хранить в БД. Это поддерживает Oracle (ХП на Java), Юкон (.NET), Versant Developer Suite (Java) да и любая СУБД (по большому счету нет проблем хранить исходники в БД). Но возможность переноса нагрузки пока только в незначительной мере реализуется системами с полноценными серверами приложений. Это так хотя бы потому, что реализуя всю бизнес-логику и правила обеспечения целостности в рамках сервера приложений мы можем решать, ставить ли нам сервер приложений на тот же компьютер, где у нас стоит сервер БД или на отдельный. Если же вся бизнес-логика реализована в виде ХП внутри одной БД и лежит вместе с данными, то современные РСУБД не дают нам никакого выбора – отработка этих ХП будет происходить на том же сервере.

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

vadiminfo

Про Дейта. Он безапеляционно отверг сам SQL как "искажение" реляционной модели, а вместо него вместе с Дарвеном предолжил язык D (1992). Насчет триггеров ничего не ясно из моих источников, ... А почему Вы упомянули Дейта? Ведь даже Кодд - отец РМД, но он выпустил Джина. Включились значительные интеллектальные ресурсы. Их не сбросишь со счетов. Разве та теория множеств Кантора, которую он сам создавал не называется сегодня "наивной". Хотя безусловно он отец теории множеств вообще и гений гениев. Но тысячи спецов, среди которых были и выдающиеся
не зря ведь работали. Были созданы новые разделы в математике. Она вообще приняла другой вид...


Согласен.
Я тут на досуге немного поисследовал – за что же Дейт критиковал ООСУБД в ряде своих статей. Забавный перечень:

1. Совместное использование данных приложениями
2. Физическая независимость данных
3. Непредвиденные запросы
4. Представления и логическая независимость данных
5. Независимые от приложений декларативные ограничения целостности
6. Владение данными и гибкий механизм безопасности
7. Управление многопользовательским доступом
8. Каталог общего назначения
9. Независимое от приложения проектирование базы данных

Создается впечатление, что разработчики ООСУБД последние 10 лет работали строго в направлении, указанном Дейтом, и старательно исправляли все названные недочеты. Сегодня практически по всем пунктам в ООСУБД есть соответствующая функциональность и только некоторые вызывают вопросы, причем вопросы эти носят скорее концептуальный, чем технический характер.
29 мар 05, 15:45    [1423682]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Как все тяжело то блин!!!
Клиент должен быть специальный, да еще с той метамоделью, да еще уметь ее загружать, если что.....
автор
При написании разных программ просто нужно использовать одно описание (библиотеку классов). FastObjects позволяет отслеживать конфликты и следить за тем чтобы к БД имели доступ только приложения с последней (и единственной) версией таких описаний. Т.е. вы, например, изменили описание класса и перекомпилировали приложение. После трансляции измененной структуры классов в хранилище данных, старые версии программы просто перестанут с ним работать. Это только одна из возможных схем работы.

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

автор
2 вариант (тяжелый)

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

Я тут вот чего подумал - если нам до компиляции не известна структура классов, то:
1. Как мы можем вообще разрабатывать то, чего сами не знаем в принципе
2. Как можно обращаться к объекту, если не знаешь его структуру да и вообще не знаешь. есть ли он

Отличная технология!
Вместо того, чтобы делать дела, я должен думать о совпадениях метаданных и т.п. либо исписывать мегабайты страниц кода для того, чтобы обратиться к свойству объекта (это я про приведенный пример). Какая уж тут бизнес-логика, тут хоть чего бы сделать. Не говоря уж о том, что я захочу сделать к БД веб-интерфейс - мне там нахрен объекты не нужны, я что, дурак чтоли, менять кучу клиентов из-за того, что в каком-то методе цифирь 1 на 2 поменялась?

И эти люди запрещают мне ковыряться в носу???

-- Tygra's --
29 мар 05, 15:49    [1423700]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
можно более подробно об этой конструкции?
int err = pDictionary->Get( &pMetaType, PtString( "Product" ) );
if ( !err )
{
   // cast the meta object to the proper type...
   PtMetaPersClass * pMetaProduct = pMetaType->cast2PtMetaPersClass();
...
}



А чего тут непонятного? Определили указатель pMetaProduct на метаданные класса Product. Метаданные хранятся в словаре (pDictionary - указатель на него). Словарь - это по сути отдельная ООБД. Формально база данных FastObjects состоит из Словаря и Данных. Отделение Словаря позволяет использовать одно хранилище метаданных в связке со множеством хранилищ данных.

А вообще, за подробностями обращайтесь к документации. Ссылку я дал.
29 мар 05, 15:59    [1423749]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Как все тяжело то блин!!!
Консоль должна быть специальная, да еще и знать как с ораклом соединяться, да еще показывать результаты запросов, если что.....

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

Я тут вот чего подумал - если нам до запуска SQL неизвестна структура таблиц, то:
1. Как мы можем вообще разрабатывать то, чего сами не знаем в принципе
2. Как можно обращаться к таблице, если не знаешь её структуру да и вообще не знаешь. есть ли она

Отличная технология!
Вместо того, чтобы делать дела, я должен думать о совпадениях структур таблиц и т.п. либо исписывать мегабайты страниц кода для того, чтобы обратиться к полю таблицы через системные таблицы (это я про приведенный пример). Какая уж тут бизнес-логика, тут хоть чего бы сделать. Не говоря уж о том, что я захочу сделать к БД веб-интерфейс - мне там нахрен SQL не нужен, я что, дурак чтоли, менять кучу клиентов из-за того, что в какой-то таблице поле 1 на 2 поменялось?

И эти DBA запрещают мне ковыряться в носу???

(зацените стить)
29 мар 05, 16:00    [1423754]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

Обычно вообще что-то делают только разработчики - и на клиенте и в БД
автор
1) Предположим у нас есть таблица с полями v1, v2, v3, vAgr. В такой ситуации я безо всякого тригера наложу ограничения, которые запретят запись в поле суммы vAgr любых значений, не равных сумме полей данных (v1, v2, v3), а в поля данных - любых значений кроме тех, которые не противоречат существующему значению суммы. В результате целостность данных будет обеспечена, но приложение просто должно будет вычислять сумму самостоятельно и изменять соответствующее поле в рамках одной транзакции с изменениями полей данных.
2) Предположим теперь, что vAgr должно содержать наибольший общий делитель значений v1, v2, v3 или наименьший по модулю корень кубического уравнения, коэффициенты которого определяются значениями v1, v2, v3 или т.п.

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

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

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

Абсолютно верно, за все в ответе СУБД и только она! Ну теперь то вам точно полегчало - такую тайну рассказал! :))
автор
Что, кроме соображений быстродействия и удобства развертывания за этим стоит? Целостность данных? Но бизнес-правила могут измениться и тогда в процессе переписывания и доработки хранимых процедур целостность данных окажется под угрозой

Это как так? Интересный вывод, не имеющий никаких подтверждений и пути его вывода.
автор
А если обработка бизнес-правил вынесена на сервер приложений, то беспокойства по крайней мере за судьбу уже накопленных данных быть не должно

А это то почему? Шайтан, аднака, этот сервер приложений, сам судьбу данных контролирует!
автор
Зачем же я задаю столько вопросов и не даю на них четких ответов?

Не знаете вы их, вот и не даете. Но я сжалился и подсказал их вам, я не жадный :))
автор
Мне кажется, что нет никаких четких критериев, по которым мы можем относить одни ограничения и правила к компетенции СУБД, а другие – к компетенции приложения.

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

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

В таком контексте... К доктору нужно, когда именно такие контексты возникают да еще их пытаются воплотить в жизнь.
Хочу быть владычицей морскою...!!!!
автор
Ведь не зря сейчас пошла волна встраивания в СУБД поддержки платформонезависимых языков (Java, да и .NET), выполнение кода которых можно легко перемещать между различными серверами/клиентами.

Это где про перемещение написано? Как вы себе представляете перемещение ХП, которая к примеру на .net написана, с сервера на клиента? Я что-то не могу - только фильм ужасов какой-то получается. :))
автор
Какой вывод я бы хотел сделать из всего сказанного? Вероятно очень важно хранить вместе с данными (или где-то рядом) формальные описания правил обеспечения целостности этих данных. Но вот вопрос о том, в каком звене информационной системы (клиент/сервер приложений/сервер БД/ ... ) эти правила следует отрабатывать не столь однозначен.

Какой вывод хотел бы я сделать? Да выше два раза аж повторяется: все в СУБД, что только можно. Да и что нельзя :))
автор
Сегодня исходные тексты (или байт/IL-коды) процедур/методов, написанных на Java или языках платформы .NET в принципе можно хранить в БД. Это поддерживает Oracle (ХП на Java), Юкон (.NET), Versant Developer Suite (Java) да и любая СУБД (по большому счету нет проблем хранить исходники в БД).

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

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

Вот и прекрасно! Полная независимость от логики клиента, вообще полная независимость данных и их обработки от методов доступа к ним. Это как раз то, что нам и нужно! Это самый лучший и универсальный способ для 95% систем!
автор
На мой взгляд вполне можно смотреть на связку «СУБД+сервер приложений» как на единое хранилище данных и методов и именно эту пару рассматривать, как систему, обеспечивющую непротиворечивость и целостность данных, а также как на собственно реализацию модели предметной области. И все равно это будет только некоторым приближением, поскольку и приложение тоже не является только витриной к хранящимся данным и некоторые элементы бизнес-логики иногда логичнее реализовывать именно в рамках пользовательских приложений (какие именно – решает разработчик в свете реальных требований в конкретных ситуациях).

Я вот что подумал - может вы на TSQL не умеете писать, ХП разрабатывать, вообще СУБД не знаете? Может поэтому вас тянет на сервера приложений да логику на клиенте? Признайтесь честно.
автор
1. Совместное использование данных приложениями
2. Физическая независимость данных
3. Непредвиденные запросы
4. Представления и логическая независимость данных
5. Независимые от приложений декларативные ограничения целостности
6. Владение данными и гибкий механизм безопасности
7. Управление многопользовательским доступом
8. Каталог общего назначения
9. Независимое от приложения проектирование базы данных

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

Угу, особенно п.3, 4, 7 и главное п.9.


-- Tygra's --
29 мар 05, 16:17    [1423821]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Да, это круто - поменял букву и все клиенты отвалились


Опять вынужден приводить контрпример. Поменяйте букву в названии таблицы/представления/ХП реляционной БД. Что будет с клиентами?

tygra

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


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

tygra

Я тут вот чего подумал - если нам до компиляции не известна структура классов, то:
1. Как мы можем вообще разрабатывать то, чего сами не знаем в принципе
2. Как можно обращаться к объекту, если не знаешь его структуру да и вообще не знаешь, есть ли он


Вам показали даже конкретный код.


tygra

Не говоря уж о том, что я захочу сделать к БД веб-интерфейс - мне там нахрен объекты не нужны, я что, дурак чтоли, менять кучу клиентов из-за того, что в каком-то методе цифирь 1 на 2 поменялась?


Если поменялась бизнес-логика (изменился код метода), то логично и необходимо требовать замены всех клиентов (к слову в .NET для этого есть специальные средства). Если же вы поменяли описание нехранимого класса, то замена клиентов для доступа к БД не потребуется (в принципе у вас есть некоторая свобода выбора, и я об этом писал).

Web-клиенты работают через отдельный Web-сервер (сервер приложений), а не на прямую с СУБД. В этом случае все общение с СУБД происходит именно на уровне сервера приложений и методы отрабатываются на сервере приложений. В принципе классическая трехзвенка с сервером приложений на Java или .NET очень удобно и быстро реализуется и с помощью FastObjects, и на базе ORM-продуктов Versant Open Access JDO, Versant Open Access .NET с использованием как ООСУБД VDS, FastObjects, так и множества разных РСУБД. Выше я уже отмечал, что приличная часть функциональности этих продуктов (VOA) рассчитана именно на то, что применять их будут в трех- (и более) звенных приложениях (трехзвенный кэш, кэширование блокировок, группирование запросов и т.п.). В иных случаях она просто оказывается невостребованной.
29 мар 05, 16:20    [1423832]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

-- Tygra's --
29 мар 05, 16:20    [1423834]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Опять вынужден приводить контрпример. Поменяйте букву в названии таблицы/представления/ХП реляционной БД. Что будет с клиентами?

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

А у вас не прав на это в БД Облом....
автор
Вам показали даже конкретный код.

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

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

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

Зачем? Зачем им отдельный сервер приложений? Зачем им методы? У нас веб работает с СУБД с помощью тех же ХП, что и другие возможные клиенты. И веб-клиенты отвечают только за показ на вебе - бизнес-логика не их забота.
автор
В принципе классическая трехзвенка с сервером приложений на Java или .NET очень удобно и быстро реализуется и с помощью FastObjects, и на базе ORM-продуктов Versant Open Access JDO, Versant Open Access .NET с использованием как ООСУБД VDS, FastObjects, так и множества разных РСУБД.

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

Т.е. уже 63 страницы идет речь о продуктах, которые востребованы всего в 0.1% рынка? Ё...перный театр!

-- Tygra's --
29 мар 05, 16:31    [1423893]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

У вас может и нет ответа. У остальных есть - выполнять все внутри СУБД...

Абсолютно верно, за все в ответе СУБД и только она! ...

Все, что можно сделать в СУБД - делать в СУБД...

Вообще то, СУБД как раз и служит для того, чтобы взять на себя всю возможную обработку и брать на себя всю нагрузку...

Да выше два раза аж повторяется: все в СУБД, что только можно. Да и что нельзя ...

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



Ну что же, tygra. Тогда у меня к вам один основной вопрос:

Что такое "внутри СУБД" и что такое "снаружи СУБД"?

И несколько подвопросиков:

Расширенная хранимка это внутри?
Хранимка на Java, выполняемая на удаленной или локальной (зависит от настроек) JVM - это внутри или снаружи?
Две связанные БД (через Linked Server) по отношению друг к другу снаружи ?
Если из БД извлекается хранящийся в ней байт-код Java и исполняется на сервере приложений, то чем это принципиально отличается от исполнения хранимки на Java "внутри" СУБД?
Есть ли для вас разница между терминами ХРАНЕНИЕ ДАННЫХ и ОБРАБОТКА ДАННЫХ?
Запуск из приложения хранимой процедуры и запуск SQL-скрипта, дублирующего код этой процедуры чем-то отличаются (желательно в терминах "внутри"/"снаружи"?
29 мар 05, 16:40    [1423938]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

-- Tygra's --
29 мар 05, 16:42    [1423953]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

А у вас не прав на это в БД Облом....


А у вас нет прав на изменение хранимых в ООБД метаданных (описаний классов). Полная аналогия. Так что хватит выпендриваться.

tygra

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


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

tygra

А если хранимого? А как это так - нехранимого?


Объекты сохраняемых классов и их метаданные (описания) хранятся в БД.
Несохраняемые классы и объекты таких классов присутствуют только в приложении и в БД попасть не могут.

tygra

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


tygra, я здесь не пытаюсь доказать необходимость серверов приложений. Я лишь придерживаюсь той позиции, что между серверами приложений и ХП (в том виде, как они реализованы в популярных коммерческих СУБД) нет никакой фундаментальной разницы. Есть только вопросы реализации и удобства развертывания тех или иных продуктов. Но с точки зрения приложения (и любой теории баз данных) - совершенно по барабану - вызывает оно ХП в СУБД или обращается к методам/сервисам на сервере приложений (тем более, что физически он может располагаться на том же компьютере, что и СУБД).

tygra

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

Т.е. уже 63 страницы идет речь о продуктах, которые востребованы всего в 0.1% рынка? Ё...перный театр!


Вам очень нравится не замечать написанного (... часть функциональности этих продуктов (VOA) рассчитана ...)? Или вы считаете, что, например, в типовой конфигурации Oracle вся функциональность рассчитана на двухзвенку?
29 мар 05, 17:00    [1424036]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
tygra
2 Dimonische

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

-- Tygra's --


Тигра, вы, возможно правы, но мой работатодатель (что для меня намного важнее) с вами не согласен.

По поводу запихивания всего в базу, задумайтесь, зачем существуют апп-сервера, и почему это гигантский рынок. Наверняка он состоит не из полных идиотов . Просто вы не знаете что это такое - апп.сервера.
Не знаете ни J2EE, ни COM+ и пр. Я знаю базы на уровне ессно не ДБА, но каждый день работаю с Ораклом и нашим ДВА. Вы же не знаете вообще ничего про апп-сервере. Ни что они делают, ни про стандарты. Т.е. абсолютно ничего не знаете. Может, стоит узнать?
29 мар 05, 17:08    [1424073]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 57 58 59 60 61 [62] 63 64 65 66 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить