Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Какую технологию выбрать для трехзвенки? [D6, FB 1.0]

Страницы: < 1 2 3 4 5 6 >
Andriano © (2003-09-17 09:23:00)

Есть 8 компьютеров в одной сети Интранет с каналами минимум 64кбит/с.
Требуется написать упрощенный оперативный торговский учет.

1.Если тонким клиентом будет Web-браузер, то придется много разбираться с Java или HTML (синтаксис и доступ к данным).
2.Есть ещё возможность использовать Remoute Data Module.

Привык использовать компоненты FIB plus. Получается, чтобы использовать все наработки и опыт, да и вообще писать в любимой среде Delphi, придется выбрать 2-ой вариант. Насколько это надежно и безглючно?

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

Кто писал трехзвенку, поделитесь опытом.

Anatoly Podgoretsky (2003-09-17 11:28:00) [81]

Vlad © (17.09.03 11:16) [26]
Конечно нет, это просто побочный эффект.

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

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

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

Дает гибкость за счет сложности.

Да и суть отражена в самом названии три (много) звеньев. Трехзвенка частный случай названия, многозвенка общий случай.

Reindeer Moss Eater (2003-09-17 11:28:00) [82]

Romkin ©
Ты рассуждаешь про сохранность при выполнении операций (даже не про надежность хранения).
А я рассуждаю про надежность системы.
Так вот надежность системы файлсервера выше надежности системы Клиент-Сервер.

я говорю именно о физической структуре базы.
И те и другие хранят свои данные на жестких дисках, которые ничего не знают про сами системы, и обслуживаются ОС.

Sandman25 (2003-09-17 11:25:00) [83]

Romkin

Ясно.

Romkin (2003-09-17 11:22:00) [84]

2Reindeer Moss Eater Парадокс в том, что это не так! Просто надежность системы неотделима от технологии, в ней применяющейся.
Сервер БД предусматривает средства для контроля целостности базы, причем такие, которые невозможно реализовать в случае файловой системы. (Это не ссылочная целостность и тд, я говорю именно о физической структуре базы). ТАкже и трехзвенка может отличаться от двухзвенки как боинг от лексуса :)))
2Sandman25 Ага, локальная база. А остальные клиенты тоже каждый со своей базой? :) Тут принцип именно в том, что место обработки данных выбирается произвольно. Для клиента, как правило, объем расчетов выбирается от двухзвенного клиента (много) до плоского клиента (только показывает, браузер, например). Если хочется считать больше, чем в двухзвенке, то увы, придется кропотливо переносить расчеты из БД на клиент, как и в двухзвенке.

Vlad (2003-09-17 11:16:00) [85]

>Anatoly Podgoretsky © (17.09.03 11:11) [24]
Защита сервера БД от посягательств клиента, путем введения промежуточного звена ? Это вы имеете ввиду ? Ну это, думаю, тоже не самое основное преимущество трехзвенки. Это можно сделать и другими средствами.

Anatoly Podgoretsky (2003-09-17 11:13:00) [86]

Vlad © (17.09.03 10:56) [18]
Как раз я не знаю, поскольку не использую. Но общии положения базовых технологий всегда знать полезно.

Sandman25 (2003-09-17 11:11:00) [87]

[21] Romkin © (17.09.03 11:06)
>Ничто не мешает и на клиента их перенести, ничто не мешает и сервер сделать невыделенным, вместе с клиентом...

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

Reindeer Moss Eater (2003-09-17 11:11:00) [88]

клиент-сервер менее надежен, чем файл-сервер :)
Парадокс, но это так! :) (Не логическая целостность прикладных данных, а как система)

Anatoly Podgoretsky (2003-09-17 11:11:00) [89]

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

Romkin (2003-09-17 11:06:00) [90]

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

Reindeer Moss Eater (2003-09-17 11:05:00) [91]

Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...

Клиент-сервер и файл сервер сожержат принципиально разные компоненты. Это как один запорожец и один лексус.
Трехзвенка и двузвенка имеют 2 почти идентичных компонента плюс в трехзвенке одно дополнительное звено.
Так что все верно.

У меня при юзании IB трафик между клиентом и сервером приложений был 56 КБайт (самая массивная операция), сжимался модемом на 60 % а между сервером приложений и IB та же самая операция уже 1.2 Гб (правда, сжатие на 80%). Вот и прикинуть можно.

Ну модем и сжатие данных - это не принадлежность исключительно той или иной технологии. У АДО и SQLlinks тоже трафик различный, но это не значит, что изобретались они именно для снижения трафика.

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

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

Vlad (2003-09-17 10:56:00) [92]

>app © (17.09.03 10:47) [15]
Да уж, кому как не Вам знать об этом все от и до! :)

Romkin (2003-09-17 10:56:00) [93]

2Reindeer Moss Eater
>Система из трех компонентов не может быть надежнее системы из двух компонентов по определению.
Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...
И трафик минимизируется, достаточно его замерить. По нескольким причинам, кстати. У меня при юзании IB трафик между клиентом и сервером приложений был 56 КБайт (самая массивная операция), сжимался модемом на 60 % а между сервером приложений и IB та же самая операция уже 1.2 Гб (правда, сжатие на 80%). Вот и прикинуть можно.
Получается так во-первых, потому, что в MIDAS передача пакетная, и пакеты весьма компактны, а во-вторых, достаточная доля данных просто не доходит до клиента, не нужны ему данные для расчета, только то, что видеть надо. В-третьих, уж выбор по минимизации трафика гораздо шире, мне постоянно выбирать приходится, как минимум, между количеством обращений к серверу и размером данных

Sandman25 (2003-09-17 10:53:00) [94]

[15] app © (17.09.03 10:47)

>изоляция клиента от БД

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

Sandman25 (2003-09-17 10:49:00) [95]

[14] Vlad © (17.09.03 10:41)

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

app (2003-09-17 10:47:00) [96]

Основное назначение изоляция клиента от БД, остальное все в придачу и трафик и процее. Бизнес правила делаются на промежуточном звене. При отсутствии безнес правил не получается даже разгрузки БД

Vlad (2003-09-17 10:41:00) [97]

>Sandman25 © (17.09.03 10:33) [12]
>сервером приложений служит сервер БД
В этом случае единственный выигрыш может быть, как сказал Reindeer Moss Eater, в облегчении клиента.
Поскольку сервер БД - один (если не кластерная система) и несколько App-серверов внутри него в параллель не поставишь :)

Vlad (2003-09-17 10:38:00) [98]

>Reindeer Moss Eater © (17.09.03 10:29) [11]
Согласен,трафик тут совсем не причем.

>Andriano (17.09.03 09:23)
Почему бы не использовать в качестве упрощения COM/DCOM, коль сеть локальная ? MIDAS в Дельфи неплохо с этим справляется, я вроде лично пользовался...

Sandman25 (2003-09-17 10:33:00) [99]
Vlad & Reindeer Moss Eater

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

Reindeer Moss Eater (2003-09-17 10:29:00) [100]

Vlad ©

Ну значит бизнес правила в середине - основное назначение, а не облегчение клиента.

Но только не минимизация трафика.

Страницы: < 1 2 3 4 5 6 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »