Зачем нужны многозвенки ?

← →
Zacho © (2005-10-31 00:35) [40]

Reindeer Moss Eater © (31.10.05 0:13) [39]
Ну а я говорю, что трехзвенка не решает проблемы тонких каналов сама по себе

Полностью согласен.

> Reindeer Moss Eater © (30.10.05 16:21) [29]
> Это заблуждение

А вот с этим - нет. Проблемы обрывов решает ? Решает. Так в чём же заблуждение ?

Но, в общем, я не имею особого желания спорить на эту тему. Как уже говорил, сам я этим занимался давно и подробности плохо помню.
А если есть желание пообщаться с людьми, которые могут подробно и аргументированно объяснить зачем нужна 3-х звенка именно для решения проблем тонких каналов - стоит спросить в e.p.i, там такие люди есть. Да и здесь, возможно, найдутся. Вот, Сергей Маслов, например.

← →
Reindeer Moss Eater © (2005-10-31 00:39) [41]

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

← →
Reindeer Moss Eater © (2005-10-31 00:40) [42]

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

Я знаю для чего она предназначена и активно её испорьзую сам.

← →
Zacho © (2005-10-31 00:49) [43]

Reindeer Moss Eater © (31.10.05 0:39) [41]
Обрывы и плохие каналы - они не обязательно медленные каналы.

Вот и консенсус :) Похоже, мне сразу нужно было указать только ненадёжные каналы, не приплетая медленные, и спора бы не было :)

Reindeer Moss Eater © (31.10.05 0:40) [42]
Я знаю для чего она предназначена и активно её испорьзую сам.

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

← →
Piter © (2005-10-31 01:02) [44]

Reindeer Moss Eater © (30.10.05 23:57) [36]
Да например шлюз, работающий на уровне TCP/IP

да, но это ведь отдельная программа, верно? Верно...

Это и есть как бы звено ТВОЕЙ ЦЕПОЧКИ. Третье звено :)

Reindeer Moss Eater © (30.10.05 23:57) [36]
Либо я начну утверждать что любой коммутатор/свитч/маршрутизатор между сервером и клиентом это тоже звено многозвенки

если бы ты в процессе написания базы сделал бы маршрутизатор - то это имхо и было бы звеном, несомненно.

Reindeer Moss Eater © (30.10.05 23:57) [36]
Нету у многозвенных приложений задачи экономии трафика. Нету и все

нету и все. Хех... Нету и все...

Авторитетно! Ничего не скажешь :)
Это тебе Билли Гейтс сказал?

Reindeer Moss Eater © (31.10.05 0:13) [39]
Ну а я говорю, что трехзвенка не решает проблемы тонких каналов сама по себе

САМА ПО СЕБЕ трехзвенка, имхо, вообще никаких проблем не решает :)

← →
Reindeer Moss Eater © (2005-10-31 08:22) [45]

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

← →
Anatoly Podgoretsky © (2005-10-31 09:14) [46]

Piter © (30.10.05 22:18) [35]
Ты не представляешь, сколько таких прослоек, пока сигнал от клиента дойдет до сервера, но это не дает основания называть это многозвенкой, это понятие логическое, а не физическое.

← →
Polevi © (2005-10-31 10:57) [47]

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

← →
Anatoly Podgoretsky © (2005-10-31 11:00) [48]

Пусть задает вопрос используя толстый клиент :-)

← →
Polevi © (2005-10-31 11:14) [49]

ктож его на сервер пустит :)

← →
Piter © (2005-10-31 11:35) [50]

Anatoly Podgoretsky © (31.10.05 9:14) [46]
Ты не представляешь, сколько таких прослоек

откуда такая уверенность?

Reindeer Moss Eater © (31.10.05 8:22) [45]
Piter, стек протоколов по которым ты общаешся с сервером - это тоже отдельная программа

стек протоколов - это программа? :)

Я знаю о промежуточных звеньях.

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

То, о чем ты говоришь - НЕ ТВОИ программы, поэтому и не являются звенов ТВОЕЙ цепи.

Если бы ты изобрел для какой-то базы данных некое аппаратное устройство - то это тоже было бы звеном твоей цепи.

А иначе что такое многозвенка?

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

И в каком случае ее можно считать звеном, а?

Если она значит просто сжимает трафик - это значит не многозвенка, ок.

А если она допустим удаляет символы перевода строки #13#10, которые ошибочно посылает клиент (ну вот такое решение сделали) - то это звено?

А если она расширяет SQL, допустим поддерживает комманду LIMIT X, которая ограничивает число возвращаемых результатов в SELECT"е - то это как, звено уже?

А если эта программа реализует некий язык программирования, что-то типа хранимых процедур (допустим, сервер хранимые процедуры не поддерживает) - то это уже звено?

А если она каким-то образом бизнесс логику применяет - это звено?

Где грань?

Я уже ответил, что звено - это любая ТВОЯ программа между сервером и клиентом. И не важно что она делает. Имхо, так.

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

Вполне может быть другое определение - слушаю.

← →
Polevi © (2005-10-31 11:45) [51]

>звено - это любая ТВОЯ программа
IE - это по твоему не звено чтоли ?

← →
Piter © (2005-10-31 11:58) [52]

Polevi © (31.10.05 11:45) [51]
IE - это по твоему не звено чтоли ?

немного не понял

← →
Reindeer Moss Eater © (2005-10-31 12:33) [53]

Питер, а если этот жмущий шлюз - не моя программа, а программа третьего лица. Она понятия не имеет ни о моем оракле, ни о моем клиенте.
Она просто жмет трафик. Любой трафик. Не только клиента Оракла, а вообще любой.
И не является она звеном многозвенки.

← →
Курдль © (2005-10-31 12:34) [54]

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

← →
Reindeer Moss Eater © (2005-10-31 12:34) [55]

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

← →
Reindeer Moss Eater © (2005-10-31 12:34) [56]

Удалено модератором

← →
Курдль © (2005-10-31 12:35) [57]

← →
Reindeer Moss Eater © (2005-10-31 12:37) [58]

Я раньше был ярым противником трехзвенок. Но потом перековался.

Здесь никто и не говорит что многозвеньевые системы - это ацтой.

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

У меня был успешный проект в котором тип сервера БД менялся кнопкой по желанию юзера.
Двузвенка то была.

← →
Sergey13 © (2005-10-31 12:42) [59]

ИМХО многозвенка нужна, что бы разгрузить сервер БД не нагружая этим клиента. 8-)

← →
Курдль © (2005-10-31 12:50) [60]

> Sergey13 © (31.10.05 12:42) [59]
> ИМХО многозвенка нужна, что бы разгрузить сервер БД не нагружая
> этим клиента. 8-)

А вот это мне не понятно! Сервера БД от качественных СУБД сами по себе могут оптимизировать свою производительность так, что доморощенным "примочкам" и не снилось. Напр., в отсутствие ОС, толково работающих с многопроцессорными серверами, оракл умеет с такими работать без какой либо ОС. Умеет сам создавать под себя оптимальную дисковую структуру, управлять ею напрямую, поддерживая RAID и т.д.

← →
Juice © (2005-10-31 12:58) [61]

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

> Пусть задает вопрос используя толстый клиент :-)

После этих слов наступило тотальное просветление "автора" в данном вопросе :)

← →
Курдль © (2005-10-31 13:00) [62]

> Reindeer Moss Eater © (31.10.05 12:37) [58]
> Здесь никто и не говорит что многозвеньевые системы - это
> ацтой.

Я говорю, что это ацтой. Но иногда без него не обойтись.

> У меня был успешный проект в котором тип сервера БД менялся
> кнопкой по желанию юзера.
> Двузвенка то была.

Это как? Утром заносил данные в оракл, а вечером решил их вытащить из информикса? 8-()

← →
Sergey13 © (2005-10-31 13:06) [63]

2 [60] Курдль © (31.10.05 12:50)
Существуют, например, задачи, где надо перелопатить большой объем инфы с активным перерасчитыванием (например сложный отчет за год). Т.е. проц занят на 100%, а БД (как хранилище данных) фактически простаивает. И при этом плохо откликается на других пользователей. Вот для подобного, я считаю, и следует применять АПП сервер.

← →
Курдль © (2005-10-31 13:13) [64]

> Т.е. проц занят на 100%, а БД (как хранилище данных) фактически
> простаивает.

Типа "мощный сервак, но слабенькая СУБД"?

← →
Reindeer Moss Eater © (2005-10-31 13:14) [65]

Это как? Утром заносил данные в оракл, а вечером решил их вытащить из информикса? 8-()

На удаленных участках стоял IB
В ЦО был MSSQL.

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

← →
Курдль © (2005-10-31 13:22) [66]

> Reindeer Moss Eater © (31.10.05 13:14) [65]

И как достигалась целостность данных, например которая в БД решается триггерами?
Логикой работы клиента?

← →
Sergey13 © (2005-10-31 13:25) [67]

2[64] Курдль © (31.10.05 13:13)
Ну представь - таблица в 100000 записей содержит входные параметры для некой (абстрактной) процедуры которая к БД (по большому счету) не имеет отношения. Зачем выполнять эту процедуру на сервере БД?

← →
Курдль © (2005-10-31 13:36) [68]

> Sergey13 © (31.10.05 13:25) [67]
> Ну представь - таблица в 100000 записей содержит входные
> параметры для некой (абстрактной) процедуры которая к БД
> (по большому счету) не имеет отношения. Зачем выполнять
> эту процедуру на сервере БД?

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

2[68] Курдль © (31.10.05 13:36)
>Всегда приходится лопатить связанные данные, лезть рекурсиями в БД и т.п.
Так даже если так, то прикинь. Например ты 1000000 раз запрашиваешь одни и те-же данные, но с разными коэффициентами (из главной таблицы). Вопрос - а зачем каждый раз запрашивать, если возвращается всегда одно и то-же? Может стОит один раз запросить, а потом вертеть на АПП сервере как хочется.
Я не говорю, что так надо делать. Я говорю, что так можно делать. И это будет оправдано в некоторых случаях.

← →
SL (2005-10-31 16:13) [70]

Reindeer Moss Eater, ты как-то упомянул о том, что знаешь для чего нужна трехзвенка и сам ее активно используешь.
Может я читал невнимательно, но не нашел твоей версии ответа - для чего же?
Будь добр, если это конечно не военная тайна...

И как достигалась целостность данных, например которая в БД решается триггерами?
Логикой работы клиента?

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

> Reindeer Moss Eater © (31.10.05 16:21) [71]
> Это уже десятый вопрос.
> Приложение было двузвенным и могло работать с двумя типами
> серверов.

Да как же "десятый", если для меня - это первый вопрос при альтернативе двухзвенка/трехзвенка для разнобазовых систем!

Одно дело - слегка адаптировать логику сервера приложений под новую СУБД.
Другое - переписывать всю серверную логику БД с PL/SQL на TSQL (к примеру).
А если заказчик попросит вовсе неизвестную мне СУБД подключить?

Ну само собой, серверный код БД значительно отличался на этих двух серверах. А клиент был минимально завязан на особенности той или иной платформы.

Reindeer Moss Eater © (31.10.05 12:33) [53]
Она просто жмет трафик. Любой трафик. Не только клиента Оракла, а вообще любой.
И не является она звеном многозвенки

тогда да - не является. А как иначе?

Если несогласен - прошу дать свое определение многозвенки.

Раз не является, то и система получается классическая клиент-серверная, двузвенная. Но в которой присутствует сжатие потоков данных.
Я про это и говорил.

Траспорт и разъемы прошу оставить в покое.

да что транспорт тут некоторые слой представления не считают звеном

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

И какое же бизнес правило можно реализовать в этом шлюзе или модеме?

> Одно дело - слегка адаптировать логику сервера приложений
> под новую СУБД.
> Другое - переписывать всю серверную логику БД с PL/SQL на
> TSQL (к примеру).
> А если заказчик попросит вовсе неизвестную мне СУБД подключить?
>

Трехзвенка в этом все равно не помошник. SQL у оракла и MS SQL настолько разный (особенно хранимок), что чтобы обеспечить совместимость хотя бы на уровне запросов, придется перейти на ANSI и жестоко потерять в производительности и возможностях. Или писать сразу 2 ветки, что явно не снижает трудоемкости. Видел 2 очень отрицательньных примера : ИНФИН (универсальность убила гибкость), новая система для налоговых - ЭОД "АИС Налог" - трехзвенка на MS SQL, которую переносят на оракл уже 6 лет.
ЗЫ. А не пойти ли нам по этому поводу в "потрепаться" ?

ANB © (01.11.05 09:57) [79]
Не знаю как сейчас, но на старых Ораклах об ANSI не приходилось говорить, там же даже [*] JOIN не был поддержан.
А как сейчас с этим у Оракла?

Зачем нужны многозвенки ? Найти похожие ветки