Трехслойка vs Двухслойка

← →
vuk © (2006-01-31 15:05) [160]

to Digitman © (31.01.06 12:56) [109]
>СУБД не УПРАВЛЯЕТ т/акциями, а ИСПОЛНЯЕТ команды управления ими !
Таки управляет. Про такую, например, штуку, как уровни изоляции напоминать надо?

to Alex Konshin © (31.01.06 14:18) [135]:
>Есть хороший принцип: разделять код и данные.
Принцип хороший, конечно, но при этом не стоит забывать про такую штуку, как эффективность работы с данными. Тоже принцип ничего себе. Процедуры, они ж не от хорошей жизни, а именно из-за нее, родимой, из-за эффективности.

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

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

>Это требует специальных знаний об этой DBMS
Без знаний о DBMS можно только select * from ... писать.

← →
Sergey13 © (2006-01-31 15:06) [161]

Сори за дубль.
2 [159] Курдль © (31.01.06 15:03)
Я хотел сказать, что файловая система и ОС это НЕ одно и то-же. То, что Оракл может юзать равдевайсы не говорит о том, сам Оракл ставится на голую тачку.

← →
ANB © (2006-01-31 15:18) [162]

> Sergey13 © (31.01.06 15:06) [161]

Хочу вступится за Курдля. Видимо, он имел в виду, что оракл может хранить данные на неформатированных носителях, а не то, что он умеет работать совсем без ОС.

> На Delphi ребята тоже сразу учатся на форму компоненты кидать.
> Ну ты же маленький, знаешь же о чем я говорю. А блокировки?
> А оптимизация запросов?
> Кстати, тестирование ты бы лучше и не упоминал, тут как
> раз-таки у разнородных систем большие проблемы. Спросите
> меня откуда я это знаю (c)

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

← →
msguns © (2006-01-31 15:25) [163]

ИМХО, ураклиды упорно тянут ветку в тупик. Спорить с ними также бесполезно, как с чукчами о тундре.
Давайте что ль подитоживать, а ?
Предлагаю навскидку такую тезису:

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

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

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

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

Основной минус - значительные затраты на поддержание и развитие (особенно) системы.

← →
Курдль © (2006-01-31 15:37) [164]

> msguns © (31.01.06 15:25) [163]

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

← →
Игорь Шевченко © (2006-01-31 15:42) [165]

msguns © (31.01.06 15:25) [163]

> Не поддерживает также централизованное управление (администрирование)
> всем хранилищем данных

Это проблема к трехзвенке не относится, вроде ?

← →
ANB © (2006-01-31 16:04) [166]

> Повторяю, что считаю двухзвенку отличной моделью для любых
> систем, работающих с БД... кроме систем с "удаленным доступом".
>

А что значит "системы с удаленным доступом" ?

← →
ZeroDivide © (2006-01-31 16:13) [167]

> Если переезд с Оракла, то пушка уже стоит. И тогда чего
> бы не жахнуть из нее, чем плодить другие рогатки?
>

Согласен. Погорячился. Мой пост относится лишь к проблеме выбора, но не к проблеме переезда.

А что касается переезда: Либо удобный и простой SQL для конкретной СУБД, либо убогий ANSI SQL для переездов. Трехзвенная архитектура лишь облегчит клиент, но не сделает переезд удобнее.

> И накой Вам этот деревянный запрос, если современные свойства
> отображения сами прекрасно строят "деревья"?

Деревянные данные нужны не только для непосредственного отображения.
Вот пример:

------------------------------------------------------------------- -- Возвращает пути HIERARCHY для подразделения ------------------------------------------------------------------- FUNCTION get_hierarchy_path(p_hierarchy_id IN INTEGER) RETURN VARCHAR2 IS result VARCHAR2(500); BEGIN result := ""; FOR cur IN (SELECT h.division_name FROM HIERARCHY h START WITH h.id = p_hierarchy_id CONNECT BY PRIOR h.parent_id = h.id) LOOP result := ">" || RTRIM(cur.division_name) || result; END LOOP; result := SUBSTR(result, 2, LENGTH(result) - 1); RETURN result; END get_hierarchy_path;

и далее, обыкновенный SQL упрощается до, например, такого:

SELECT get_hierarchy_path(h.ID), h.NAME FROM HIERARCHY h where ID = 1111

← →
Sergey13 © (2006-01-31 16:18) [168]

ИМХО хорошее поле для применения 3х-звенки сопровождение и развитие больших и сложных СУБД построенных на локальных форматах типа ДБейс. Иногда наверное бывает сложно отказаться от них сразу и бесповоротно в пользу СКЛ-серверов - слишком много завязано. А АПП-сервер в этом случае может действительно помочь.

← →
seg (2006-01-31 16:19) [169]

Повторяю, что считаю двухзвенку отличной моделью для любых
> систем, работающих с БД... кроме систем с "удаленным доступом".

Это для тех, кто не может настроить удаленный доступ.

← →
Курдль © (2006-01-31 16:22) [170]

> ZeroDivide © (31.01.06 16:13) [167]

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

← →
ZeroDivide © (2006-01-31 16:25) [171]

Иногда наверное бывает сложно отказаться от них сразу и бесповоротно в пользу СКЛ-серверов

Уже много задач переписали и сразу и бесповоротно запустили.
1. Пишется задача, не спеша и обдуманно
2. Пишется импорт данных.
2.5 Система тестируется на импортированных данных, обучаются люди.
3. Тормозится процесс...
4. Запускается новая система.
5. Запускается процесс...

Все.

← →
euru © (2006-01-31 16:37) [172]

А как же SAP R/3?

Не думаю, что такое было бы возможно на 2-звенке.

← →
Sergey13 © (2006-01-31 16:39) [173]

2[171] ZeroDivide © (31.01.06 16:25)
Это в форум написать быстро. А в жизни? И не про задачи я писал, а про комплексы. Крутится на предприятии какая нить здоровая "бухгалтерия" написанная под ДОС и купленная неизвестно когда и все бухгалтера просто счастливы. Но надо вот стало анализ к бухгалтерии приделать или еще чего. Всю бухгалтерию переписать на СКЛ? Иногда это проще сказать.

ИМХО все исключительно. Витийствую мысленно. 8-)

← →
ZeroDivide © (2006-01-31 16:48) [174]

> А как же SAP R/3?

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

← →
ZeroDivide © (2006-01-31 16:58) [175]

> Но надо вот стало анализ к бухгалтерии приделать или еще
> чего. Всю бухгалтерию переписать на СКЛ?

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

← →
euru © (2006-01-31 17:05) [176]

> ZeroDivide © (31.01.06 16:48) [174]
> Было бы возможно. Но система старая... когда она писалась
> небыло решения лучше, имхо. R/3 использует БД только для хранения данных

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

← →
Danilka © (2006-01-31 17:22) [177]

euru © (31.01.06 17:05) [176]

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

А специалистов-то спросили? А если они хочут зависеть от СУБД? А переносить код никуда не хочут! :)

← →
euru © (2006-01-31 17:41) [178]

> Danilka © (31.01.06 17:22) [177]

Тем хуже для специалистов :) (напр., рынок труда уменьшается).

Не знаю как в других системах, а в SAP R/3 код бизнес-логики абсолютно не зависит ни от операционной системы, ни от СУБД (если, конечно, его специально не затачивать под это).

← →
ANB © (2006-01-31 17:42) [179]

> И замечательно, что только для хранения.

Почему ?

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

← →
ANB © (2006-01-31 17:42) [180]

> а в SAP R/3

То то спецы, которые с ним работают, так его "хвалят"

← →
euru © (2006-01-31 17:56) [181]

> ANB © (31.01.06 17:42) [179]
> В скорости - только проигрыш, т.к. тратися время на перекачку
> данных (в случае с распределенными СП - по сетке), которые
> в случае хранимки за пределы СУБД никогда не вышли бы. Например
> - посчитать сложный баланс, который одним запросом не считается.
> В ХП запустил нужное количество курсоров - и делай что
> хочешь. СП - тот же толстый клиент. А при отсутствии хранимок
> - толстенный и трудномодифицируемый.

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

> То то спецы, которые с ним работают, так его "хвалят"

А что собственно этим спецам не нравится? И почему они тогда не уходят из этой области?

← →
euru © (2006-01-31 17:58) [182]

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

Это недостаток ХП

← →
by © (2006-01-31 18:47) [183]

А может не будем пробовать натягивать все на все?
Может каждая технология имеет свой сектор использования?
Если пишется тот же биллинг, в котором должны быть ответы гарантированы до секунды и меньше, и доступность данных 24*7*365 - то он и пишется под Оракл, с использованием всех его особенностей и фич, тюнингуя на максимум производительности. И куда его переность может понадобится? Только разве что на DB2 и то врядли.
А если пишется CRM с требование установки на большинство (не любую) баз - то можно и поступится временем отклика, там ведь не 50 млн. табличка за месяц будет - и рисовать её в трехзвенке с select * from как основной запрос, да и задвинуть все в объекты.

← →
Sergey Masloff (2006-01-31 20:23) [184]

Я сторонник трехзвенки. Все же как не крути нагрузку она балансировать позволяет и переписывать ничего не надо. Но ВСЯ логика и обработка данных у меня на сервере (ORACLE) в виде пакетов. Проблем с производительностью нет. С масштабируемостью нет абсолютно. Буржуйский аудит подтвердил.

← →
Petr V. Abramov © (2006-01-31 20:29) [185]

> Sergey Masloff (31.01.06 20:23) [184]
> Но ВСЯ логика и обработка данных у меня на сервере (ORACLE) в виде пакетов.
А что же живет в том самом среднем звене? Оно заполнено бальзамом на душу буржуйского аудита? Чтоб он мог сказать, технологии используются самые современные? :)
P.S. не в обиду, а в подъ-ку :)

← →
Sergey Masloff (2006-01-31 20:33) [186]

Petr V. Abramov © (31.01.06 20:29) [185]
Просто труба отдающая курсоры клиенту. Ну и небольшой кеш справочника (он деревянный поэтому один).
Но даже в такой конфигурации нагрузка на сервер значительно снизилась. Мы уже упирались в предел а после перевода части на трехзвенку еще почти в 2 раза подняли юзеров на той же технике.

← →
Petr V. Abramov © (2006-01-31 20:39) [187]

> Sergey Masloff (31.01.06 20:33) [186]
Ну за счет "трубы"-то нагрузка как снизится?

← →
Sergey Masloff (2006-01-31 20:46) [188]

Petr V. Abramov © (31.01.06 20:39) [187]
>Ну за счет "трубы"-то нагрузка как снизится?
Хрен знает. Но факт. Коннектов открытых меньше но на этом вроде не сэкономишь столько...

> Sergey Masloff (31.01.06 20:46) [188]
> Коннектов открытых меньше но на этом вроде не сэкономишь столько...
Ну как сказать... По умолчанию - ~ по мегабайту на лицо :) На курсорах, которые висят открытыми при дельфишной технологии - море памяти

Petr V. Abramov © (31.01.06 20:56) [189]

> На курсорах, которые висят открытыми при дельфишной технологии
> - море памяти

Можно поступиться кораном и закрывать. Аллах простит :)

← →
Sergey Masloff (2006-01-31 22:31) [191]

Игорь Шевченко © (31.01.06 22:23) [190]
Ну операция открытия-закрытия видимо не самая легкая раз так настойчиво советуют пул соединений держать. А так никакого открытия просто клиент к очередной уже открытой трубе припадает без оверхеда. Хотя конечно в два раза экономии взятся вроде и неоткуда...

> Игорь Шевченко © (31.01.06 22:23) [190]
> Можно поступиться кораном
А вот это нельзя. :)
И "оно работает" - не аргумент

> Sergey Masloff (31.01.06 20:33) [186]
> Хотя конечно в два раза экономии взятся вроде и неоткуда...
тогда "нагрузка на что" и "экономия чего" реально получилась?

← →
Sergey Masloff (2006-01-31 22:39) [193]

Petr V. Abramov © (31.01.06 22:36) [192]

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

>>ANB © (31.01.06 10:51) [21]

>Не приставай. Про политику спорить то запретили.
"Ухожу, Марь Иванна. Ухожу, ухожу..." ©
:-))

кстати если СУБД лицензируется на колво одновременных подключений, среднее звено позволяет в несколько раз снизить стоимость владения - моя практика показывает что при 20 клиентах на среднем звене в среднем используется 5 соединений с БД

Polevi © (05.02.06 12:01) [197]
кстати если СУБД лицензируется на колво одновременных подключений, среднее звено позволяет в несколько раз снизить стоимость владения
Я читал в каком то EULA, помоему от MS, что все не так просто, и ситуацию с сервером приложений они оговаривают отдельно. И платить прийдется за количество реальных юзеров. Это как MS Office на терминальном сервере - инсталяция одна, а лицензий нужно столько сколько пользователей.

Polevi © (05.02.06 12:01) [197]
Не касается MS SQL, сколько есть клиентов (устройств), столько и лицензий, хоть один коннект к БД

Трехслойка vs Двухслойка Найти похожие ветки