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

Откуда: Томск
Сообщений: 1027
Alexey Rovdo
задумайтесь, зачем существуют апп-сервера

Знаете, на этом форуме уже не раз обсуждался вопрос необходимости трехзвенки, то есть наличия апп-серверов. (Можете использовать поиск). Так вот. Каждый раз выяснялось, что сторонники апп-серверов так и не могли четко обосновать их необходимость в каждом конкретном случае. Такая вот фишка.
А по поводу триггеров... У меня впечатление, что вы сами не имеета богатого опыта их создания и использования (как и РСУБД в целом). Поскольку вы иногда путаете ХП и триггеры, а при всем сходстве есть существенные отличия. Кроме того, вы занижаете их вычислительные возможности. Я с легкостью реализовывал на T-SQL к примеру методы наименьших квадратов, кусочно-линейную интерполяцию. Код получался ясный, компактный и достаточно эффективный.
30 мар 05, 08:11    [1425059]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


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

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


mir

А по поводу триггеров...


А по поводу триггеров я не написал НЕЛЬЗЯ РЕАЛИЗОВАТЬ, а написал НЕРАЦИОНАЛЬНО. Это была всего-лишь демонстрация того факта, что само по себе отнесение проблемы к ограничениям целостности слабо влияет на то, где мы в итоге решаем производить ВЫЧИСЛЕНИЯ - на серверее или на клиенте. Место самих вычислений определяется конкретными условиями проекта. А вот сам код, обеспечивающий целостность данных, должен существовать в одном экземпляре и с этим я не спорю.
30 мар 05, 10:21    [1425385]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Alexey Rovdo
само по себе отнесение проблемы к ограничениям целостности слабо влияет на то, где мы в итоге решаем производить ВЫЧИСЛЕНИЯ - на серверее или на клиенте

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

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

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

А что такое апп-сервер? Вы сами то можете сказать - что это такое? Потом, как скажите, станет понятно, что такое ХП и почему отличается от апп-сервера.
автор
Т.е. используем мы встроенный (ХП) или внешний (JBoss и т.п.) сервер приложений сути никак не меняет.

Никак, конечно, только на 180 градусов разворачивает понятие.
автор
Что если завтра Oracle решит интегрировать апп-сервер в состав СУБД и продавать это единым пакетом?

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

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

Хоть какую СУБД возьмите и из нее вынесите логику - получится зло.
автор
А вот то же самое приложение в MS SQL 2005 уже можно исполнить "внутри" СУБД и тогда - честь ему и хвала - оно правильное.

Какое то же самое приложение ? Где оно? Вы о чем???? Вам плохо???

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

Это бред полнейший!!! Я пошел за доктором.
Если вы ЭТОГО не понимаете - в чем разница между внутри и снаружи - то какого хрена вы чего-то вообще можете кому-то доказывать?
Это все-равно, что говорить: совершенно пофиг где ставить двигатель автомобиля - внутри него самого, или сзади на прицепе в тележке.

Вам уже 145 раз сказали:
- Данные и обработка их должны быть неотделимы друг от друга.
- Мало того, работать с данными отдельно от бизнес-логики, которая заложена в обработку - не должно быть возможно ни коим образом.
- Обработка данных не зависит от клиента и технологии доступа к СУБД

Если это вам не понятно, если вам непонятно то, что никакой апп-сервер не удовлетворяет этим условиям и в том числе FastObjects - то о чем вы вообще можете рассуждать?

-- Tygra's --
30 мар 05, 11:06    [1425576]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

Сервер статических данных - т.е, всякие партнеры, выпущенные акции, опционы, страны и т.д. и т.д. ~100 типов объектов и ~800 таблиц.
Объем базы 236 GB.
Задача основная - мегабыстрая выдача данных - не более 5 мсек. Обращаются постоянно ~100 приложений и ~10000 запросов на данные ежесекундно. Запросов на обновление не более 1%.

Архитектура:

Есть Оракл - в нем нет никаких тригеров, хр, процедур и даже foreign key
Есть только туева куча индексов. (8xOpteron, 8 GB памяти, Solaris, EMC хранилице)
(100 тыс$), цена оракла - 100тыс$

Уровень апп-серверов - 40 машин (2xOpteron, 1GB, JBoss, TreeCache)
Задача - управлять целостностью, кэшировать данные, отдавать данные клиентам по вебсервисам, хттп, и т.д
(100 тыс$), софт - JBoss, Linux (не знаю какой) не стоит ничего

Итого ~300 тыс$.

Эквивалентная система (~10000 запросов на данные ежесекундно,не более 5 мсек запрос), реализованная только средствами Оракла, предложенная нам по тендеру стоила примерно 5 млн$

И не говорите мне, что мега специфичный проект.
30 мар 05, 11:08    [1425582]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
>> Данные и обработка их должны быть неотделимы друг от друга

Данные и обработка неотделимы !

А что такое "неотделимы "? Это как? На одном компе, процессоре, в одном потоке, файле, в одно и то же время? Что же это значит "неотделимы"?
30 мар 05, 11:13    [1425602]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


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

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Что из себя представляют апп-сервера? Чем они занимаются конкретно? Почему ОНИ этим занимаются (а не СУБД)? Почему именно 40? Почему нет никаких ХП в БД (чем они помешали)? Проверял ли кто, как бы оно работало без апп-серверов? Что было предложено за 5 миллионов баксов?

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

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

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

Alexey Rovdo
Данные и обработка неотделимы !
А что такое "неотделимы "? Это как? На одном компе, процессоре, в одном потоке, файле, в одно и то же время? Что же это значит "неотделимы"?


- Ку
- Ыыыыыыыыыы....
- Мама, мама, что я буду делать
- Ку


ЗЫ я тоже буду изображать из себя дурачка :
а что такое обработка? а что такое данные? это как? что такое процессор? что такое файл? что такое время? кто я? где я? oh, ya, ya, dast ist fantastish.....
Ыыыыыыыыыыыыыыы...
Ку!


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

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

Я думаю Ващи оппоненты имеют ввиду проблему управляемости сложных систем. Как правило к написанию триггеров и ХП определяющих бизнес-логику допускается ограниченный круг умных голов. В то время как приложения в разное время создают разные люди разной квалификации. В результате
1) Не все они правильно понимают/реализуют бизнес логику.
2) Нет механизмов гарантирующих что они будут использовать некий волшебный единственный экземпляр кода реализующий бизнес логику (ежели таковой даже существует).

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

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

Именно. За исключением ХП. Для предотвращения некорректного обращения с данными собственно они и нужны. Пользователи СУБД (программист апп-сервера, сам апп-сервер, просто "бивень" какой-то) не имеют доступа к данным. У них максимум может быть только права на исполнение некоей ХП, представляющей собой одну согласованную бизнес-операцию. И все. Нет прав напрямую обратиться к таблицам, нет прав исполнить "опасные" процедуры, нет прав создать процедуры, позволяющие обойти эти ограничения. Такая безопасность гарантируется самой СУБД. А ее уже ломают очень редко.
30 мар 05, 11:41    [1425712]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Alexey Rovdo
Почему то некоторым кажется, что апп-сервер чем-то фундаментально отличается от ХП. Но что такое ХП, если не встроенный в СУБД апп-сервер?

По моему ХП например не может открыть коннект с СУБД. Кроме того ХП насколько мне представляется живет не дольше чем транзакция где она вызвана. ХП как правило имеют ограничения на непосредственное использование функций операционной системы. То есть конечно фундаментально в обоих случаях мы имеем дело с кодом который реализует некий алгоритм, тем не менее различия достаточно существены. Хотя конечно можно рассматривать ХП как пораженное в правах приложение.
30 мар 05, 11:46    [1425739]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 serg99
Ну еще ХП исполняется в контексте транзакции - не клиентской транзакции.
А еще ХП нельзя обойти - как правильно написал AAron, есть возможность только запустить ХП, больше ничего. Т.е. с данными в обход СУБД нельзя работать.
Соответственно полностью котроллируется целостность данных и выполнение заданной бизнес-логики
И соответственно с БД может работать любой клиент, который вообще может работать с СУБД.

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

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

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

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

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

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

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

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

Откуда: Москва
Сообщений: 913
>>Т.е. с данными в обход СУБД нельзя работать.

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

Откуда: Москва
Сообщений: 913
>> Все это никак не может относиться к апп-серверу, который сам является еще одним клиентом для СУБД.

Да единственный он клиент - ЕДИНСТВЕННЫЙ. Я не хочу усложнять ситуацию и говорить о распределенных системах. Для простоты я также исхожу из того, что и установлен он на том же сервере, что и БД. А внешние клиенты не имеют прав на подключение напрямую к БД и могут только вызывать сервисы сервера приложений.
30 мар 05, 12:05    [1425845]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Павел Воронцов
Member

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

Кстати - а чем помешали внешние и первичные ключи (ограничения целостности)? У вас же сплошные выборки - констрейнты могли бы помочь и вам и серверу. И наличие триггеров вряд ли сказалось бы на производительности операций обновления - при наличии большого количества индексов (я так понимаю, покрывающих все самые ходовые сочетания условий на выборку, так?) время на их обновление будет тратиться скорей всего больше.

Я не против апп серверов. Просто Ваш пример не показателен. Сделали так - и молодцы, вы проект сдали, а потому победители и не мне вас судить что там было не так. Надо только отдавать себе отчёт в том, что вы делали - а сделали вы просто приложение, работающее как часть СУБД (в вашем случае - Оракла) и снимающее таким образом с него нагрузку. Оракл и сам бы справился, но за гораздо бОльшие деньги.
30 мар 05, 12:06    [1425851]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Т.е. приняв соглашение неиспользовать в коде наших приложений на апп-сервере некоторой функциональности (и усилив это соглашение соответствующей настройкой системы безопасности ОС) мы можем достичь полной эквивалентности c ХП?
30 мар 05, 12:09    [1425865]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
AAron
Именно. За исключением ХП. Для предотвращения некорректного обращения с данными собственно они и нужны. Пользователи СУБД (программист апп-сервера, сам апп-сервер, просто "бивень" какой-то) не имеют доступа к данным. У них максимум может быть только права на исполнение некоей ХП, представляющей собой одну согласованную бизнес-операцию. И все. Нет прав напрямую обратиться к таблицам, нет прав исполнить "опасные" процедуры, нет прав создать процедуры, позволяющие обойти эти ограничения. Такая безопасность гарантируется самой СУБД. А ее уже ломают очень редко.

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

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

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


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

Наверное можно, но мне трудно представить какую либо пользу от приложения которое может обслужить только одного пользователя, выполнить только одну транзакцию и не может при этом пользоваться операционной системой.
30 мар 05, 12:22    [1425921]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
tygra
Что из себя представляют апп-сервера? Чем они занимаются конкретно?


Извините, то почему бы вам не почитать самому?

tygra

Почему ОНИ этим занимаются (а не СУБД)?


Оракл дороже.

tygra

Почему именно 40?


Так сбалансировались машины в тестах производительности

tygra

Почему нет никаких ХП в БД (чем они помешали)?


Весь доступ через апп сервера. Их много, меньше сжирается ресурсов серведа БД.

tygra

Проверял ли кто, как бы оно работало без апп-серверов? Что было предложено за 5 миллионов баксов?


Именно без аппсерверов и предложили на тендере. Что было предложено - не важно. Главное, предлагали профессионалы от Оракла.

tygra

Лично я бы вместо указанных апп-серверов поставил win2003+IIS+.net (asp.net), которые бы обеспечили то же самое, но всю логику запихал бы в СУБД.


Если бы вы были CIO, то да.

tygra

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


Потому что не знаете что это такое
30 мар 05, 12:31    [1425968]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Dimonische
Кстати, вот вам пример приложения - зачен нужны аппсервера
...
И не говорите мне, что мега специфичный проект.

А у вас есть статистика по специфике разработки ИС? Какими данными вы обоснуете, что данный проект не мега специфичный?
Кстати, возможно вы выбрали наилучший вариант из возможных, вовсе не спорю. Я не знаю вашу задачу в подробностях, не знаю какие были альтернативы, да и опыта создания подобных систем у меня нет. Так что если есть прямые специалисты по таким задачам, они и выскажутся.
Вот что мне интересно. Ваши 40 апп-серваков идентичны по софту? То есть на них один и тот же код крутится? Если нет, то при необходимости модификации бизнес-правил надо одновременно модифицировать несколько совершенно различных приложений. При этом, само собой, весьма возможны программистские ошибки. То есть одни проги будут блюсти целостность одним образом, а другие проги - совсем даже другим образом. То есть выиграли в производительности -- потеряли в централизации управлении изменениями, которую обычно обеспечивает СУБД. А это может обернуться ошибками, потерями данных. Подчеркиваю - не обязательно обернется, но может обернуться.
То есть моя мысль в том, что решения, "отрывающие" поддержу целостности от самий СУБД, всегда потенциально опасны.
30 мар 05, 12:35    [1425986]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

И как же он будет в одном экземпляре, если он будет на клиенте. Клиентов-то много. Что-то вы себе противоречите...

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

Dimonische

И не говорите мне, что мега специфичный проект.

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



serg99

Я думаю Ващи оппоненты имеют ввиду проблему управляемости сложных систем.

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

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

Я спрашивал именно про ваши апп-сервера - каую работу они выполняют именно в вашей системе?
автор
Оракл дороже.

Дороже чего? Он же все-равно куплен.
автор
Весь доступ через апп сервера. Их много, меньше сжирается ресурсов серведа БД.

Каких ресурсов? Селект напрямую проще чем ХП? Или вы кучу данных храните на апп-серверах и оттуда берете? Чем это лучше?
автор
Именно без аппсерверов и предложили на тендере. Что было предложено - не важно. Главное, предлагали профессионалы от Оракла.

Все знают о предложениях от "профессионалов" - как можно больше, как можно дороже.
автор
Если бы вы были CIO, то да.

Т.е. апп-сервера были взяты именно потому, что CIO "помешан" на них? И что выбор был просто от фонаря. Понятно :))
автор
Потому что не знаете что это такое

Ну так скажите разницу.

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

2 Alexey Rovdo
автор
>>Т.е. с данными в обход СУБД нельзя работать.

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

У вас етсь такие приложения? И вы так работаете? Кто-то так работает? И как оно? :))
автор
>> Все это никак не может относиться к апп-серверу, который сам является еще одним клиентом для СУБД.

Да единственный он клиент - ЕДИНСТВЕННЫЙ. Я не хочу усложнять ситуацию и говорить о распределенных системах. Для простоты я также исхожу из того, что и установлен он на том же сервере, что и БД. А внешние клиенты не имеют прав на подключение напрямую к БД и могут только вызывать сервисы сервера приложений.

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

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

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

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

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

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

Что-нибудь забыл ?
30 мар 05, 13:20    [1426224]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 59 60 61 62 63 [64] 65 66 67 68 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить