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

Откуда: Москва
Сообщений: 913
>> Зачем? Зачем ставить апп-сервер, тем самым мало того, что усложняя в разы процесс разработки, так еще и ограничивая возможность доступа к БД - select можно послать хоть из ексела, а к апп-серверу как подключаться?

К перечню добавлю еще один путнкт.

Наличие стандартов и спецификаций на протоколы доступа к сервисам системы со стороны клиентских приложений.

Замечу, что это тоже прикладной вопрос.
30 мар 05, 13:22    [1426233]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

Ну, не стоит так уже принижать результаты того топика. Все-таки кое-что там сказали. Кроме того, не зависимо от того, что было выяснено в том топике, нужность и полезность апп-серверов и вообще многозвенки в реальной жизни может быть. Т.е. того или другого топика, скорее всего, не достаточно для обоснования ненужности во всех других топиках.
30 мар 05, 13:23    [1426236]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Alexey Rovdo
serg99

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


Т.е. приняв соглашение неиспользовать в коде наших приложений на апп-сервере некоторой функциональности (и усилив это соглашение соответствующей настройкой системы безопасности ОС) мы можем достичь полной эквивалентности c ХП?

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


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

Откуда: Новосибирск
Сообщений: 2400
Блог
Alexey Rovdo
Итак мне кажется мы наконец пришли к пониманию того факта, что .....
Вот тут Вы мне начинаете напоминать колеегу ЧАЛа. Ему все говорят - ну нифига себе! А он - итак мы согласились... ))
30 мар 05, 13:34    [1426307]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Павел Воронцов
Вот тут Вы мне начинаете напоминать колеегу ЧАЛа. Ему все говорят - ну нифига себе! А он - итак мы согласились... ))


Но тогда выскажите свое мнение хотя бы по такому вопросу:

Вот скажем у меня есть Java-процедура, которая относится к уровню бизнес-логики. Я могу разместить ее на сервере приложений (скажем JBoss), а могу в виде хранимки (Oracle). (Предположим, что Oracle и JBoss стоят на одном компе) В чем разница? Они даже в рамках одной и той же JVM могут исполняться. Почему про первый случай кто-то говорит, что это чему-то там не соответствует, а во втором "соответствие" снисходит на нас?
30 мар 05, 13:46    [1426387]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Alexey Rovdo
Приложение на апп-сервере может обслуживать одновременно множество пользовательских приложений (это апп-сервер один, но с ним то уже работает множество приложений-клиентов), выполнять в разных потоках множество транзакций и пользоваться операционной системой в рамках наложенных ограничений.

Причем тогда эквивалентность ХП и апп-сервера? Если Вы переведете аббревиатуру ХП как "хранимое приложение", а не "хранимая процедура", обеспечите механизм загрузки этого приложения по запросу здесь же на серверном или на удаленном компьютере, с правами открывать коннекты/сессии с СУБД (откуда следует множественность транзакций) и с правами пользоваться любыми сервисами операционной системы или любых других приложений, то только тогда можно говорить об эквивалентности апп-сервера и ХП. Просто процедуры здесь непричем.
30 мар 05, 13:50    [1426411]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Alexey Rovdo
Я могу разместить ее на сервере приложений (скажем JBoss), а могу в виде хранимки (Oracle). (Предположим, что Oracle и JBoss стоят на одном компе) В чем разница? Они даже в рамках одной и той же JVM могут исполняться. Почему про первый случай кто-то говорит, что это чему-то там не соответствует, а во втором "соответствие" снисходит на нас?

Они не могут выполняться на одной JVM. У СУБД своя JVM, причем с определенными ограничениями (нельзя например пользоваться многопоточностью).
30 мар 05, 13:55    [1426436]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Alexey Rovdo
Павел Воронцов
Вот тут Вы мне начинаете напоминать колеегу ЧАЛа. Ему все говорят - ну нифига себе! А он - итак мы согласились... ))


Но тогда выскажите свое мнение хотя бы по такому вопросу:

Вот скажем у меня есть Java-процедура, которая относится к уровню бизнес-логики. Я могу разместить ее на сервере приложений (скажем JBoss), а могу в виде хранимки (Oracle). (Предположим, что Oracle и JBoss стоят на одном компе) В чем разница? Они даже в рамках одной и той же JVM могут исполняться. Почему про первый случай кто-то говорит, что это чему-то там не соответствует, а во втором "соответствие" снисходит на нас?
Про разницу Вам уже сказали, я ничего нового добавить не могу. Безопастность, целостность данных.

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

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

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

Откуда: Москва. Россия
Сообщений: 1576
А мне всегда хотелось обрабатывать данные там же где мы их храним.... а то на апп-сервере свои переменные (для обработки), на сервере данных свои(для хранения), значения в этих переменных синхронизировать надо, опять же вопрос пресловутого "импеданса" моделей для случая с выделенными апп-сервером решать надо...... В общем я ни к чему не пришел....

Кстати, аналогия с коллегой ЧАЛ в фразе "Итак, мы пришли..." мне тоже в глаза прямо так и бросилась.....
30 мар 05, 14:05    [1426486]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Alexey Rovdo
Просто в общем случае на "внешнем" сервере приложениям предоставлена несколько большая свобода действий, чем хранимым процедурам на "встроенном" сервере.
Всё дело именно в этом "несколько". Зачастую оно очень весомо и им нельзя пренебрегать.
30 мар 05, 14:10    [1426523]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Вот скажем у меня есть Java-процедура, которая относится к уровню бизнес-логики. Я могу разместить ее на сервере приложений (скажем JBoss), а могу в виде хранимки (Oracle). (Предположим, что Oracle и JBoss стоят на одном компе) В чем разница? Они даже в рамках одной и той же JVM могут исполняться. Почему про первый случай кто-то говорит, что это чему-то там не соответствует, а во втором "соответствие" снисходит на нас?


Павел Воронцов

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


Ничего конкретного никто до вас не говорил. Итак давайте теперь разберемся "Безопастность, целостность данных"

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

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

Павел Воронцов

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


Нигде такого не выснялось. Versant поддерживает и триггеры и хранимые процедуры ... бла-бла-бла


Павел Воронцов

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


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

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

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

Что-нибудь забыл ?

Это вы об ком собственно - апп серверах или ХП?

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

Я у вас еще раз спрошу - зачем вам, мне, кому-то еще апп-сервер?????
Вы можете обосновать?

Павел Воронцов
Alexey Rovdo
Итак мне кажется мы наконец пришли к пониманию того факта, что .....
Вот тут Вы мне начинаете напоминать колеегу ЧАЛа. Ему все говорят - ну нифига себе! А он - итак мы согласились... ))

Точно! Тихо сам с собою я веду беседу... :))

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

Alexey Rovdo
Вот скажем у меня есть Java-процедура, которая относится к уровню бизнес-логики. Я могу разместить ее на сервере приложений (скажем JBoss), а могу в виде хранимки (Oracle). (Предположим, что Oracle и JBoss стоят на одном компе) В чем разница? Они даже в рамках одной и той же JVM могут исполняться. Почему про первый случай кто-то говорит, что это чему-то там не соответствует, а во втором "соответствие" снисходит на нас?

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

Так ответьте же на вопрос, выше заданный!

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

Прямо абсолютно верно!
-- Tygra's --
30 мар 05, 14:22    [1426619]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
U-gene
А мне всегда хотелось обрабатывать данные там же где мы их храним....


Конечно игра слов, но все-таки: если мы храним данные на сервере "A" в СУБД MS SQL, а обрабатываем их на сервере "А" в J2EE-приложении под управлением JBoss, то ответ на вопрос "где мы храним и обрабатываем данные" звучит так "На сервере А - в одном месте".

Вот есть нечто. Оно называется СУБД. А давайте СУБД+аппсервер тоже назовем одним термином "Расширенная СУБД". А теперь мы може спокойно говорить "мы обрабатываем данные там же где мы их храним - в Расширенной СУБД".

U-gene

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

Прикладная проблема имеющая решение.


U-gene

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


ХОП! А если не надо ?
30 мар 05, 14:26    [1426653]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

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

Гы.. Опять косим? При чем тут ХП и триггеры?
А методы объектов? Они лежат в БД? И их можно исполнять внутри БД? Или опять притворимся? Закосим под ЧАЛа?

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

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

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

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

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

Кроме того, насколько я в курсе, коллега ЧАЛ давно узурпировал право делать выводы дискуссии игнорируя другие посты или истолковывая их на свой манер, и не делился пока еще ни с кем этим правом.


Alexey Rovdo

К прикладным аспектам удобства использования при разработке и развертывании в общем случае можно отнести такие факторы:


Что-нибудь забыл ?

Насчет прикладных можно конечно думать. Но фундаментальные тоже имеют значение.

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

Откуда: Новосибирск
Сообщений: 2400
Блог
ой, держите меня семеро, я сейчас опять начну читать лекцию о том что такое модель данных и как она с БД соотносится....
Alexey Rovdo
Нигде такого не выснялось. Versant поддерживает и триггеры и хранимые процедуры ... бла-бла-бла
Прстите, если я что-то упустил в этой многостраничной эпопее на несколько топиков - а чем оперируют эти самые триггера и хранимые процедуры?
Alexey Rovdo
Вы сами выбираете способ организации приложений, осуществляющих доступ к ООСУБД Versant ... В нормальной ситуации все приложения должны опираться на единые библиотеки хранимых классов. Тем не менее это могут быть разные приложения (опирающиеся на разные подмножества единой библиотеки). Но если очень нужно получить доступ к объектам, описания которых не известны на этапе компиляции приложения , то это тоже возможно ... бла-бла-бла
А я не об этом. Не о том, что описание объектов не известно на этапе компиляции. Я о том, что иногда трудно построить единую библиотеку так, чтобы она разбивалась на непротиворечивые подмножества, необходимые разным приложениям. По мне так это задача, на порядок более сложная, чем построение реляционной схемы и двух независимых объектных надстроек. В этом случае хвалёное преимущество в скорости разработки скрадывается. Исчезает. Увы.
30 мар 05, 14:34    [1426704]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

К прикладным аспектам удобства использования при разработке и развертывании в общем случае можно отнести такие факторы:

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

Что-нибудь забыл ?


tygra
Это вы об ком собственно - апп серверах или ХП?


Это перечень критериев, по которым справедливо сравнивать разные подходы - на базе апп-серверов и на базе хранимых процедур. То есть это об обоих. Другие критерии (такие как "целостность данных", "независимость от приложения" и т.п.) по моему несправеливы и несколько демагогичны.
30 мар 05, 14:36    [1426716]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Конечно игра слов, но все-таки: если мы храним данные на сервере "A" в СУБД MS SQL, а обрабатываем их на сервере "А" в J2EE-приложении под управлением JBoss, то ответ на вопрос "где мы храним и обрабатываем данные" звучит так "На сервере А - в одном месте".
Вот есть нечто. Оно называется СУБД. А давайте СУБД+аппсервер тоже назовем одним термином "Расширенная СУБД". А теперь мы може спокойно говорить "мы обрабатываем данные там же где мы их храним - в Расширенной СУБД".

А давайте перестанем прикидываться непонимающим тупым ... уродом (простите уж, вырвалось).

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


ЗЫ Какой я гадкий :(=)

==========

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


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

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

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

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

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

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

А весны все нет в Москве, мать ее.......
В Иркутске уже две недели +10 на улице!!!!

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

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

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


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

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

vadiminfo

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


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

Откуда: Москва. Россия
Сообщений: 1576
Alexey Rovdo
U-gene
А мне всегда хотелось обрабатывать данные там же где мы их храним....


Конечно игра слов, но все-таки: если мы храним данные на сервере "A" в СУБД MS SQL, а обрабатываем их на сервере "А" в J2EE-приложении под управлением JBoss, то ответ на вопрос "где мы храним и обрабатываем данные" звучит так "На сервере А - в одном месте".

Вот есть нечто. Оно называется СУБД. А давайте СУБД+аппсервер тоже назовем одним термином "Расширенная СУБД". А теперь мы може спокойно говорить "мы обрабатываем данные там же где мы их храним - в Расширенной СУБД".

U-gene

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

Прикладная проблема имеющая решение.


U-gene

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


ХОП! А если не надо ?


Хорошо :) я перефразирую. Поскольку в связке апп-сервре + пассивный сервер БД для хранения и обработки переменных используются разные пременные, возникает куча требующих решения вопросов (прикладных-неприкладных, надо-ненадо см. выше), которые в случае с ...ммм.... активным сервером, где данные обрабатываются в тех же пременных, где они и хранятся, отсутсвуют по определению. Действительно, внешне может быть разницы и будет, но нафига эти лишние внутренние гемморои?
30 мар 05, 14:48    [1426818]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

Я у вас еще раз спрошу - зачем вам, мне, кому-то еще апп-сервер?????
Вы можете обосновать?


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

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

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


Возможно для вашей воспаленной психики это будет слишком тяжело. Рекомендую вам прекратить чтение данного топика, чтобы уберечь себя от психических расстройств, вызванных неизбежным пониманием несостоятельности и зашоренности вашего взгляда на простые и обыденные вещи ...
30 мар 05, 14:52    [1426843]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 60 61 62 63 64 [65] 66 67 68 69 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить