Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 17   вперед  Ctrl
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
автор
Вот интересно, как крутяться задачи по расчетам зп, кварплаты, схемы энергопотребления промышленных абонентов, где расчет идет по графам на ХП ?


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

ЗЫ. как-то никак не вьезжаю в суьб спора, есть дата тиер, он на хп, что может помешать мидл тиеру обращатся к хп не врубаюсь.
8 окт 04, 16:47    [1020141]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Tygra

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

ASCRUS
автор
Вот интересно, как крутяться задачи по расчетам зп, кварплаты, схемы энергопотребления промышленных абонентов, где расчет идет по графам на ХП ? И неплохо крутятся, так как SQL в свете динамического SQL еще и выступает для бизнес-логики в качестве встроенного языка, на котором можно не только быстро и красиво описать правила расчетов обьектов (уточню - запросами, а не курсорчиками), но еще и позволяет организовать хранение истории изменения самих алгоритмов во времени (хоть задними числами).


Расчет ЗП - это алгоритм - где именно и на чем он реализован - дело десятое. Да SQL рулит в качестве средства преобразования одних структурированных данных в другие - спору нет. Но насчет того же dynamic SQL - все знают чего он стоит в DBMS - и странно спорить о том что сделать это же на ОО-языке было бы еще проще. Хотя не в этом дело. Почему-то логика в СУБД и логика где-то еще постоянно противопоставляется друг другу - это не так! Логика должна быть сосредоточена там где ее возможно реализовать максимально эффективно. При этом логика - это не один алгоритм и не два - а намного больше. Что-то будет в БД, что-то нет. Вот здесь и неплохо будет иметь общий знаменатель в лице middle tier'а И еще я думаю, что тот же пример с зарплатой - это как говорят не благодаря, а вопреки...
8 окт 04, 16:48    [1020151]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
Yo!
ЗЫ. как-то никак не вьезжаю в суьб спора, есть дата тиер, он на хп, что может помешать мидл тиеру обращатся к хп не врубаюсь.
Обычно так и бывает, одно другому не мешает.
8 окт 04, 16:49    [1020161]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

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

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


Ну если Вы хоть что-то меняете на клиенте, пусть Вызовы ХП, то на все клиетские компы его надо инсталировать. А их к примеру 2000. А в рекламном лозунге намекается на то, что на клиенте вообще ничего не надо делать. Т.е. если меняется 3 звено, то это затронет 2 и 3. А 1 - нет. А если звеньев 4 и более? Ожидается какая ни на есть независимомсть между не связанными между сабой на прямую звеньями.

Но, наверное, есть признаки усложнения системы в целом. И аппратно и программно, больше разных типов компонентов и между звеньями нужны свои интерфейсы. Это может выразится и в требованиях к квалификации специалистов, участвующих в пректе. Вообще проект может быть дороже при прочих равных условиях. Т.е. если недостатки двухзвенкизвенки имеют небольшое значение в данном проекте, то, наверное, она предпочтительнее. Это похоже на модульную декомпозицию - если при дальнейшей декомпозиции нет улучшения, то она и не нужна. А если есть и значительные, то лучше ее использовать.


Т.е. при прочих равных условиях духзвенка имеет плюсы, особенно, если сюда включать и трехзвенку с WEB сервром. Хотя можно обратить внимание, что просто в настоящее время среднее звено WEB - сервер хорошо освоен, и тот кто почти ничего в нем не смыслит, делает сайты и все такое. И если тоже случится с серверами приложений, то этот плюс двузвенок будет иметь меньшее значение. Т.е., возможно, тогда и их захотят считать двухзвенками.
8 окт 04, 17:20    [1020318]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Но насчет того же dynamic SQL - все знают чего он стоит в DBMS

Я знаю, чего он стоит в MSSQL, но я так же знаю, что он ничего не стоит в Sybase ASA. Или Вы считаете, что он во всех СУБД чего то стоит ?

Логика должна быть сосредоточена там где ее возможно реализовать максимально эффективно.

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

При этом логика - это не один алгоритм и не два - а намного больше. Что-то будет в БД, что-то нет. Вот здесь и неплохо будет иметь общий знаменатель в лице middle tier'а

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

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

У меня полный расчет 1000 сотрудников вместе с налогами и ЕСН на Sybase ASA, запущенный из под обычного ISQL проходит ровно за 3 секунды, причем СУБД крутиться на 32 метрах памяти, не занимает процессорной мощности, продолжает обслуживать пользовательские приложения и одновременно строит HTML-формы строгой отчетности по макетам, возвращая их через веб-сервисы (выступая еще в роли выделенного HTTP сервера), которые спокойно можно открыть через любой браузер, Word или OpenOffice. Плюс обычный клиент, который реализован на PB и ничем кроме как отображения и сохранения информации в БД, а так же создания бандовых отчетов не занимается. Где тут место еще одному звену ?
8 окт 04, 17:21    [1020324]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
ASCRUS
Интересно зачем мне общий знаменатель между хранением и обработкой данных и расчетами ?

Хотя бы для прозрачной интеграции с другими частями системы. Ведь те же web services что были упомянуты - это ведь уже не СУБД (встроенный в ASA HTTP сервер не в счет)

Общим знаменатель у них только один - информация в базе данных.

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

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

Дело в том что это хорошие средства - но уже давно есть и получше! Просто по сути (если упрощать) - спор похож на структурное проектирование vs ООП. Ясно что задачи можно решить и так и так - но у ООП есть некоторые плюсы сделавшие его лидером

У меня полный расчет 1000 сотрудников вместе с налогами и ЕСН на Sybase ASA, запущенный из под обычного ISQL проходит ровно за 3 секунды

заю знаю - и всем это всегда в пример привожу!
8 окт 04, 17:47    [1020434]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Nikolay Kulikov
Member

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

Триггера появились в СУБД ДО появления поддержки декларативной ссылочной целостности.

Неправда ваша, в DB2/390 констрейнты были с самого рождения 20 лет назад.
Первый кто кстати реализовал triggers и SP сдается мне был Informix году эдак в 89.
8 окт 04, 17:51    [1020448]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
автор
Интересно зачем мне общий знаменатель между хранением и обработкой данных и расчетами ?
[scip]
Где тут место еще одному звену ?


берем sybase - 2 субд, одна для отчетов (IQ), другая OLPT (ASA) есть корпоративная система. где у нее знаменатель общее ? в ASA или ASE ?
8 окт 04, 17:58    [1020473]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
тьфу IQ или ASA
8 окт 04, 17:59    [1020477]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
С точки зрения входящих данных общим знаменателем будет ASA, с точки зрения центрального аналитического хранилища данных - IQ. Соотвествующе клиентское приложение не будет писать информацию в IQ, а отчетник для построения аналитики не будет пытаться взять данные со всех удаленных ASA. Опять же - каждый выполняет свою работу и самый самый общий знаменатель тут не нужен.
8 окт 04, 18:04    [1020489]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
в смысле аналитику предлагаете принципиально запрещать работать с OLPT базой ? а если у меня для аналитика и оператора один клиент просто у аналитика что-то запрещено + дополнительная закладка с аналитическими отчетами ... или я принципиально должен делать для каждой роли свой клиент ?
8 окт 04, 18:15    [1020518]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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

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


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

savage79
Обычно так и бывает, одно другому не мешает.

Тогда в чем преимущества? Конкретные преимущества - будем считать, что я прочел книжки но преимуществ многозвенки в конкретно этом примере не нашел.

vadiminfo
Ну если Вы хоть что-то меняете на клиенте, пусть Вызовы ХП, то на все клиетские компы его надо инсталировать. А их к примеру 2000. А в рекламном лозунге намекается на то, что на клиенте вообще ничего не надо делать. Т.е. если меняется 3 звено, то это затронет 2 и 3. А 1 - нет. А если звеньев 4 и более? Ожидается какая ни на есть независимомсть между не связанными между сабой на прямую звеньями.


Ай-ай, совсем не так. Давайте по ситуациям:

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

2. Добавляется колонка в результат, колонку надо вывести на клиента в список. Все действия из п.1 + перекомпиляция клиента и его переинсталляция. И для ХП, и для апп-сервера клиент меняется.

3. А три нет - только два варианта.

Теперь скажите мне, где ваш лозунг? В случае с апп-сервером работы получается больше. Ооопс. Ошибочка вышла с независимостью.

автор
Но, наверное, есть признаки усложнения системы в целом. И аппратно и программно, больше разных типов компонентов и между звеньями нужны свои интерфейсы. Это может выразится и в требованиях к квалификации специалистов, участвующих в пректе. Вообще проект может быть дороже при прочих равных условиях. Т.е. если недостатки двухзвенкизвенки имеют небольшое значение в данном проекте, то, наверное, она предпочтительнее. Это похоже на модульную декомпозицию - если при дальнейшей декомпозиции нет улучшения, то она и не нужна. А если есть и значительные, то лучше ее использовать.


Об чем и разговор!!!

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


Да, точно!

Но тогда что такое многозвенка?
Трехзвенка с вебсервером и например asp.net не является по сути трехзвенкой - это все та же двухзвенка.

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

Об таких многозвенках мы тут и говорим.
Другие многозвенки просто из другой степи.
--------------------

funikovyuri
Хотя бы для прозрачной интеграции с другими частями системы. Ведь те же web services что были упомянуты - это ведь уже не СУБД (встроенный в ASA HTTP сервер не в счет)


А вебсервисам не нужен никакой апп-сервер и их интегрировать ничем другим не надо - они имеют доступ к БД и спокойно с ней работают напрямую. Даже прямо сейчас вот, у нас :)

автор
Дело в том что это хорошие средства - но уже давно есть и получше! Просто по сути (если упрощать) - спор похож на структурное проектирование vs ООП. Ясно что задачи можно решить и так и так - но у ООП есть некоторые плюсы сделавшие его лидером


Про какие средства идет речь? Чем они лучше?

ЗЫ Вопросы без подвохов - спокойно разговариваем по теме.
Я честно - не для подколки, спора, не от того, что фанат двух-звенки - просто честно не понимаю смысла использования многозвенок, если только того не требует ситуация, которая такова, что двухзвенка просто совсем не справляется с поставленной задачей. Никакого злого умысла у меня нет Картинка с другого сайта.

-- Tygra's --
8 окт 04, 18:23    [1020545]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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


Ну запрещать то зачем.

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

У нас к примеру отдельный сервер с кубами, к нему сделан отдельный клиент - потому как совсем по-другому с кубами работать. Кому есть доступ - тот через этого клиента может посмотреть все, что нужно.
На рабочей же базе есть текущие отчеты, открываются из общего клиента. Только обычно они ограничены по периоду - неделей. Чтобы не нагружать рабочий сервер. И я не вижу смысла делать какой-то апп-сервер чтобы совмещать несовместимое. Ведь в принципе "большие" отчеты - это совсем отдельная от текущей работы вещь.

ЗЫ Эххх, пятница, душно, слова забываю, термины..... Срочно пора отдыхать.... О, так уже через 25 минут домой!

-- Tygra's --
8 окт 04, 18:32    [1020561]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
один клиент несколько конекций к разным субд ... некошерно в плане общего знаменателя
8 окт 04, 18:40    [1020574]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
в смысле аналитику предлагаете принципиально запрещать работать с OLPT базой ? а если у меня для аналитика и оператора один клиент просто у аналитика что-то запрещено + дополнительная закладка с аналитическими отчетами ... или я принципиально должен делать для каждой роли свой клиент ?

В смысле, что я ничего не предлагал, Вы задали абстрактный вопрос, я так же абстрактно ответил. Думаю это не повод делать практические выводы о том, что я запрещаю аналитику обращаться к OLTP или что ему нужен обязательно другое клиентское приложение. Есть архитектор проекта, есть выбранная им платформа и способы реализации проекта, с практической точки зрения ни кого не волнует, как и на чем реализован проект - на Оракле или Sybase ASA, на классической 2-х звенке, апп-сервере или на Clipper. Главное на сколько он эффективно работает, какие финансовые затраты были на его разработку и сопровождение и насколько это окупаемо. В итоге любой спор решается примитивным подсчетом в денежном эквиваленте - приносит прибыль, значит платформа и средства его реализации были выбрано правильно, приносит убытки - значит был неправильно выбран архитектор. По такому критерию очень легко сравнивать и оценивать абсолютно любые технологии в разрезах одинаковых задач.
8 окт 04, 18:40    [1020575]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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

Ну это же лучше, чем клиент и апп-сервер с коннектом к разным СУБД :)
Можно разных клиентов, если хочется.

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

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

========
Ну, до понедельника. И главное, чтобы у всех системы работали, особенно в выходные

-- Tygra's --
8 окт 04, 18:53    [1020597]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
2ASCRUS

ну вот видите, скоро мы наконец сойдемся что нет черного или белого :)
8 окт 04, 20:25    [1020744]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

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

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

2. Добавляется колонка в результат, колонку надо вывести на клиента в список. Все действия из п.1 + перекомпиляция клиента и его переинсталляция. И для ХП, и для апп-сервера клиент меняется.

3. А три нет - только два варианта.

Теперь скажите мне, где ваш лозунг? В случае с апп-сервером работы получается больше. Ооопс. Ошибочка вышла с независимостью.

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

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

А Вы еще обратите внимание на то, что это разные вообще клиентские проги могут, а их логика на сервере приложения. Тогда централизованное управление логикой получается.

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

tygra

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

Об таких многозвенках мы тут и говорим.
Другие многозвенки просто из другой степи.



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

Мы здесь обсуждаем двухзвенную и многозвенные архитектуры приложений БД . При этом, трехзвенную архтектуру с сервером приложений считаем традиционной трехзвенной архитектурой. И далее под трехзвенкой понимаем такие приложения БД . А приложения с использованием WEB среды как платформы приложений БД не рассматриваем, если в ней не просматривается явный сервер приложений, считая ее нетрадиционной трехзвенкой - многозвенка из другой степи.
8 окт 04, 20:36    [1020772]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
c127
Guest
>Просто по сути (если упрощать) - спор похож на структурное проектирование vs ООП. Ясно что задачи можно решить и так и так - но у ООП есть некоторые плюсы сделавшие его лидером

Действительно похож. Так во-первых в той же ASA уже давно есть джава, пишите на ней, а во-вторых где это ООП стал лидером? Что-то не наблюдаю явного лидерства, все признаки, что это просто мода. Не аргумент по-моему.

2 vadiminfo

>Ну если Вы хоть что-то меняете на клиенте, пусть Вызовы ХП, то на все клиетские компы его надо инсталировать. А их к примеру 2000.

Так ведь клиент по большому счету не знает, ходит ли он на сервер приложений или в базу. Это значит что Ваш аргумент работает в обоих случаях, в обоих случаях нужно менять 2000 клиентов.

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

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

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

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

Единственное очевидное преимущество - это возможность поставить несколько серверов приложений, равномерно рассовать пользователей по ним и обрабатывать данные параллельно. Но тут сразу возникает немаленькая проблема с синхронизацией кешированных данных. А не кешировать нельзя. Это особенно проблема если пользователи не имеют постоянной сессии (например ходят из интернета) и неизвестно на какой из серверов приложений пользователь попадет в следующий раз. А перечитывать все каждый раз из БД тоже нельзя по вышеупомянутым причинам.
9 окт 04, 12:01    [1021241]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Может сказать проще - многозвенка выгодна лишь в двух случаях:
1)при распределенных транзакциях
2)когда подключений очень много, а логика достаточно проста чтобы вынести ее в среднее звено которое работает с БД через небольшой пул своих соединений.
9 окт 04, 12:13    [1021247]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
автор
Теперь скорости обработки данных. SQL сервера отлаживаются и оптимизируются как раз в плане производительности не один десяток лет. Что-то не верится, что в сервере приложений можно обеспечить большую скорость обработки, ведь в обоих случаях логически одинаковые действия должны быть выполнены над теми же данными, только лежащими не в таблицах, а в массивах или где-то там еще.


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

автор
Это особенно проблема если пользователи не имеют постоянной сессии (например ходят из интернета) и неизвестно на какой из серверов приложений пользователь попадет в следующий раз. А перечитывать все каждый раз из БД тоже нельзя по вышеупомянутым причинам.


вообще-то балансер обычно по хеш функции раскидывает юзеров, т.е. один и тот же всегда на один и тот-же хост попадает. но в принципе никто не мешает их сесии (кеши) хранить на общей файловой системе, тогда вообще по барабану на который хост тебя перекинули.
9 окт 04, 13:24    [1021286]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

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

Так ведь клиент по большому счету не знает, ходит ли он на сервер приложений или в базу.


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

Клиент - Интерфейс пользователя
Сервер приложений: Основная логика приложения, Логика обработки данных
Сервер БД: Контроль данных, Доступ к БД.

В двухзвенной:

Клиент - Интерфейс пользователя, Основная логика обработки данных
Сервер БД: Контроль данных на серверной стороне, Доступ к БД.

Поэтому как бы походы клиента в БД выглядят излишними.
9 окт 04, 13:50    [1021292]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

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

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


Все-таки это удар не по трехзвенкам, а по РСУБД. Сервер приложений можно реализовать без ООП. А вот если РСУБД и объектное описание сущностей были бы взаимоисключающими понятиями, то это не сулило бы нечего хорошего РСУБД в перспективе, поскольку ООП - это несомненно успешная парадигма программирования. Более того, нам с Вами как базистам желательно, чтобы роль данных возрастала по сравнению с процедурами. А в ООП это имеет место. И, кроме того, если хорошо спроектировать и написать иерархию классов, то скорее всего получится приложение, в котором относительно легко будет наращивать относительно сложный функционал.
Вы сами отдаете преимущество Cache. Однако, в двухзвенках используются ООП на клиентской стороне и даже в файл серверной (Access). Более того, есть надежды и на ОРСУБД как перспективы для РСУБД. Т.е. Вы больше предсказали, что будущее за ООСУБД , чем пошатнули позиции многозвенок.
10 окт 04, 02:05    [1021582]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
gardenman
В принципе ASCRUS ответил правильно. Ошибка в триггере еще не значит, что всю транзакцию нужно откатывать. Все зависит от логики приложения.

Да, правильно. А целостность базы данных - это еще не значит, что ее надо поддерживать - все зависит от логики приложения !!!


Вы так договоритесь до такого ...
11 окт 04, 11:38    [1022648]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
tygra
Был недавно не менее "прохладный" топик по поводу использования select-ов прямо из клиента (апп-сервера в этом случае) вместо ХП в БД. Очень уж это странно.

О, Тигра, да ты ж за меня !! А ну давай их всех вместе грррызть !!!
11 окт 04, 11:41    [1022662]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить