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

← →
Nikolay M. © (2006-01-31 11:16) [40]

> А если я захочу перейти с Oracle на Informix, например,
> то мне не придется менять код клиента и искать аналог ODAC.

А то, что в любом случае придется переделывать все ХП и апп-сервер - это ничего? Никогда не понимал этого аргумента "легкая смена СУБД". Поднимите руку те, кто разрабатывал трехзвенку на одной СУБД и через некоторое время переписывал с нуля весь апп-сервер и серверную часть ради "легкого переезда на другой сервер". Я хочу просто знать, что такие люди есть и заодно спросить, насколько часто им приходится прыгать между Ораклом, МС СКЛ, Аксессом и тд.

Ситуация, описанная в Reindeer Moss Eater © (31.01.06 10:51) [22] не считается. Если нужна брать данные из качественно разных хранилищ данных, то без промежуточного слоя, который получает эти данные, не обойтись. Не станешь же всем клиентам ставить клиентские части всех использующихся СУБД.

← →
roottim © (2006-01-31 11:16) [41]

+ нет необходимости обновлять парк oraclr client машин, правда если пользуеш ODAC, в этом отпадает необходимость.
+ можеш использовать сторонние источники. Например данные с мсскуля 1С базы.

← →
msguns © (2006-01-31 11:17) [42]

>Игорь Шевченко © (31.01.06 11:04) [36]
>При грамотно написанной трехзвенке - да

При грамотно написанной двухзвенке - тоже да.
Просто логика максимально "убрана" с клиента на SQLServer (в твоем случае - на AppServer)

← →
Digitman © (2006-01-31 11:19) [43]

> seg (31.01.06 10:56) [27]

> на ХП можно вместо долгих запросов использовать курсоры

Речь в дан.сл. идет не о "запросах" (долгих ли там. коротких ли), а о реализации "навороченной" бизнес-логики средствами ХП.

Элементарный "пустой" цикл в ХП будет выполняться заведомо медленнее, нежели в машкоде Апп-сервера.

> ANB © (31.01.06 10:57) [28]

> В чистом виде - да. Но если начинается активная работа с
> SQL, то это еще вопрос, что быстрее. Например, перекачка
> данных отдельными инсертами в пакете выполняется намного
> быстрее, чем через клиента.

Апп-сервер, как ты понимаешь, как раз и является клиентом SQLСУБД-сервера.

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

← →
Danilka © (2006-01-31 11:23) [44]

Sandman29 © (31.01.06 11:01) [32]

> СП добавляет новый уровень безопасности. Безопасность на уровне
> пользователей никто не отменял. Все, иду работать :)

Кажись наоборот, в любых системах дополнительное звено уменьшает надежность системы вцелом.

← →
msguns © (2006-01-31 11:25) [45]

>Nikolay M. © (31.01.06 11:16) [40]

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

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

← →
Sandman29 © (2006-01-31 11:27) [46]

ANB © (31.01.06 11:04) [35]

Какой уровень безопасности добавляет СП, которого нет в оракле ?

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

← →
Игорь Шевченко © (2006-01-31 11:29) [47]

msguns © (31.01.06 11:05) [38]

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

← →
seg (2006-01-31 11:30) [48]

Элементарный "пустой" цикл в ХП будет выполняться заведомо медленнее, нежели в машкоде Апп-сервера.

Один криво написанный запрос сведет на нет все преимущества машкодов.
Я уже писал о техзвенке, у которой формы открывались по 15-20 минут.

← →
Sandman29 © (2006-01-31 11:31) [49]

Nikolay M. © (31.01.06 11:16) [40]

А то, что в любом случае придется переделывать все ХП и апп-сервер - это ничего? Никогда не понимал этого аргумента "легкая смена СУБД". Поднимите руку те, кто разрабатывал трехзвенку на одной СУБД и через некоторое время переписывал с нуля весь апп-сервер и серверную часть ради "легкого переезда на другой сервер". Я хочу просто знать, что такие люди есть и заодно спросить, насколько часто им приходится прыгать между Ораклом, МС СКЛ, Аксессом и тд.

Передо мной как раз сейчас стоит такая задача :)

← →
msguns © (2006-01-31 11:31) [50]

>Игорь Шевченко © (31.01.06 11:29) [47]
>Задачи, они разные бывают. Бывают такие задачи, которые невыгодно переделывать каждый раз при увеличении количества клиентов или в которых невыгодно покупать дорогой аппарат при, опять же, увеличении количества клиентов.

Ну это все, конечно, кульно, рульно и скульно. Тока опять же зависит от кривизны рук и прямолинейности мозгов, но никак не от количетва звеньев в цепи ;)

← →
seg (2006-01-31 11:31) [51]

реализации "навороченной" бизнес-логики средствами ХП.

Кстати и всю бизнес-логику в этой системе реализовали на клиенте.
Не говоря уже о геморе с самим Арр-сервером.

← →
Sandman29 © (2006-01-31 11:33) [52]

msguns © (31.01.06 11:25) [45]

Очень верно всё поняли и опасали. Типов клиентских приложений у нас несколько десятков, переписывать все очень не хочется.

← →
Sergey13 © (2006-01-31 11:33) [53]

2 [46] Sandman29 © (31.01.06 11:27)
> Предприятия хотят обмениваться кое-какой информацией друг с другом.
А не проще будет по мылу посылать некий файл(ы) понятного обоим формата?

← →
Sandman29 © (2006-01-31 11:34) [54]

Danilka © (31.01.06 11:23) [44]

Ты прав, конечно. Но не мешай, дай поспорить :)

← →
Игорь Шевченко © (2006-01-31 11:34) [55]

msguns © (31.01.06 11:17) [42]

> При грамотно написанной двухзвенке - тоже да.

"Традиционная схема клиент-сервер проста: клиент посылает запросы, а сервер на них отвечает. Поскольку клиент и сервер часто представлены разными компьютерами, они способны расщеплять - или разделять - вычислительную нагрузку, что позволяет выполнять работу быстрее. Клиент осуществляет интерфейс и взаимодействие с пользователем. Сервер (обычно сервер баз данных) обрабатывает запросы клиента. Большинство разработок систем клиент-сервер относятся к этой традиционной двухзвенной модели.
Но хотя двухзвенная модель клиент-сервер прекрасно подходит для небольших программ на уровне рабочей группы при числе пользователей менее 100 (конечно в зависимости от того, что делают прикладные программы), в большинстве двухзвенных систем невозможно существенно увеличить это число. Операционная система сервера оказывается настолько загруженной управлением многочисленными подключениями к серверу, что просто "умирает от истощения".
Трехзвенная модель решает проблемы масштабируемости. При использовании трехзвенной модели помимо клиента и сервера есть еще и дополнительное промежуточное звено, которое управляет транзакциями намного эффективнее. Это позволяет разработчикам расширять свои системы до уровня предприятия. "

http://astu.secna.ru/russian/students/personal/52ts&52do/glava3.htm

← →
Курдль © (2006-01-31 11:38) [56]

> Есть ли хоть какие нибудь аргументы, говорящие в пользу
> трехслойки ?

Достаточно одного слова "интернет".

← →
Nikolay M. © (2006-01-31 11:39) [57]

> msguns © (31.01.06 11:25) [45]

Вот я и хочу сказать, что слова "легкий переезд на другую СУБД", особенно если это единственный аргумент, являются скорее поводом делать клиент-сервер, а не многозвенку. Написать нового клиента и обновить даже сотню клиентских мест может быть менее трудозатратным, чем переписать весь апп-сервер. Особенно если есть возможность сделать клиентский слой не более чем GUI-ем, а всю логику реализовать на ХП.
Да что там смена СУБД, я знаю кучу случаев, когда люди не рисковали переезжать с МС СКЛ 7.0 на 2000, не то что на другую СУБД.

← →
Nikolay M. © (2006-01-31 11:42) [58]

> Sandman29 © (31.01.06 11:31) [49]
> Передо мной как раз сейчас стоит такая задача :)

И насколько легче будет переписать аппсервер по сравнению с переписыванием клиентских приложений? Сколько человек будет этим заниматься?

← →
Sergey13 © (2006-01-31 11:43) [59]

2[57] Nikolay M. © (31.01.06 11:39)
Согласен, но тут есть маленький нюанс. Если пишется "коробочный" продукт, то может быть оправданным его изначальная заточка под разные БД.
ИМХО.

← →
msguns © (2006-01-31 11:45) [60]

>Игорь Шевченко © (31.01.06 11:34) [55]

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

← →
Курдль © (2006-01-31 11:45) [61]

> Nikolay M. © (31.01.06 11:39) [57]

Недавно нами был переведен на другую СУБД (ASA -> oracle) крупный проект (несколько тысяч исходных файлов, дюжина проектов в одном решении).
Если бы бизнес-логика писалась на уровне СУБД (ХП, триггеры), скорее всего перевод проекта бы не состоялся никогда!
Так что изначальное решение писать трехзвенку оказалось архиправильным!

← →
Danilka © (2006-01-31 11:47) [62]

Игорь Шевченко © (31.01.06 11:34) [55]
> Но хотя двухзвенная модель клиент-сервер прекрасно подходит
> для небольших программ на уровне рабочей группы при числе
> пользователей менее 100 (конечно в зависимости от того,
> что делают прикладные программы), в большинстве двухзвенных
> систем невозможно существенно увеличить это число. Операционная
> система сервера оказывается настолько загруженной управлением
> многочисленными подключениями к серверу, что просто "умирает
> от истощения".

ЭЭЭ. Ежели к Ороклу будет более 100 одновременных подключений, то операционная система сервера, на котором установлен Орокол, "умрет от истощения"? Я правильно понял данный абзац? :)

← →
Игорь Шевченко © (2006-01-31 11:50) [63]

msguns © (31.01.06 11:45) [60]

Я писал про масштабируемость. Кроме того, у трехзвенки есть и другие плюсы (и минусы), о которых народ в ветке писал. Я же не призываю всех переходить на многозвенку, верно ? :)

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

← →
msguns © (2006-01-31 11:50) [64]

>Sergey13 © (31.01.06 11:43) [59]
>Согласен, но тут есть маленький нюанс. Если пишется "коробочный" продукт, то может быть оправданным его изначальная заточка под разные БД.
ИМХО.

Во ! Первая реплика не мальчика, но мужа в пользу 3 звена ;)
Тот же Парус, например, неализован и как локальный, и как скльный вариант. При этом "клиенты практически одни те те. Именно за счет аппсервера, запрятанного в таинственное "ядро".

← →
ANB © (2006-01-31 11:55) [65]

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

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

> "Традиционная схема клиент-сервер проста: клиент посылает
> запросы, а сервер на них отвечает. Поскольку клиент и сервер
> часто представлены разными компьютерами, они способны расщеплять
> - или разделять - вычислительную нагрузку, что позволяет
> выполнять работу быстрее. Клиент осуществляет интерфейс
> и взаимодействие с пользователем. Сервер (обычно сервер
> баз данных) обрабатывает запросы клиента. Большинство разработок
> систем клиент-сервер относятся к этой традиционной двухзвенной
> модели.
> Но хотя двухзвенная модель клиент-сервер прекрасно подходит
> для небольших программ на уровне рабочей группы при числе
> пользователей менее 100 (конечно в зависимости от того,
> что делают прикладные программы), в большинстве двухзвенных
> систем невозможно существенно увеличить это число. Операционная
> система сервера оказывается настолько загруженной управлением
> многочисленными подключениями к серверу, что просто "умирает
> от истощения".
> Трехзвенная модель решает проблемы масштабируемости.
> При использовании трехзвенной модели помимо клиента
> и сервера есть еще и дополнительное промежуточное звено,
> которое управляет транзакциями намного эффективнее. Это
> позволяет разработчикам расширять свои системы до уровня
> предприятия. "

Писал это человек, не знакомый с ораклом.

> другую СУБД (ASA -> oracle)

Надо было сразу под оракл писать и не парится. Вопрос не стоит о других СУБД. Интересно, вы тестирование этого всего переведенного уже закончили ?

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

Напряженно привести ситуевину, которую нельзя разрешить на оракле.

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

← →
ANB © (2006-01-31 11:57) [66]

> Тот же Парус

Парус - жуткий отстой и тормоз.

← →
msguns © (2006-01-31 12:00) [67]

>Игорь Шевченко © (31.01.06 11:50) [63]

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

Это лет 10 назад, когда какой-нибудь пень 200-й тужился, обрабатывая запрос на выборку из "лимонной" базы, апп был нужен больше как промежуточное хранилище, буфер, чем алгоритмизатор. Он реально облегчал работу тому самому пню, "подсовывая" ему нужное.
Сегодня же клиент запрсто может справится сам со всем, что для него делал аппсервер.
Другое дело - технологические завязки, упомянутые Серегой13. Вот это АРГУМЕНТ.

ЗЫ. Речь, насколько я понимаю, идет в основном о ERP- подобных системах для корпоративных и меньше нужд ?

← →
seg (2006-01-31 12:01) [68]

При этом "клиенты практически одни те те. Именно за счет аппсервера, запрятанного в таинственное "ядро".

А что мешает запихать ядро в ХП?
Мне уже приходилось писать клиента (таинственное ядро), работающего на SQL-server и Oracle.
В результате невозможно использовать все достоинства того и другого сервера. Получается, что можно писать только простые запросы, понятные обоим серверам, а если надо сделать более сложный запрос, то надо писать 2 версии - по одной для каждого сервера.
При создании хранимых процедур, надо учитывать входные/выходные параметры, их типы да и сами вызовы процедур бывают разные.

> 3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят

1С 8.0 - трехзвенка. У меня клиентское приложение работает на машине С-2,4 Ггц, с памятью 256 МБ. Такое торможение, что я вижу весь процесс отрисовки GUI.

> ANB © (31.01.06 11:55) [65]
> Надо было сразу под оракл писать и не парится. Вопрос не
> стоит о других СУБД. Интересно, вы тестирование этого всего
> переведенного уже закончили ?

Заказчик начинал с малого. Потом аппетиты разрастались.
Тестирование закончили. На то есть тестеры, тест-кейсы и реальные юзеры.

Однако, многие запросы (select-ы) пришлось переписать. Но в большинстве случаев достаточно было простого "Find/Replace" некоторых зарезервированных слов типа NVL вместо IsNull и т.п. по мелочам. Здесь тоже сыграло роль здравое начинание - писать по максимуме на ANSI SQL.

← →
seg (2006-01-31 12:06) [72]

Парус - жуткий отстой и тормоз.

Это понятно, ведь получив запрос от клиента, ему сначала надо разобраться, с каким сервером он работает, чтобы сгенерить правильный запрос и правильно обработать полученный результат.
Кстати, а сколько весит Парусовский тонкий клиент?

← →
seg (2006-01-31 12:08) [73]

Интернет.

Какие проблемы?
на PL/SQL можно разработать Web портал.

>seg (31.01.06 12:01) [68]
>А что мешает запихать ядро в ХП?

Читай внимательнее.
В "локальном" варианте нет никаких хп. Ибо нет никакого склсервера. Есть дибэйзные файлы.

> msguns © (31.01.06 12:05) [71]
> >Напряженно привести ситуевину, которую нельзя разрешить
> на оракле.
> Интернет.

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

msguns © (31.01.06 12:00) [67]

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

Вот уж фиги с маслом, насчет "делает по производительности". Кроме того, существует пропускная способность сети.

> Sergey13 © (31.01.06 11:43) [59]

А это вообще попахивает ночным кошмаром. Вот Диасофт 5NT, например, умеет работать на MS SQL и Sybase ASE, потому что это довольно близкие СУБД, но все равно я думаю, что разработчики ведут 2 версии программы под каждую СУБД. Ну, если я ошибаюсь, они так вылизывают SQL-запросы, чтобы те работали в обоих случаях, но, как следствие, такие запросы далеки от оптимальных.
Хотел бы я посмотреть на программу, на коробке которой было написано "для Access/MySQL/MS SQL/Cache" :)

> Курдль © (31.01.06 11:45) [61]
> Если бы бизнес-логика писалась на уровне СУБД (ХП, триггеры),
> скорее всего перевод проекта бы не состоялся никогда!

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

> Nikolay M. © (31.01.06 12:14) [77]
> разработчики ведут 2 версии программы под каждую СУБД. Ну,
> если я ошибаюсь, они так вылизывают SQL-запросы, чтобы
> те работали в обоих случаях, но, как следствие, такие запросы
> далеки от оптимальных.

Вы хотите сказать, что left outer join работает менее оптимально, чем *= или = (+)?

Nikolay M. © (31.01.06 12:14) [77]
написано "для Access/MySQL/MS SQL/Cache" :)
SalesLogix 5.2
Interbase, MsSql, Oracle

> Вот Диасофт 5NT, например, умеет работать на MS SQL и
> Sybase ASE,

У них встроенный макроязык. разницей Sybase/Ms програмисты не парятся. Ну кроме ограничений использования мелкомягкого exec(<строка>)

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