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

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

Хорошо, хорошо, пусть с натяжкой можно сказать, что апп-сервера где-то и как-то почти похожи на ХП, сделаем вид, что это так :))


Уфф...

tygra

Но вопрос то остается: зачем в общем случае нужен апп-сервер?


А в общем случае он, полагаю, и не нужен. Т.е. я, к примеру, вообще считаю это делом вкуса и пристрастий разработчика/заказчика/начальника и ввязываться в спор о ВКУСАХ - боже упаси.

Другое дело, что особенности отдельных систем (например, FastObjects t7/.NET, MySQL, SapDB ... ) иногда делают более практичным их использование именно в паре с апп-сервером, а не как самостоятельного и самодостаточного хранилища. Иногда это вопрос пристрастий и элементарного удобства, а иногда - когда модель предметной области такова, что ее просто нельзя корректно запихнуть в базу, - это уже обязательное требование, обусловленное именно фундаментальным требованием обеспечения единого места хранения данных и бизнес-правил, обеспечивающих эту целостность (размазывать бизнес-правила по клиентским приложениям будет ошибкой). Т.е. СУБД+апп-сервер - единственный способ удовлетворить этим фундаментальным требованиям (еще раз акцентирую внимание на том, что такое требование может возникнуть как результат усложнения самой предметной области).
30 мар 05, 16:31    [1427536]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Зачем нужен сервер приложений?

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

Зачем нужен такой код?

На сегодняшний момент есть куча задач которые не удобно/не возможно решать на сервере БД.

А я считаю что обработка должна происходить там же где и данные...

Да, как можно ближе, правда если у вас есть выбор
30 мар 05, 16:37    [1427583]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

автор
2. Один слой - .NET-клиент обращается сразу к методу Web-сервиса, ему плевать на то, что внутри, он просто говорит (C#) obj1 = webservice.GetObject(parameter); - и ... все. Клиент - кто угодно.


Два слоя все же - про БД забыли :) А еще же IIS есть - тоже слой :)


Но я же не пытаюсь считать слои при обращении к серверу БД через ADO .NET (там ведь тоже драйвера, сокеты, фаловая система и пр.). Для меня IIS и приложение на нем - единое целое и никакие детали реализации этого целого не могут запретить мне принять соглашение, что это одна система и один слой.

tygra

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

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

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


Во-первых хранимые процедуры (и в Versant, и в других СУБД), естественно, тоже могут обрабатывать данные. А во-вторых, а почему хранимые процедуры, например, в Oracle по вашему не являются приложением. И чем они тогда являются?
30 мар 05, 16:40    [1427602]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

Другое дело, что особенности отдельных систем (например, FastObjects t7/.NET, MySQL, SapDB ... ) иногда делают более практичным их использование именно в паре с апп-сервером, а не как самостоятельного и самодостаточного хранилища. Иногда это вопрос пристрастий и элементарного удобства, а иногда - когда модель предметной области такова, что ее просто нельзя корректно запихнуть в базу, - это уже обязательное требование, обусловленное именно фундаментальным требованием обеспечения единого места хранения данных и бизнес-правил, обеспечивающих эту целостность (размазывать бизнес-правила по клиентским приложениям будет ошибкой). Т.е. СУБД+апп-сервер - единственный способ удовлетворить этим фундаментальным требованиям (еще раз акцентирую внимание на том, что такое требование может возникнуть как результат усложнения самой предметной области).

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

автор
На сегодняшний момент есть куча задач которые не удобно/не возможно решать на сервере БД.

Дык, это естественно. Но решать те задачи, которые в СУБД хорошо решаются, на апп-сервере - это то незачем.

======================================

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

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

Ну тогда уж выложите определение прикладной программы.

Прикладная программа - программа, предназначенная для решения задачи или класса задач в определенной области применения системы обработки информации (ГОСТ 19781-90).
:-)
Alexey Rovdo
И почему вы все время сводите вопрос к OODB. Я то говорю в более широком смысле - вообще про любые БД.

Э... Ну как разрабатывать SQLDB, и какими там средствами обеспечивать целостность и непротиворечивость данных - задачи знакомые подавляющему большинству разработчиков. А хотелось бы знать общие и частные преимущества решения этих задач в ORDB, OODB над SQLDB, т.к. OODB все еще достаочно диковинный зверь.

Или этот топик уже давно не об этом? :-)
30 мар 05, 16:43    [1427617]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Прикладная программа - программа, предназначенная для решения задачи или класса задач в определенной области применения системы обработки информации (ГОСТ 19781-90).


Приложение на единственном апп-сервере через которое идет весь доступ к БД под это определение не подпадает. Оно предназначено для решения задачи или класса задач во всех без исключения областях применения системы обработки. Нет задач, которые решаются в обход этого приложения.
30 мар 05, 16:50    [1427652]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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


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


Alexey Rovdo

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

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



Alexey Rovdo

Приняв соответствующее соглашение мы уже можем рассматривать сервер приложений как часть внутренней модели и все указанные замечания к ней не относить.

Т.е. прераспределить ф-ии так, что не возможно сказать где начинается прилоржение, а где СУБД? Я говорил Вам и о других противопоказаниях против этого кроме того, что мы нарушим независимость данных и, возможно, утратим пользу от понятия модели данных, которые в ней были до сих пор.
Мне кажется мы вообще так рискуем получить спагети систему, где все ф-ии перепутанны раз и на всегда.
Тогда, действительно, лучше исходить из того, что нам легче, а что получится потом разберемся. Тогда можно, например, данные втюхать в массивы приложений. Я видел парней, которым так было легче. А потом надо писать запрос, а данные то в проге. Вот классно получилось.
30 мар 05, 16:51    [1427653]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Наконец можно сформулировать и еще одну особенность ООБД, которая вряд ли была бы понята без всего этого длительного обсуждения.

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

Versant проповедует несколько смешанный подход.

С одной стороны, есть ООСУБД FastObjects, которая не включает никакого сервера приложений - там есть только сервер обработки запросов и блокировок. С этим продуктом в большинстве случаев (когда сложность предметной области превышает определенный порог) с точки зрения обеспечения целостности и единства данных и бизнес-логики правильнее использовать сервер приложений (JBoss, Weblogic, Websphere, IIS). Я еще раз подчеркну - все обращения к БД должны идти строго через апп-сервер (не из технических, а именно из соображения соответствия фундаментальным принципам).

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

Также как Oracle когда-то отказалась от написания собственной ОС, скорее всего в перспективе производители ООБД в итоге откажутся и от написания собственных объектных серверов приложений (мое личное мнение). Просто потому, что на рынке и так есть замечательные продукты, которые прекрасно решают эту задачу. Вопрос может стоять лишь в обеспечении более тесной интеграции этих имеющихся серверов с ОО-хранилищами, и построении на базе такого симбиоза систем с новыми возможностями и более практичных и удобных в развертывании и сопровождении.
30 мар 05, 17:15    [1427775]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
serg99
Если разрешить доступ только к ХП, то это конечно еще более жесткий уровень ограничений на потенциально ошибочные действия приложений. Тем не менее бизнес-операции работают над заданной в БД моделью предметной области, которая в отличие от бизнес-операций более стабильна. Поэтому я бы возлагал ограничения по согласованности данных в рамках модели предметной области на триггера, что не позволило бы их нарушить даже неверно написанной ХП.

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

Alexey Rovdo
Очень даже можно. Вопрос только в настройках системы безопасности ОС. Если права есть, то приложение может просто само залезть в фалы БД и работать с ними сколько душе угодно. Причем на настройки безопасности самой СУБД такому приложению будет совершенно начхать.

На такое даже отвечать не интересно. Для очень и не очень осведомленных. Приложение не может обратится к файлу БД по нескольким причинам. Например,
1. СУБД эксклюзивно блокирует файлы БД (что естественно)
2. СУБД может работать держать данные на RAW PARTITION

Разумеется сломать можно все, но факт - большинство разработчиков не будет этого делать, если им не будут платить за сам факт взлома сервера. А это уже другая тема.
30 мар 05, 17:16    [1427782]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Alexey Rovdo

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


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


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

Например, разные БД могут взаимодействовать между собой, поскульку они руководствуются соглашениям под названием "поддержка SQL", "поддержка ODBC" и пр. Именно поэтому мы должны соблюдать общепринятые вещи во всех случаях, в т.ч. и при работе с серверами приложений.

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

Я бы хотел отдельно отметить и вашу фразу "Стоит ли ставку делать на волюнтаризм в виде прихода соглашекний на перекор общей практике?"
С точки зрения людей. которые уже дано и много работают с серверами приложений, то, что вам кажется волюнтаризмом, уже давно стало общей практикой и подобные соглашения их ничуть не напрягают.
30 мар 05, 17:30    [1427833]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Разумеется сломать можно все, но факт - большинство разработчиков не будет этого делать, если им не будут платить за сам факт взлома сервера. А это уже другая тема.


Так ведь об этом и речь. Мы принимаем соглашение не ломать и спокойно работаем с любыми конфигурациями. И замечания типа "а я могу" априори не могут рассматриваться как фундаментальная причина от чего-то отказаться.
30 мар 05, 17:35    [1427855]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Наконец можно сформулировать и еще одну особенность ООБД, которая вряд ли была бы понята без всего этого длительного обсуждения.

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

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

Alexey Rovdo

Кажется, что естественным выходом в такой ситуации является включение методов в хранилище вместе с объектами и отработка этих методов на сервере БД. Но на практике вылазит масса проблем при таком подходе. Не то, вырастают колоссально.
чтобы эти проблемы были совсем не разрешимы, но требования к серверу БД[/quot ]

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

[quot Alexey Rovdo]
В реляционных системах крупнейшие производители пошли по пути совмещения (встраивания) сервера приложений в состав СУБД (этот сервер отвечает за выполнение хранимых процедур). В ОО-системах эта задача более трудна. Стоит ли встраивать в СУБД продукт класса JBoss или Weblogic?

Ну не надо тока подкидвать недостатки РСУБД, которых там нет. В аксцессе да, наверное, там нет триггеров. Но у Оракла, MS Server и многих других есть возможность поддержки с данными, т.е. на сервере БД, а не приложений. Оракл 8 встраивал EJB, CORBA, т.е. хранил их в БД. А в 9 есть отдельный продукт - сервер приложений. И он выполняет какие угодно ф-ии, но тока поддержку ограничений целостности. Такой революционной идеи там никто еще не высказывал.
Получается, что мы выяснили все-таки недостаток ООСУБД с поддержкой ограничений целостности в БД? Ну вроде что-то слышал, что есть такой.
30 мар 05, 17:45    [1427900]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Я не навязываюсь, но как насчет моего поста?

https://www.sql.ru/forum/actualthread.aspx?tid=9021&pg=67#1427583
30 мар 05, 17:51    [1427926]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Alexey Rovdo

Кажется, что естественным выходом в такой ситуации является включение методов в хранилище вместе с объектами и отработка этих методов на сервере БД. Но на практике вылазит масса проблем при таком подходе. Не то,
чтобы эти проблемы были совсем не разрешимы, но требования к серверу БД вырастают колоссально. [/quot ]

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



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

Фраза "с вынесенной поддержкой целостности" мне не нравится. Я продолжаю настаивать на том, что нет никакой "вынесенной" и "внесенной" поддержки целостности. Есть неправильное (привязанное к конкретным реализациям) понимание того, как на самом деле может выглядеть целостная система.

vadiminfo

Alexey Rovdo

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


Ну не надо тока подкидвать недостатки РСУБД, которых там нет.


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

vadiminfo

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


Достаток/недостаток ...
Я вот так и не пришел к пониманию того, что это недостаток. Ограничения целостности сильно связаны с методами объектов. Это недостаток? По какой причине? Просто указанный факт порождает иной подход к обеспечению целостности - это факт. Только говорить о том, что этот иной подход порождает нарушения целостности, неверно. При принятии простых соглашений никакого нарушения не наблюдается. Впрочем, дальше уже дело вкуса - а вкусак, как известно ...
30 мар 05, 18:05    [1427983]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
funikovyuri
На сегодняшний момент есть куча задач которые не удобно/не возможно решать на сервере БД.


Вот и хочется разобраться, насколько велика этя куча
30 мар 05, 18:12    [1428012]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Alexey Sh


Вот и хочется разобраться, насколько велика этя куча


Ага, еще разобраться с явой, дотнетом, аппсерверами ... может будем просто сравнивать БД?
30 мар 05, 18:21    [1428062]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Ага, еще разобраться с явой, дотнетом, аппсерверами ... может будем просто сравнивать БД?

Дык хотелось бы.
Но тогда от FastObjects останется только один большой dbf с внешней обработкой данных посредством апп-сервера - а чего тогда его сравнивать с другими СУБД?

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

Откуда:
Сообщений: 137
tygra
автор
Ага, еще разобраться с явой, дотнетом, аппсерверами ... может будем просто сравнивать БД?

Дык хотелось бы.
Но тогда от FastObjects останется только один большой dbf с внешней обработкой данных посредством апп-сервера - а чего тогда его сравнивать с другими СУБД?

-- Tygra's --


дорогу осилит идущий
30 мар 05, 18:32    [1428103]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
Alexey Rovdo
Вы знаете, я вас просто не понимаю. Вот есть у нас сохраняемый класс, у него есть список сохраняемых атрибутов, объект этого класса хранится в БД, все его сохраняемые атрибуты хранятся в БД. Какие "разные" версии этого класса вы полагаете можно иметь в разных приложениях? Просто поясните, а то я запутался.
Всё очень просто - есть пользователи, есть группы, отношение многое ко многим - в группе несколько пользователей, у пользователя несколько групп.

Понятно, что пример дурной и Вы мне легко найдёте решение (я и сам легко найду), но при решении "в лоб" (у пользователя коллекция ролей, у роли - коллекция пользователей) возникнут проблемы с синхронизацией. Это самый простой пример, если Вы настаиваете - я смоделирую чего посложней. Но главное - при создании БД далеко не всегда можно точно указать все возможные применения, зачастую приходится сипользовать имеющиеся данные в новой парадигме. Каждый раз при этом наследоваться от чего-то... Бррр....
30 мар 05, 19:56    [1428278]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
автор
Вы знаете, я вас просто не понимаю. Вот есть у нас сохраняемый класс, у него есть список сохраняемых атрибутов, объект этого класса хранится в БД, все его сохраняемые атрибуты хранятся в БД. Какие "разные" версии этого класса вы полагаете можно иметь в разных приложениях? Просто поясните, а то я запутался.
... продолжаю мысль. То есть не разные версии класса, а разные классы, пользующие одни и те же данные в разных контекстах. Так понятней?
30 мар 05, 19:59    [1428282]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Например, разные БД могут взаимодействовать между собой, поскульку они руководствуются соглашениям под названием "поддержка SQL", "поддержка ODBC" и пр. Именно поэтому мы должны соблюдать общепринятые вещи во всех случаях, в т.ч. и при работе с серверами приложений.

Прежде всего реляционные БД могут взаимодействовать между собой, потому что это достоинство реляционной модели - обеспечивать достаточно высокую степень независимости данных от приложения. Потому рел БД относительно независима и от СУБД. А "поддержка SQL", "ODBC" - это всего лишь реализация. И если бы они этого не могли, то не зависимо ни от каких соглашений были бы сегодня на помойке, а их место заняли бы другие. Потому что заказчику нужны решения, а не соглашения. Представьте ему что-то надо, а мы скажем: "Мы этого Вам не дадим, но дадим лучше - соглашения". Если бы так можно было, счас бы не было бы ни одной системы, а были бы тока соглашения.
Особенно хорошо, если не важно кто соглашался. предъявил соглашение, получил бабки и пошел домой.

Alexey Rovdo

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

Хорошо коли так. Но некоторые говорили, что их Дос не напрягает, и не хотели переходить на Винды. А еще раньше с калькулятора на комп.
Т.е. такие ссылки нельзя назвать лучшим доказательством. Действительно, о чам мы тада говорим? Сравниваем типы СУБД. Есть люди которых не напрягает никакой из этих типов, и они давно работают. И каждый может привести десяток фамилий. Или как ЧАЛ - балабановскую спичечную фабрику.

Alexey Rovdo

Есть неправильное (привязанное к конкретным реализациям) понимание того, как на самом деле может выглядеть целостная система.

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

Alexey Rovdo

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


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

Alexey Rovdo

Достаток/недостаток ...
Я вот так и не пришел к пониманию того, что это недостаток. Ограничения целостности сильно связаны с методами объектов. Это недостаток? По какой причине? Просто указанный факт порождает иной подход к обеспечению целостности - это факт. Только говорить о том, что этот иной подход порождает нарушения целостности, неверно. При принятии простых соглашений никакого нарушения не наблюдается. Впрочем, дальше уже дело вкуса - а вкусак, как известно ...

Ну, мы сравниваем типы СУБД, стало быть выясняем - Достаток/недостаток ...
Ограничения целостности сильно связаны с данными, а не с чем либо еще.
Точнее это логические правила, которым должны отвечать данные в любом состоянии БД. Равно как они долже отвечать схеме в любом состоянии.
Принятием соглашений мы не можем заставить ток теч в другую сторону. Они к данному вопросу не имеют никакого отношения. Потому что есть технологии БД, которыми мы пользуемся, и у них есть свои достижения, которые никакими соглашениями не отменишь. Можно тока все испортить.
Ну про вкус и грить нечего. Можно сказать: "Чего сравнивать разные типы СУБД? - дело вкуса".
30 мар 05, 21:20    [1428385]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Alexey Rovdo
Так ведь об этом и речь. Мы принимаем соглашение не ломать и спокойно работаем с любыми конфигурациями. И замечания типа "а я могу" априори не могут рассматриваться как фундаментальная причина от чего-то отказаться.

Да не принимаем мы эти соглашения. Вот в чем штука. Всякий желающий может попытаться ломать сервера. Можно начать с того же SQL Server, если вам он больше знаком.

PS. Судя по высказываниям - вообще, не знаком ни один сервер.
PPS. Раньше, когда было какое-то обсуждение концепций самого версанта, можно было надеятся на адекватные ответы. Сейчас - нет.
30 мар 05, 22:49    [1428447]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Alexey Rovdo
>> Причем тогда эквивалентность ХП и апп-сервера?

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

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

ХП как правило не взаимодействует с пользователем (не является интерактивной), не взаимодействует непосредственно с внешними приложениями или с внешними устройствами.

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

ХП не может установить коннект со своей же СУБД. ХП не может решить никакой функционально полной прикладной задачи. ХП существует в рамках одной транзакции.

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

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


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


Что бы мы не встроили в СУБД, оно уже не будет приложением. По опредлению приложение «внешне» относительно СУБД. Не понятно так же почему обеспечение согласованности для ООБД настолько сложное что требует вставки туда ХП сравнимых по сложности с Jboss.

Насчет контекстов о чем уже говорил Павел Воронцов. Допустим в ИС предприятия есть приложения «Продажи», «Логистика», «Фин анализ» и пара апп-серверов например «Веб каталог» и «Электронная торговля». Скажем для Продаж нужна отпускная цена товара. Для Фин анализа нужна кроме этого и покупная цена. Для Логистики важен вес и габариты товара, но совсем не нужны цены. Для Веб каталога ко всему прочему нужно описание товара и его фотография. И т.п. То есть разным приложением нужны разные «представления» одного и того же объекта с разным набором свойств. Соответственно прикладные классы должны быть разные в том числе потому что прикладные методы в разных приложениях разные (я уже не говорю что СУБД по идее должна уметь общаться с любой даже не ООП программой). Теперь представьте, что Вам нужно каждого разработчика каждого из этих приложений заставить в каждый свой класс вставить нужный метод обеспечения согласованности (что бы этот метод везде работал нужно еще следить за общими правлами именования персистентных свойств), да еще потом проконтролировать что они это сделали. И может оказаться, что правила согласованности задействуют группу свойств, которые не присутствуют одновременно хотя бы в одном приложении (или во всех), а присутствуют одновременно только в БД. Получается все такие свойства нужно тащить во все приложения независимо от того нужны они там или нет. А если изменилось законадательство (например стало можно выписать счет без НДС для предприятий с упрощенной системой налогового учета) и ограничения в результате добавились/убавились – изменять все приложения?
31 мар 05, 00:10    [1428511]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mv
Member

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

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

Мне кажется, что Вы мало чего здесь добьетесь :o)

Ваши оппоненты: спортсмены - любители, их интересует не финиш, а процесс разминки, цвет флага своего любимого клуба, фамилия тренера, марка кроссовок и т.п. Несомненно, вещи важные.
31 мар 05, 00:43    [1428539]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
mv
Мне кажется, что Вы мало чего здесь добьетесь :o)

Ваши оппоненты: спортсмены - любители, их интересует не финиш, а процесс разминки, цвет флага своего любимого клуба, фамилия тренера, марка кроссовок и т.п. Несомненно, вещи важные.
Вы правы. Я сюда уже давно развлекаться хожу. Только мне интересен цвет флага, которым размахивает оппонент. Смешно у него получается иногда.
mv
Люди, имеющие опыт работы со сложными системами, склонны рассматривать их свойства (обеспечение целостности данных на уровне СУБД, наличие триггеров, возможность использования ранимых процедур и проч.) как самодостаточные, ценные сами по себе без привязки к предметной области.
А Вы кстати не задумывались почему так? Может быть потому, что они ответственно подходят к разработке этих самых сложных систем? Может быть обеспечение целостности данных на уровне СУБД - это требование, которое нельзя просто так обойти? Попробуйте заикнуться в беседе с банкиром, которому Вы пишите софт, что ваша система не обеспечивает целостность на уровне СУБД, а только в связке с приложением! Знаете куда он Вас .. что он Вам скажет?
31 мар 05, 06:49    [1428660]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 62 63 64 65 66 [67] 68 69 70 71 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить