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

← →
ANB © (2006-01-31 10:15) [0]

Есть ли хоть какие нибудь аргументы, говорящие в пользу трехслойки ?
СУБД, есно, Оракл.

Имхо :
Трехслойку тяжелее писать и труднее сопровождать. А преимуществ нету.

← →
by © (2006-01-31 10:27) [1]

В свое время я писал одно трехзвенное приложение что бы упростить установку клиентской части, так как на клиенте не нужно было бы настраивать BDE и пр. Но сейчас есть компоненты доступа которые работают и без клиента Oracle (тот же ODAC).
Еще одним аргументом было то что при трехзвенке лучше выполняются операции типа расчета амортизации, когда нужно перелопатить данные и получить результат, на клиента это тянуть не хочется.
Но опять же, в случае Oracle это красиво запихивается в пакеты.
Я сейчас пишу только клиент-сервер для Oracle.
Трехзвенка нужна тогда, наверное, если к одной логике хочется прилепить и rich клиент и web интерфейс.
Но опять же, в случае Oracle с web отлично справляется iAS.
Так что пока обойдемся двухзвенкой.

← →
Карелин Артем © (2006-01-31 10:28) [2]

Более тонкое управление клиентами и их правами, меньше нагрузки на клиента.
3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят.

← →
unknown © (2006-01-31 10:32) [3]

У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи
(128 кб всего)

← →
seg (2006-01-31 10:35) [4]

У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи
(128 кб всего)

Может дешевле более быстрый канал оплатить?

← →
Sandman29 © (2006-01-31 10:37) [5]

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

← →
ANB © (2006-01-31 10:37) [6]

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

1. Тонкое управление доступом прекрасно делается на уровне пакетов оракла и динамического SQL с возвратом на клиента курсора
2. Очень тонкий клиент типа броузера IE прекрасно и легко пишется на PL/SQL. Тут тогда вообще однослойка получается.

← →
by © (2006-01-31 10:38) [7]

unknown © (31.01.06 10:32) [3]
У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи
(128 кб всего)
А сколько клиентов то? У нас биллинг на 128к при десятке клиентов пристойно работал и на клиент сервере - естесвенно вся логика в пакетах сервера.

← →
unknown © (2006-01-31 10:39) [8]

>seg (31.01.06 10:35) [4]
Да нет, к сожалению, не дешевле.
Это радио канал между двумя городами.

← →
Игорь Шевченко © (2006-01-31 10:39) [9]

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

Масштабируемость

← →
seg (2006-01-31 10:39) [10]

1. Тонкое управление доступом прекрасно делается на уровне пакетов оракла и динамического SQL с возвратом на клиента курсора
2. Очень тонкий клиент типа броузера IE прекрасно и легко пишется на PL/SQL. Тут тогда вообще однослойка получается.

Абсолютно согласен.
2-х звенка и web интерфейс на PL/SQL рулят адназначна и запихивают в ж.. всякие .NET технологии.

← →
ANB © (2006-01-31 10:41) [11]

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

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

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

Да нет, к сожалению, не дешевле.

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

← →
Reindeer Moss Eater © (2006-01-31 10:42) [13]

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

В чем они рулят-то?
Функционала чуть, зато html тэгов на единицу полезных данных - вагон и маленькая тележка.

← →
unknown © (2006-01-31 10:43) [14]

>by © (31.01.06 10:38) [7]
Клиентов в пределах 30-ти, в клиент-серверном варианте траффика набегает
в пределах 3 Гб в месяц (на каждого клиента).
В разрабатываемом варианте раза в 4 меньше.

← →
ANB © (2006-01-31 10:43) [15]

> Масштабируемость

А у двухслойки нет масштабируемости (если грамотно писать, есно) ?

> Да нет, к сожалению, не дешевле.
> Это радио канал между двумя городами.

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

← →
Lamer@fools.ua © (2006-01-31 10:47) [16]

Про n-tier флейма уже достаточно понаписано. Например, здесь:
http://sql.ru/forum/actualthread.aspx?tid=214017&pg=1

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

ANB © (31.01.06 10:43) [15]

> А у двухслойки нет масштабируемости (если грамотно писать,
> есно) ?

Нет. А откуда она возьмется ?

← →
Sandman29 © (2006-01-31 10:47) [18]

ANB © (31.01.06 10:41) [11]

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

Все равно известно, где первая БД, которую можно взломать. А в трехзвенке вообще непонятно, есть ли БД как таковая :)
А если я захочу перейти с Oracle на Informix, например, то мне не придется менять код клиента и искать аналог ODAC.

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

А я и не писал про логику в СП. СП может заниматься только тем, что дергать нужные ХП. Названия и параметры ХП, кстати, тоже будут неизвестны злоумышленникам.

← →
ANB © (2006-01-31 10:48) [19]

> unknown © (31.01.06 10:43) [14]

PACKAGE utl_tcp. И не надо среднего звена.

> Reindeer Moss Eater © (31.01.06 10:42) [13]
> 3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят.
>
> В чем они рулят-то?
> Функционала чуть, зато html тэгов на единицу полезных данных
> - вагон и маленькая тележка.

Присоединяюсь. На Web можно просмотрялки, магазины делать. Но если посадить за такую прогу нормального оператора с большим документооборотом, он повесится от тормозов и неудобства.

← →
Digitman © (2006-01-31 10:49) [20]

> ANB © (31.01.06 10:41) [11]

Не забывай, что хранимые процедуры интерпретируются ядром сервера (точней интерпретируется некий промежуточный код, полученный в рез-те прекомпиляции сервером текста ХП), в то время как исп.код AppServer"а может быть нативным машкодом.

Интерпретирующие же системы всегда проигрывают в производительности нативным системам.

← →
ANB © (2006-01-31 10:51) [21]

> Lamer@fools.ua © (31.01.06 10:47) [16]

Не приставай. Про политику спорить то запретили.

> Нет. А откуда она возьмется ?

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

← →
Reindeer Moss Eater © (2006-01-31 10:51) [22]

Я реально не смог обойтись без трехзвенки когда потребовалось обеспечить одновременный доступ к нескольким (вообще любым) серверам раскиданным по всей корпоративной сети.

← →
roottim © (2006-01-31 10:52) [23]

Функционала чуть, зато html тэгов на единицу полезных данных

AJAX, DHTML, SOAP, XML-RPC решает указанные роблемы и фактически делает web почти gui приложением

← →
Sandman29 © (2006-01-31 10:53) [24]

Reindeer Moss Eater © (31.01.06 10:51) [22]

+ если хранить часть данных не в БД, а в виде файлов, то не приходится давать всем встречным доступ к хранилищам

← →
Игорь Шевченко © (2006-01-31 10:54) [25]

ANB © (31.01.06 10:51) [21]

> Можно поподробнее, чего можно сделать такого в треслойке,
> чего нельзя в двухслойке ?

Запустить большее количество клиентов без необходимости смены аппаратной платформы

← →
Sergey13 © (2006-01-31 10:54) [26]

2 [3] unknown © (31.01.06 10:32)
>У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи(128 кб всего)

Не факт, что 3-звенка решит эту проблему. Автоматом точно не решит. ИМХО.

← →
seg (2006-01-31 10:56) [27]

что хранимые процедуры интерпретируются ядром сервера (точней интерпретируется некий промежуточный код, полученный в рез-те прекомпиляции сервером текста ХП),

Но на ХП можно вместо долгих запросов использовать курсоры, которые ускоряют работу в сотни раз!

← →
ANB © (2006-01-31 10:57) [28]

> Все равно известно, где первая БД, которую можно взломать.
> А в трехзвенке вообще непонятно, есть ли БД как таковая
> :)
> А если я захочу перейти с Oracle на Informix, например,
> то мне не придется менять код клиента и искать аналог ODAC.
>

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

> А я и не писал про логику в СП. СП может заниматься только
> тем, что дергать нужные ХП. Названия и параметры ХП, кстати,
> тоже будут неизвестны злоумышленникам.

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

> Интерпретирующие же системы всегда проигрывают в производительности
> нативным системам.

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

← →
ANB © (2006-01-31 10:58) [29]

> Reindeer Moss Eater © (31.01.06 10:51) [22]

DB Link рулит

← →
Reindeer Moss Eater © (2006-01-31 10:59) [30]

AJAX, DHTML, SOAP, XML-RPC решает указанные роблемы и фактически делает web почти gui приложением

И ради чего такой компот из множества разнородных средств?
Что бы иметь функционал слегка приближающийся с gui?
Стоимость поддержки по сравнению с двузвенкой будет выше.

← →
seg (2006-01-31 10:59) [31]

Не факт, что 3-звенка решит эту проблему. Автоматом точно не решит. ИМХО.

Согласен. Сталкивался с такой 3-х звенкой, вкоторй формы открывались по 15-20 минут!
Запускаешь открытие формы и идешь на обед.
Все дело оказалось в отвратительно спроектированной базе.

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

ANB © (31.01.06 10:57) [28]

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

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

>
> Игорь Шевченко © (31.01.06 10:54) [25]
Запустить большее количество клиентов без необходимости смены аппаратной платформы

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

← →
Reindeer Moss Eater © (2006-01-31 11:01) [34]

DB Link рулит

Это дырка в безопастности.

← →
ANB © (2006-01-31 11:04) [35]

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

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

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

ANB © (31.01.06 11:01) [33]

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

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

← →
ANB © (2006-01-31 11:04) [37]

> Reindeer Moss Eater © (31.01.06 11:01) [34]

Смотря как настраивать.

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

>Игорь Шевченко © (31.01.06 10:54) [25]
>Запустить большее количество клиентов без необходимости смены аппаратной платформы

И что ? Каким боком к этому относится дилемма два/три звена ?

← →
ANB © (2006-01-31 11:06) [39]

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

Ну и если сервер приложений начал тормозить, то чего делать, чтобы быстрее заработал ?

← →
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 версии - по одной для каждого сервера.
При создании хранимых процедур, надо учитывать входные/выходные параметры, их типы да и сами вызовы процедур бывают разные.

← →
Тульский © (2006-01-31 12:03) [69]

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

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

← →
Курдль © (2006-01-31 12:04) [70]

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

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

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

← →
msguns © (2006-01-31 12:05) [71]

>ANB © (31.01.06 11:55) [65]
>Напряженно привести ситуевину, которую нельзя разрешить на оракле.

Интернет.

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

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

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

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

Интернет.

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

← →
msguns © (2006-01-31 12:08) [74]

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

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

← →
Курдль © (2006-01-31 12:08) [75]

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

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

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

msguns © (31.01.06 12:00) [67]

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

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

← →
Nikolay M. © (2006-01-31 12:14) [77]

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

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

← →
Nikolay M. © (2006-01-31 12:17) [78]

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

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

← →
Курдль © (2006-01-31 12:18) [79]

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

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

← →
paul_k © (2006-01-31 12:21) [80]

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(<строка>)

← →
Курдль © (2006-01-31 12:21) [81]

> Nikolay M. © (31.01.06 12:17) [78]
> Опять же все зависит от того, как писать. Если логика лежит
> частично в тригерах, частично в ХП и никак недокументирована,
> то тут за счастье поддерживать костыли, чтобы все это не
> рухнуло, не то что на другую СУБД перейти.

Да будь она хоть трижды документирована, ее пришлось бы перепроектировать, а логику апп-сервера достаточно было просто адаптировать.

← →
ANB © (2006-01-31 12:22) [82]

> Здесь тоже сыграло роль здравое начинание - писать по максимуме
> на ANSI SQL.

1. Сильно урезаются возможности
2. Увеличиваются тормоза

← →
Nikolay M. © (2006-01-31 12:23) [83]

> paul_k © (31.01.06 12:21) [80]

Буду знать. Сам в Диасофте, случайно, не работал? :)

← →
Nikolay M. © (2006-01-31 12:26) [84]

> Курдль © (31.01.06 12:18) [79]
> Вы хотите сказать, что left outer join работает менее оптимально,
> чем *= или = (+)?

Нет. T-SQL MS SQL-я позволяет, например, указывать в хинтах несколько индексов, обязательных к использованию в запросе, а в Sybase - только один. И таких нюансов - море.

← →
Dok_3D © (2006-01-31 12:26) [85]

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

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

Но масштабировать такие системы и правда проще, что греха таить ...

← →
Курдль © (2006-01-31 12:27) [86]

> ANB © (31.01.06 12:22) [82]
> 1. Сильно урезаются возможности
> 2. Увеличиваются тормоза

1. Какие возможности сильно урезаются? ... connect by prior? И все?
2. Практика не показала увеличения тормозов, сопоставимых с пропускной спостбностью каналов (особенно внешних).

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

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

Этот синтаксис поддерживается, а вот такие функции как NVL, DECODE, не говоря уже о пакетах есть только в Oracle. Попробуй написать сложный запрос, который одинаково бы работал на SQL и Oracle.

← →
ANB © (2006-01-31 12:29) [88]

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

Целая куча пакетов даже в 8, которая работает с интернетом

← →
paul_k © (2006-01-31 12:29) [89]

Nikolay M. © (31.01.06 12:23) [83]
неа. в Аладдине работал.. (у вас депозитарий и спецдеп от них) Идеологии в принципе схожие..

а с диасофтом сейчас потихоньку ковыряюсь..

← →
Курдль © (2006-01-31 12:30) [90]

> Nikolay M. © (31.01.06 12:26) [84]
> Нет. T-SQL MS SQL-я позволяет, например, указывать в хинтах
> несколько индексов, обязательных к использованию в запросе,
> а в Sybase - только один. И таких нюансов - море.

В первый раз услышал хоть о каком-то преимуществе MS SQL перед Sybase :) (хотя с ASE я не работал, однако слышал о его недостатках перед ASA).

← →
ANB © (2006-01-31 12:31) [91]

> Попробуй написать сложный запрос, который одинаково бы работал
> на SQL и Oracle.

Повесишься

← →
Dok_3D © (2006-01-31 12:32) [92]

2 ANB © (31.01.06 12:29) [88]

Ну что ты все про ORACLE, в самом деле :). Знаем, что "прога кульная".
Но, ты знаешь, она многозвенная.

← →
Reindeer Moss Eater © (2006-01-31 12:32) [93]

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

← →
Nikolay M. © (2006-01-31 12:32) [94]

> paul_k © (31.01.06 12:29) [89]
> неа. в Аладдине работал.. (у вас депозитарий и спецдеп от
> них) Идеологии в принципе схожие..

Угу, знаю :)

> paul_k © (31.01.06 12:29) [89]
> а с диасофтом сейчас потихоньку ковыряюсь..

Аналогично по мере необходимости. Еще та... мнэ... дыра :)

← →
paul_k © (2006-01-31 12:34) [95]

Nikolay M. © (31.01.06 12:32) [94]

> Еще та... мнэ... дыра :)

не надо о грустном...
Хотя текстовый построитель отчетов они веселый придумали. Да и ещё задумок хороших много.. а между задумками. именно оно...
И хорошо, что трехзвенку лепить не стали..

← →
Курдль © (2006-01-31 12:35) [96]

> paul_k © (31.01.06 12:29) [89]
> а с диасофтом сейчас потихоньку ковыряюсь..

И как? Сильно тошнит? :) Я с ним в банке работал... Н-да...

> seg (31.01.06 12:28) [87]
> Этот синтаксис поддерживается, а вот такие функции как NVL,
> DECODE, не говоря уже о пакетах есть только в Oracle. Попробуй
> написать сложный запрос, который одинаково бы работал на
> SQL и Oracle.

Пакеты - для серверной логики. Я же ранее говорил, что основная бизнес-логика исполняется на уровне апп-сервера. NVL и DECODE тупо переводятся в ISNULL и IF THEN ELSE.
Написать сложный запрос, который одинаково бы работал на SQL и Oracle попробовал. Работает :)
(Я ж писал, что перевод завершился и занял наделю работы и 3 недели тестирования).

← →
Nikolay M. © (2006-01-31 12:36) [97]

> Курдль © (31.01.06 12:30) [90]
> В первый раз услышал хоть о каком-то преимуществе MS SQL
> перед Sybase :) (хотя с ASE я не работал, однако слышал
> о его недостатках перед ASA).

Что значит Sybase? Sybase - это фирма, выпускающая три совершенно разных СУБД: ASA, ASE и IQ.

Насчет преимущества. Часто натыкался на грабли, что пытался в ASE применить конструкцию по аналогии из MS SQL, она не работала, а в форумах находил всегда один и тот же ответ: "в ASA такое есть, а в ASE нет" :(

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

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

Могу сказать, что процедуры, написанные на PL/SQL не будут работать на других серверах и наоборот, а от к-во звеньев это ваще никак не зависит.
Это все равно, то перенести программу с С на Дельфи.

← →
Petr V. Abramov © (2006-01-31 12:37) [99]

"Толстый" клиент вполне может меньше весить, чем IE :)

← →
Nikolay M. © (2006-01-31 12:37) [100]

> paul_k © (31.01.06 12:34) [95]
> И хорошо, что трехзвенку лепить не стали..

Чур тебя :)))

← →
Digitman © (2006-01-31 12:37) [101]

> Dok_3D © (31.01.06 12:26) [85]
> Угу угу. Это ж каким черепом нужно обладать чтобы написать
> среднее звено, которое будет управлять транзакциями эффективнее,
> чем промышленная СУБД!

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

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

Написать сложный запрос, который одинаково бы работал на SQL и Oracle попробовал. Работает :)

Запрос в студию!

← →
Desdechado © (2006-01-31 12:43) [103]

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

← →
Курдль © (2006-01-31 12:44) [104]

> seg (31.01.06 12:38) [102]
> Написать сложный запрос, который одинаково бы работал на
> SQL и Oracle попробовал. Работает :)
> Запрос в студию!

Ок. Сейчас выложу ораклевый запрос. Если надо - пороюсь в CVS-е и извлеку его версию под Sybase ASA.

select A_PR.SA_ID, Null as SA_ID_PR, A_PR.SA_REJECT, DA_PR.DOC_DATE, DA_PR.DOC_NUM, DA_PR.DOT_CODE, DD_PR.DOC_ID as DCL_ID, DC_PR.DOC_ID as CNTR_ID, DS_PR.DCS_SUMMA_RUB, DS_PR.DCS_SUMMA, DS_PR.VAL_CODE, V_PR.VAL_ATTR, COND_PR.CON_SMALL_NAME, AGP_PR.SYS_ID, AGS_PR.SYS_PLACE, DD_PR.DOC_NUM || " от " || To_Char(DD_PR.DOC_DATE, "dd.MM.yyyy г.") as DCL_NAME, DC_PR.DOT_CODE || " № " || DC_PR.DOC_NUM || " от " || To_Char(DC_PR.DOC_DATE, "dd.MM.yyyy г.") as CNTR_NAME, (case when DA_PR.DOT_CODE = "АВП" then 1 else 0 end) as ACT_TYPE, (case when DC_PR.DOT_CODE = "ДВП" then 1 when DC_PR.DOT_CODE = "ДИП" then 2 else 0 end) as CNTR_TYPE , (select NVL(sum(LS_CO.LNS_SUMMA_2), 0) from SC.SC_DOC_LINKS DL_CO, SC.SC_LINK_SUMMS LS_CO where DL_CO.DOC_ID_1=LS_CO.DOC_ID_1 and DL_CO.DOC_ID_2=LS_CO.DOC_ID_2 and DL_CO.DOT_CODE_1=LS_CO.DOT_CODE_1 and DL_CO.DOT_CODE_2=LS_CO.DOT_CODE_2 and DL_CO.BNT_CODE=LS_CO.BNT_CODE and DL_CO.DOC_ID_2=DA_PR.DOC_ID and DL_CO.BNT_CODE="006") AS PAY_SUMMA, (1 - NVL(A_PR.SA_REJECT, 0)) * NVL(DS_PR.DCS_SUMMA, 0) as REAL_SUMMA from SC.SC_INSUR_ACTS A_PR, SC.SC_DOCUMENTS DA_PR, SC.SC_DOCUMENTS DD_PR, SC.SC_DOCUMENTS DC_PR, SC.SC_DOCUMENT_SUMMS CS_PR, SC.SC_DOCUMENT_SUMMS DS_PR, SC.SC_VALUTS V_PR, SC.SC_CONTRACTS CNTR_PR left outer join (SC.SC_AGENT_POLICES AGP_PR inner join SC.SC_AGENT_SYSTEMS AGS_PR on AGS_PR.SYS_ID = AGP_PR.SYS_ID) on AGP_PR.CNTR_ID = CNTR_PR.DOC_ID, SC.SC_CONDITIONS COND_PR, SC.SC_DOC_LINKS L2, SC.SC_DOC_LINKS L3 where DA_PR.DOT_CODE in ("АКТ", "АВП") and L2.DOC_ID_1 = A_PR.SA_ID and L2.DOC_ID_2 = DD_PR.DOC_ID and L2.BNT_CODE = "001" and L3.DOC_ID_1 = DD_PR.DOC_ID and L3.DOC_ID_2 = DC_PR.DOC_ID and L3.BNT_CODE = "001" and CS_PR.DOC_ID = DC_PR.DOC_ID and CNTR_PR.DOC_ID = CS_PR.DOC_ID and COND_PR.CON_ID = CNTR_PR.CON_ID and V_PR.VAL_CODE = DS_PR.VAL_CODE and DA_PR.DOC_ID = A_PR.SA_ID and DS_PR.DOC_ID = A_PR.SA_ID and exists (select /*+ FIRST_ROWS */ Null from SC.SC_INSUR_ACTS A, SC.SC_DOCUMENTS DA, SC.SC_DOCUMENTS DD, SC.SC_DOCUMENTS DC, SC.SC_CONTRACTS CNTR left outer join (SC.SC_AGENT_POLICES AGP inner join SC.SC_AGENT_SYSTEMS AGS on AGS.SYS_ID = AGP.SYS_ID) on AGP.CNTR_ID = CNTR.DOC_ID, SC.SC_DOC_LINKS L5, SC.SC_DOC_LINKS L6, SC.SC_DOC_LINKS L4 where L4.DOC_ID_1 = A.SA_ID and L4.DOC_ID_2 = A_PR.SA_ID and L4.DOT_CODE_1 = "АИП" and L4.DOT_CODE_2 in ("АКТ", "АВП") and L4.BNT_CODE = "005" and L5.DOC_ID_1 = A.SA_ID and L5.DOC_ID_2 = DD.DOC_ID and L5.BNT_CODE = "001" and L6.DOC_ID_1 = DD.DOC_ID and L6.DOC_ID_2 = DC.DOC_ID and L6.BNT_CODE = "001" and CNTR.DOC_ID = DC.DOC_ID and DA.DOC_ID = A.SA_ID and DA.SBJ_ID_OWNER = :SBJ_ID_OWNER

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

пороюсь в CVS-е и извлеку его версию под Sybase ASA.

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

← →
Reindeer Moss Eater © (2006-01-31 12:54) [106]

Могу сказать, что процедуры, написанные на PL/SQL не будут работать на других серверах и наоборот, а от к-во звеньев это ваще никак не зависит.
Это все равно, то перенести программу с С на Дельфи.

Дело не в самом языке а о механизме сохранения значений переменных пакета в течение сессии клиента.
Например:
Коннект юзера к серверу. Вызывается процедура, которая инициализирует кучу переменных и структур пакета.
На MSSQL при вызове серверной логики с клиента на сервер надо передавать кучу параметров (скажем простейшее логирование активности: ID юзера,код события, текст).
На оракле код юзера можно не передавать, а использовать закешированное в пакете значение.
Этот механизм позволяет существенно снизить количество параметров процедур и функций, снизить трафик между клиентом и сервером и т.д.

← →
Курдль © (2006-01-31 12:54) [107]

> seg (31.01.06 12:49) [105]
> Что значит "его версию"?
> Ты выложи один запрос, который будет работать на всех серверах.

Я что, где-то выше по тексту упоминал "универсальный запрос"? :(

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

← →
Petr V. Abramov © (2006-01-31 12:54) [108]

> Desdechado © (31.01.06 12:43) [103]
> К упоминавшейся масштабируемости промежуточного звена:
> - если не хватает мощности SQL-сервера для обработки ХП и прочего, то
> новый купить/настроить/поддерживать слишком дорого и проблемно
> - если не хватает мощности промежуточного звена, просто ставим рядом
> второй такой же, и нагрузка между ними распределяется без потери
> функциональности
У Oracle это все сделано безо всякой трехслойки

← →
Digitman © (2006-01-31 12:56) [109]

> Dok_3D © (31.01.06 12:26) [85]

СУБД не УПРАВЛЯЕТ т/акциями, а ИСПОЛНЯЕТ команды управления ими !

← →
paul_k © (2006-01-31 12:56) [110]

Курдль © (31.01.06 12:44) [104]
Это не сложный. Это большой запрос:)

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

СУБД не УПРАВЛЯЕТ т/акциями

Я в шоке.

← →
Dok_3D © (2006-01-31 12:59) [112]

2 Digitman © (31.01.06 12:37) [101]

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

← →
Курдль © (2006-01-31 13:00) [113]

> paul_k © (31.01.06 12:56) [110]
> Курдль © (31.01.06 12:44) [104]
> Это не сложный. Это большой запрос:)

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

← →
paul_k © (2006-01-31 13:00) [114]

Курдль © (31.01.06 12:54) [107]
Я говорил, что адаптировать проект, выполненный на трехзвенке под новую СУБД
совершал "переезд" с Sybase ASE на MS SQL. За счет изначально правильного подхода к разработке в очень большом проекте пришлось исправить 16 процедур. добавить 10 шаблонов в макроязык.
Система стала жить и в том и в другом сервере. На "переезд" ушел месяц. Причина - изначально правильно продуманный подход к разработке.

← →
Polevi © (2006-01-31 13:01) [115]

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

← →
seg (2006-01-31 13:02) [116]

Курдль © (31.01.06 12:54) [107]

Я писал:

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

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

← →
Dok_3D © (2006-01-31 13:03) [117]

2 Digitman © (31.01.06 12:56) [109]
СУБД не УПРАВЛЯЕТ т/акциями!

Автомобиль не ездит, он лишь исполяет команды "поехали", "стоп" и "дави бабку" :)

← →
seg (2006-01-31 13:06) [118]

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

Или не способные создать подобное.

← →
Курдль © (2006-01-31 13:10) [119]

> seg (31.01.06 13:06) [118]
> многозвенную архитектуру придумали люди не знакомые с сервером
> оракл
> иначе они конечно-же сразу бы поняли абсурдность данной
> парадигмы
>
> Или не способные создать подобное.

Каюсь! Я не способен создать сервер оракл :(

← →
Digitman © (2006-01-31 13:12) [120]

> Dok_3D © (31.01.06 13:03) [117]

Дурью не майся уже)

Так ведь и есть - автомобиль "слушает" и "исполняет"ё твои команды.. А тебе как "ездюку" по колено как он там это делает ...

и не говори что это не так) ...

← →
ANB © (2006-01-31 13:12) [121]

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

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

А 10G можно без переписывания настроить на распределенную работу.

← →
Курдль © (2006-01-31 13:12) [122]

> paul_k © (31.01.06 13:00) [114]
> совершал "переезд" с Sybase ASE на MS SQL.

Еще бы в таком переезде возникли проблемы! Ведь указанные СУБД - уродливые дети одного и того же родителя! :)

← →
seg (2006-01-31 13:17) [123]

Каюсь! Я не способен создать сервер оракл :(

ессно, одному челу это не под силу.

← →
ZeroDivide © (2006-01-31 13:20) [124]

Holy War

ИМХО, здесь 2 вопроса:
1. Преимущество 3-х звенки, перед 2-х звенкой в случае написания СУБД индепенденс приложений.
2. Преимущество 3-х звенки, переl 2-х звенкой Oracle.

В последнем случае, преимуществ ни каких нет, только недостатки.

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

> ZeroDivide © (31.01.06 13:20) [124]
>
> Holy War
>
> ИМХО, здесь 2 вопроса:
> 1. Преимущество 3-х звенки, перед 2-х звенкой в случае написания
> СУБД индепенденс приложений.
> 2. Преимущество 3-х звенки, переl 2-х звенкой Oracle.
>
> В последнем случае, преимуществ ни каких нет, только недостатки.
>
>

Опишите приблизительно-коротенько реализацию публикации БД!

← →
ZeroDivide © (2006-01-31 13:38) [126]

> пишите приблизительно-коротенько реализацию публикации БД!

Реализацию публикации... приблизительно-коротенько... Ничего не понял. Это как?

← →
paul_k © (2006-01-31 13:39) [127]

Курдль © (31.01.06 13:12) [122]
Со словом "уродливые" категориццки не согласек. А так да, MS дитя Sybase.
Но уверен, что и на оракл переез не составил бы больших сложностей. и на любую другую СУБД. ну не месяц, ну два. ну не 10 шаблонов переписать а 20.(а процедур - теже 16). Опять же в силу правильной идеи полоенной в основу.

← →
Курдль © (2006-01-31 13:41) [128]

> ZeroDivide © (31.01.06 13:38) [126]

Ок. Задам вопрос попроще.
Как сделать доступ к БД из тырнета? Да чтобы с шифрованием, разделением доступа к функциям системы по группам и т.п.

← →
seg (2006-01-31 13:49) [129]

Как сделать доступ к БД из тырнета?

К Ораклу?

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

Курдль © (31.01.06 13:12) [122]

http://en.wikipedia.org/wiki/Microsoft_SQL_Server#History

Дабы внести ясность в сабж

← →
Sandman29 © (2006-01-31 14:01) [131]

Sergey13 © (31.01.06 11:33) [53]

Нет, не проще.

← →
ZeroDivide © (2006-01-31 14:04) [132]

> Как сделать доступ к БД из тырнета? Да чтобы с шифрованием,
> разделением доступа к функциям системы по группам и т.п.
>

Все это можно в Oracle сделать без проблем.
Как? - www.oracle.com

Лично я разрабатываю rich клиентов на Delphi. У нас есть web-прогрммисты, которые успешно занимаются обеспечением доступа из браузеров к нашей БД. При этом система администрирования - одна, написаная на PL/SQL, т.е. функциональность системы и данные доступные пользователю одни и те же, как для веб, так и для rich клиентов.

← →
Sandman29 © (2006-01-31 14:06) [133]

ANB © (31.01.06 11:55) [65]

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

То есть БД выполняет роль сервера приложений? Тогда действительно можно обойтись.

← →
Reindeer Moss Eater © (2006-01-31 14:10) [134]

Как сделать доступ к БД из тырнета? Да чтобы с шифрованием, разделением доступа к функциям системы по группам и т.п.

Море средств. Начиная с SYS.DBMS_CRYPTO_TOOLKIT

← →
Alex Konshin © (2006-01-31 14:18) [135]

Есть хороший принцип: разделять код и данные. Например, Windows - типичный пример смешивания того и другого в системных директориях, хотя они методично пытаются исправиться.
Другой пример - базы данных с логигокой построенной на хранимых процедурах и тригерах. На мой взгляд - это как раз для мазохистов. Понаблюдайте, сколько времени уходит на отладку и сопровождение таких систем. Не зря же DBA стали некими синонимами шаманов от программирования - очень специализированных, и очень системозависимых. Это же дико для обычного программиста, что перевод DBMS с одной версии на другую версии равносилен пожару, а уж переход на другую DBMS и просто чаще всего невозможен.
Получается, что часть кода сидит в самой DB, часть - в приложении, причем обе части очень разнородные. С точки зрения нормального програмиста, все это программирование в DBMS это сплошное использование побочных эффектов и игра с нерегулярностями с переменным успехом. Это требует специальных знаний об этой DBMS (не зря Oracle так жиреет на обучении и консультациях). И время на обучение, и ячейки памяти в мозгах нужно еще и разделять со знаниями языка програмирования самого приложения. Потому трудно найти одного человека, который бы владел и тем, и тем в совершенстве. Поэтому вреальных ситуациях обычно имеется две команды (по крайней мере): одно специализируется на DB, другая на клиентской части. Тут же возникает проблема согласованной работы этих команд.
Получить что-то надежное в такой ситуации трудно, по крайней мере это трудоемко. Поэтому говорить, что с Oracle и трехзвенка не нужна - это просто не замечать бревно в глазу.

← →
ANB © (2006-01-31 14:18) [136]

> ZeroDivide © (31.01.06 13:20) [124]
> Holy War
>
> ИМХО, здесь 2 вопроса:
> 1. Преимущество 3-х звенки, перед 2-х звенкой в случае написания
> СУБД индепенденс приложений.
> 2. Преимущество 3-х звенки, переl 2-х звенкой Oracle.
>
> В последнем случае, преимуществ ни каких нет, только недостатки.
>

Первый вопрос отпадает, т.к. в топике ясно указано - Оракл !!!

> Курдль © (31.01.06 13:22) [125]
>
> Опишите приблизительно-коротенько реализацию публикации
> БД!

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

По поводу универсальности примеры :
1. Запрос по дереву
Oracle - connect by
MS SQL - только через хранимки
2. Хранение сессионных переменных
Oracle - пакеты
MS SQL - только на клиенте
3. Векторные подзапросы
Oracle - только через аналитические функции
MS SQL поддерживает
4. from в delete, update
Oracle - только через векторные подзапросы
MS SQL поддерживает

Это только навскидку. Во всяком случае даже простые проекты, в которых активно используются фичи оракла (а так короче, надежнее, быстрее и понятнее) перенести на MS SQL простым Find/Replace будет невозможно. А вдумчивая работа потребует очень кардинальной переделки. Да и кто сможет назвать хотя бы 3 причины, которые обоснуют переезд с оракла на другую СУБД ?

← →
seg (2006-01-31 14:18) [137]

То есть БД выполняет роль сервера приложений?

Может все-таки для начала доку по Ораклу почитать, а потом спорить?

← →
seg (2006-01-31 14:25) [138]

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

Мощно задвинул, присоединяюсь.

← →
Polevi © (2006-01-31 14:28) [139]

>ANB © (31.01.06 14:18) [136]
MS не стоит на месте, Yukon поддерживает рекурсивные запросы - это к вопросу запросов по дереву

← →
ANB © (2006-01-31 14:30) [140]

> Alex Konshin © (31.01.06 14:18) [135]

Как раз имею обратный опыт. Обычная мелкая синтаксическая ошибка в запросе, который запихан в SQL.Text обнаруживается только в RunTime и то, если при тестировании залез в эту ветку. Эта же ошибка в пакете обнаруживается еще при компиляции. Или, например, кто то заальтерил табличку (удалил поле). Чтобы выявить, что при этом сломалось на аппсервере, придется провести полное тестирование. А оракл просто укажет на битые пакеты. Насчет сложности PL/SQL - это сказки. Изучается самостоятельно по книжкам на раз. В МВ нас с нуля готовили на оракл неделю и нормальные ребята сразу начали писать. Он довольно простой и очень логичный.

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

← →
Alex Konshin © (2006-01-31 14:30) [141]

seg (31.01.06 14:25) [138]
Да и кто сможет назвать хотя бы 3 причины, которые обоснуют переезд с оракла на другую СУБД ?
Мощно задвинул, присоединяюсь.

Он хуже работает на Windows.
Он большой и громоздкий.
Заказчик всегда прав.
Стоимость лицензии.

← →
Polevi © (2006-01-31 14:33) [142]

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

> Он хуже работает на Windows.
> Он большой и громоздкий.
> Заказчик всегда прав.
> Стоимость лицензии.

1. У почти всех наших клиентов он работает на Windows. И никто не жалуется, хотя их очень много. Кстати, почему то наша поддержка не рекомендует ставить оракл на линух.
2. Не такой уж большой и громоздкий. У меня 3 компа и на всех по несколько инстансов.
3. Заказчика можно всегда переубедить
4. Для разработки и обучения - халява, плюс собираются выпустить халявую урезанную версию и для коммерческого использования. Да и кто в России платит за лицензии ?

> Polevi © (31.01.06 14:34) [143]
> >ANB © (31.01.06 14:30) [140]
> ты про Yukon почитал чтоли, многие твои сведения устарели
> в связи с его выходом

Если у него будет столько же возможностей, сколько у оракла, то флаг ему в руки. Но тогда это будет еще одна система, с которой : 1) незачем слезать 2) не нужна трехслойка

> Alex Konshin © (31.01.06 14:30) [141]

> Он хуже работает на Windows.
Хуже, чем что?
> Он большой и громоздкий.
Для база "Борей" - м.б.
> Заказчик всегда прав.
Его проблемы
> Стоимость лицензии.
Стоимость владения большой базой

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

Апологеты MS SQL-ля могут назвать и больше :) Только вот убедительны они лишь для них!

Кстати, кто разбирался с MS SQL-2005?
В моей фирме был день траура по поводу MS Visual Studio 2005.
Решили перейти на этот продукт с 2003-го. Назначили парочку челов для тестовой компилляции / проверки. Те через несколько дней отрапортовали о "зачоте".
Потом вся контора пересела на 2005. И оказалось, что проект компилится, а вот много чего не поддается редактированию. Например, гриды отказались наследоваться! Т.е. все свойства гридов на формах-наследницах базовых списочных форм оказались недоступными! Долго бегали по инету, бились в истерике. Оказалось, что MS официально отменил "visual inheritance for non-trivial controls". Это шок! Какого ... ?
Вот интересно, что там с MS SQL 2005?..

ANB © (31.01.06 14:30) [140]

> Alex Konshin © (31.01.06 14:18) [135]

Как раз имею обратный опыт. Обычная мелкая синтаксическая ошибка в запросе, который запихан в SQL.Text обнаруживается только в RunTime и то, если при тестировании залез в эту ветку. Эта же ошибка в пакете обнаруживается еще при компиляции. Или, например, кто то заальтерил табличку (удалил поле). Чтобы выявить, что при этом сломалось на аппсервере, придется провести полное тестирование. А оракл просто укажет на битые пакеты. Насчет сложности PL/SQL - это сказки. Изучается самостоятельно по книжкам на раз. В МВ нас с нуля готовили на оракл неделю и нормальные ребята сразу начали писать. Он довольно простой и очень логичный.

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

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

Что я хочу сказать, что путь Oracle мне не нравится. Для меня уже достаточно того, что там нарушается принцип разделения данных и кода.

← →
seg (2006-01-31 14:45) [149]

Оказалось, что MS официально отменил "visual inheritance for non-trivial controls". Это шок! Какого ... ?

Зачем вообще связываться с "новейшими" разработками мелкософта?

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

Есть одна причина: не стрелять из пушки по воробьям.

ЗЫ: Для воробьев 3-х звенка тем более не нужна :)

> Есть хороший принцип: разделять код и данные.

А ни кто их и не мешает. Все хранится в БД, но раздельно :) А не использовать особенности реализации SQL в конкретной СУБД, а только ANSI SQL - вот это как раз мазохизм. Тем более, когда есть Oracle SQL, не использовать его просто глупо, хотя бы тот же connect by... нет уж... извините...

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

2[150] ZeroDivide © (31.01.06 14:45)
> Есть одна причина: не стрелять из пушки по воробьям.

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

2[148] Alex Konshin © (31.01.06 14:42)
>Что я хочу сказать, что путь Oracle мне не нравится. Для меня уже достаточно того, что там нарушается принцип разделения данных и кода.

А что нравится? Дибейс? У всех серверов вроде хранимки есть.

> ZeroDivide © (31.01.06 14:45) [150]
> глупо, хотя бы тот же connect by... нет уж... извините..

И накой Вам этот деревянный запрос, если современные свойства отображения сами прекрасно строят "деревья"? Я прусь от оракла, но не считаю connect by prior его главным преимуществом. Оракл - это прежде всего высоконадежная, высокопризводительная СУБД, расчитанная на одновременную работу сотен пользователей с тысячами таблиц. В этом ему почти нет равных. И если уж есть конкуренты, то не от MS, а от каких-нить Intel.
Оракл может устанавливаться как под распространенными ОС, так и вообще без таковых. Он может сам создавать оптимальную файловую систему под себя.

> seg (31.01.06 14:45) [149]
> Зачем вообще связываться с "новейшими" разработками мелкософта?

Т.к. никакими другими существующими средствами разработки наш проект в наши сроки нашим коллективчиком было не поднять! На Delphi это бы заняло в 5 раз больше времени, если совсем бы не зашло в тупик...

← →
seg (2006-01-31 14:59) [155]

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

Может именно в этом заключается глючность данного сайта?

← →
seg (2006-01-31 15:00) [156]

На Delphi это бы заняло в 5 раз больше времени, если совсем бы не зашло в тупик...

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

2[154] Курдль © (31.01.06 14:56)
> Оракл может устанавливаться как под распространенными ОС, так и вообще без таковых.
Ну уж ты загнул.

>Он может сам создавать оптимальную файловую систему под себя.
Файловая система и ОС это одно и то-же.

> Sergey13 © (31.01.06 15:01) [157]
> > Оракл может устанавливаться как под распространенными
> ОС, так и вообще без таковых.
> Ну уж ты загнул.

Отнюдь!

> >Он может сам создавать оптимальную файловую систему под
> себя.
> Файловая система и ОС это одно и то-же.

У меня на одном компе под Win 2000 один диск с NTFS а другой - с FAT32. Или это не файловые системы? :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

msguns © (31.01.06 15:25) [163]

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

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

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

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

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

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

А что касается переезда: Либо удобный и простой 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

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

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

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

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

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

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

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

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

Все.

А как же SAP R/3?

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

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

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

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

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

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

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

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

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

euru © (31.01.06 17:05) [176]

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

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

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

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

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

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

Почему ?

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

> а в SAP R/3

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

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

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

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

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

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

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

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

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

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

> 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 раза подняли юзеров на той же технике.

> 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 Двухслойка Найти похожие ветки