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

← →
Juice © (2005-10-28 19:16) [0]

Это серьезный вопрос, я без шуток :)

← →
Джо © (2005-10-28 20:58) [1]

Чтобы оправдать завышенную цену за выполнения проекта, например :)

← →
Desdechado © (2005-10-28 21:11) [2]

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

← →
tesseract © (2005-10-28 21:18) [3]

А ты ни разу юзеров из 1с не выгонял :-)
Они нужны для исключения конфликтов в запросах изменения/чтения данных, кэширования результатов, репликации данных, масштабируемости тд.

← →
Sergey Masloff (2005-10-28 21:35) [4]

Desdechado © (28.10.05 21:11) [2]
>Есть один серьезный аргумент в их пользу - легкая масштабируемость. >Если бизнес-логику положить в БД (ХП, например), то при необходимости >увеличить число пользователей приводит к серьезным затратам на апгрейд >сервера БД.
Это в теории. А на практике... совсем наоборот. Масштабирование на порядок (с тысяч до десятков тысяч пользователей) систем где логика вся в базе я видел. Проблем не было. А вот логигу с наращиванием за счет масштабирования серверов приложений - увы, успешных не видел. Неуспешные видел. Так что не все так просто ;-))
Кстати логика в базе совсем не исключает трехзвенки и наоборот - очень широко используется.

← →
tesseract © (2005-10-28 21:54) [5]

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

Я честно говоря видел. Lotus Notes например, 1с 8.x

> Кстати логика в базе совсем не исключает трехзвенки и наоборот
> - очень широко используется.

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

← →
Desdechado © (2005-10-28 22:00) [6]

2 Sergey Masloff
> логика в базе совсем не исключает трехзвенки и наоборот
Согласен. Не вижу смысла тянуть на среднее звено много данных при необходимости переколбасить всю БД для аналитического отчета, например.

> успешных не видел
Это пока только начало. Специалистов мало, технология еще не обкатана да и рекламный прессинг присутствует. Да и хорошо работающие 2-звенки не вижу смысла перетаскивать на 3 и более. А вот новые вполне можно сразу грамотно на многозвенку сажать.

← →
Zacho © (2005-10-29 00:06) [7]

Desdechado © (28.10.05 22:00) [6]
технология еще не обкатана

Так сколько её можно обкатывать ? :) Технологии уже лет 10, если не больше.

По сабжу:
Ещё 3-x звенка весьма полезна при доступе к БД по медленным и ненадёжным каналам (например, dial-up).

← →
Anatoly Podgoretsky © (2005-10-29 11:46) [8]

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

← →
Polevi © (2005-10-29 17:28) [9]

просто еще один уровень абстракции
куда нам без них в нашем деле

← →
tesseract © (2005-10-30 00:20) [10]

> как в 1С, чтобы прикрыть неправильную работу с SQL, там
> поставили третье звено, чтобы как то прикрыть сильные просчеты.
>

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

← →
Reindeer Moss Eater © (2005-10-30 10:22) [11]

По сабжу:
Ещё 3-x звенка весьма полезна при доступе к БД по медленным и ненадёжным каналам (например, dial-up).

<Цитата>

Трехзвенка никогда не решала проблему тонких каналов.
У нее вообще такой задачи не было.

← →
Zacho © (2005-10-30 11:57) [12]

Reindeer Moss Eater © (30.10.05 10:22) [11]
У нее вообще такой задачи не было.

Мало ли чего не было.. :) Главное, что 3-х звенка с успехом используется именно для решения части проблем тонких каналов. По крайней мере, при использовании IB. С другими СУБД - не знаю, может и правда ничего не даёт.
Если хочешь подробности - спроси на news://forums.demo.ru/epsylon.public.interbase
А я участвовал в разработке системы на IB с доступом по тонким каналам довольно давно, и уже смутно помню, какие именно проблемы решались именно 3-х звенкой.

← →
Piter © (2005-10-30 12:11) [13]

Anatoly Podgoretsky © (29.10.05 11:46) [8]

а вы много работали с 1C?

← →
Anatoly Podgoretsky © (2005-10-30 12:34) [14]

Piter © (30.10.05 12:11) [13]
Чур, чур меня.

← →
Piter © (2005-10-30 12:57) [15]

Anatoly Podgoretsky © (30.10.05 12:34) [14]
Чур, чур меня

тогда на основании чего говорите о непродуманности?

← →
sniknik © (2005-10-30 13:08) [16]

> Чур, чур меня.
;)

> а вы много работали с 1C?
я работал, довольно много. и именно с 1С а не на ;). (COM обьекты(пару) под нее делал, обмен, помогал 1С-никам в нее ADO вставлять(вернее не вставлять, поддержка COM там есть, а писал код для его использования на 1С, хотя язык и не знаю ;о), но тут они мне помогали), запросы им же делал...)

в общем из первых рук(своих ;) знаю, что проблема неправильной работы с базой(mssql) там есть, она работает с mssql также как и с собственным dbf движком... от чего всех начинающих так предостерегают ;)), т.е. там как раз присутствуют отборы всей таблици в милион записей, чтобы потом наложить фильтр и получать 10 значимых, перетаскивание данных и общет на клиенте вместо запроса на сервер и т.д. сервер практически не используется. (можеш сам открыть профайлер и посмотреть).
а с чего, и как думаеш делают оптимизацию на порядки (отчет считается 3 часа, переписываем тоже но с помощью ADO там же (в 1С), и он считается 20сек)? именно поэтому, обходя убого реализованный механизм работы с mssql.
да ето все касается 1С семерки, с восьмеркой не работал практически, разошлись у нас путя...

но по сути понятно, всетаки не совсем без инфы..., там трезвенка (одна из задач) для того чтобы в самой 1С все оставить как есть, а с базой работу сделать пооптимальнее. но вот тут еще вопрос получилось у них или нет... (сам не разбирался, естественно, раз больше не работаю с ним, но вот отдел рядом, через картонную стенку ;)... только недавно слышал, ругали его, там чтото с выполнение запроса не так было (есть компонент показывает ход выполнения запроса... (мечта некоторых сдесь ;), так вот ставят они его и вычисление с 9сек увеличивается до 30мин... ну примерно), думаю это тоже не от хорошей работы с базой. и это не единственное, хотя в общем говорят получше стало)

← →
Anatoly Podgoretsky © (2005-10-30 13:10) [17]

Piter © (30.10.05 12:57) [15]
Интернет большой

← →
sniknik © (2005-10-30 13:12) [18]

> тогда на основании чего говорите о непродуманности?
а что обязательно много работать с ним чтобы узнать недостатки?
по моему достаточно почитать по теме, посмотреть с какими проблемами люди сталкиваются, проверить, потестить.... и не использовать если оправдалось и есть возможность не использовать.... ;о) (у нас не такой ;()

← →
Anatoly Podgoretsky © (2005-10-30 13:16) [19]

sniknik © (30.10.05 13:08) [16]
работает с mssql также как и с собственным dbf движком

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

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

Что у них великолепно, так это высочайшего уровня маркетинг, надо же суметь так раскрутить систему и всучивать ее на всех уровнях, от отдельных компьютеров, до корпоративного уровня.

При выборе системы у нас одним из кандидатов был и 1С, славо богу руководство поняло, что это такое.

← →
Anatoly Podgoretsky © (2005-10-30 13:17) [20]

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

← →
Piter © (2005-10-30 14:18) [21]

tesseract © (28.10.05 21:54) [5]
взять хотя бы язык JSQL

а что это такое? Вроде T-SQL слышал, об PL/SQL тоже. А что такое JSQL? Тоже типа того?

← →
Piter © (2005-10-30 14:20) [22]

Нда-а-а-а, не знал, что у 1C такие огрехи. Странно, ну не дураки же там работают...

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

← →
Anatoly Podgoretsky © (2005-10-30 14:23) [23]

Piter © (30.10.05 14:18) [21]
Это разные языки, разных SQL серверов.

← →
Anatoly Podgoretsky © (2005-10-30 14:24) [24]

Piter © (30.10.05 14:20) [22]
Написать переходник проще, чем переписать полностью всю систему, изначально бардачно построеную.
Даже если ее писать паралельно, системы подобго класса требуют годы и гамма тестирование.

← →
Anatoly Podgoretsky © (2005-10-30 14:28) [25]

Piter © (30.10.05 14:20) [22]
Нда-а-а-а, не знал, что у 1C такие огрехи. Странно, ну не дураки же там работают...

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

← →
Anatoly Podgoretsky © (2005-10-30 14:30) [26]

Кстати тут неоднакратно приводили жизненые примеры, как 1С-ники окучивают рынок.

← →
Piter © (2005-10-30 15:49) [27]

Anatoly Podgoretsky © (30.10.05 14:23) [23]
Это разные языки, разных SQL серверов

я в курсе. И что? :)

← →
Anatoly Podgoretsky © (2005-10-30 16:01) [28]

А то и есть, другой язык и все.

← →
Reindeer Moss Eater © (2005-10-30 16:21) [29]

Главное, что 3-х звенка с успехом используется именно для решения части проблем тонких каналов.

Это заблуждение

← →
Piter © (2005-10-30 17:49) [30]

Anatoly Podgoretsky © (30.10.05 16:01) [28]
А то и есть, другой язык и все

что другой язык?

Если про T-SQL и Pl/SQL - знаю, расширение от MS и Oracle соответственно.

А JSQL это тоже расширение от кого-то? КТо-то ведь придумал? :)

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

ну почему??? Может там реализована докачка данных.

Например, выполняется здоровенный INSERT, если в обычной ситуации у тебя разорвется связь - надо все сначала. А с трехзвенкой можно докачку сделать :)

Плюс даныне можно сжимать ZLIB"ом каким-нибудь, они будут меньше занимать, что для медленного канала выгоднее, верно?

← →
Sergey Masloff (2005-10-30 21:24) [31]

Reindeer Moss Eater © (30.10.05 16:21) [29]
>>Главное, что 3-х звенка с успехом используется именно для решения >части >проблем тонких каналов.

>Это заблуждение

...А мужики то и не знают ;-) Мы вот пользуем для этой цели именно. Уже много лет ;-))) Вроде полет нормальный. Просто не знали что оно не для этого ;-)

← →
Piter © (2005-10-30 21:37) [32]

Sergey Masloff (30.10.05 21:24) [31]

а каким образом используете для этой цели? Как я написал? Или чего еще?

← →
Reindeer Moss Eater © (2005-10-30 21:49) [33]

Допустим в приложении есть форма с гридом.
Если приложение двузвенное, на клиента в грид приедет Х байт данных.
Если приложение трехзвенное, в грид приедет примерно то же самое кол-во данных.

Вы скажете, что в трехзвенках у вас нет гридов?
Я скажу что и в двухзвенке гриды не обязательны.

Вы скажете, что прикрутили компрессию данных в трехзвенке?
Я скажу, что и к двухзвенке прикрутить можно.

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

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

Компрессия данных в трехзвенных приложениях - это не фича непосредственно трехзвенки.
Я, например, могу соединиться диалапом с сервером БД и у меня в двузвенном приложении будет компрессия данных. Мопед будет жать их.
Это только один пример.
Можно привести пример и чисто программного решения компрессии в двузвенных приложениях.

← →
Piter © (2005-10-30 22:18) [35]

Reindeer Moss Eater © (30.10.05 21:56) [34]
Можно привести пример и чисто программного решения компрессии в двузвенных приложениях

например???

Если сама база данных не поддерживает компрессии?

По любому будешь ставить некую прослойку, разве нет? А это и суть есть трехзвенка.

← →
Reindeer Moss Eater © (2005-10-30 23:57) [36]

Да например шлюз, работающий на уровне TCP/IP.
Он ни малейшего понятия не имеет ни о сервере БД ни о клиенте.
И он не может считаться звеном многозвенной системы.
Он просто жмет поток и все.
Либо я начну утверждать что любой коммутатор/свитч/маршрутизатор между сервером и клиентом это тоже звено многозвенки.

Нету у многозвенных приложений задачи экономии трафика. Нету и все.
Никогда не было таких задач.

А все что вы прикручиваете к своим трехзвенным системам точно так же прикручивается к двузвенным.

← →
Zacho © (2005-10-31 00:11) [37]

Reindeer Moss Eater © (30.10.05 21:56) [34]

Дело не только и не столько в компрессии. В основном, с помощью 3-х звенки решаются проблемы с обрывами соединения. Я же специально написал "медленным и ненадёжным каналам (например, dial-up)."

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

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

1.Рабочая станция с клиентом Оракла 172.1.1.1
2.Сервер Оракл 172.1.1.2

На клиента ставим сервис, который слушает порт 1522 и все что выслушает там жмет и посылает на тот же порт хоста 172.1.1.2
На 172.1.1.2 такой же сервис все что принял с 1522 расжимает и посылает в порт 1521 локальной машины, а все что прочитал оттуда шлет сжимая обратно на порт 1522 хоста 172.1.1.1

Клиент Оракла настраивается на localhost порт1522

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

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

В основном, с помощью 3-х звенки решаются проблемы с обрывами соединения.

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

← →
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 записей содержит входные
> параметры для некой (абстрактной) процедуры которая к БД
> (по большому счету) не имеет отношения. Зачем выполнять
> эту процедуру на сервере БД?

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

← →
Sergey13 © (2005-10-31 13:52) [69]

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

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

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

← →
Reindeer Moss Eater © (2005-10-31 16:21) [71]

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

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

← →
Курдль © (2005-10-31 16:26) [72]

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

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

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

← →
Reindeer Moss Eater © (2005-10-31 16:35) [73]

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

← →
Piter © (2005-10-31 17:48) [74]

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

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

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

← →
Reindeer Moss Eater © (2005-10-31 19:46) [75]

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

← →
Anatoly Podgoretsky © (2005-10-31 19:56) [76]

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

← →
Polevi © (2005-11-01 08:13) [77]

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

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

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

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

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

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

Курдль © (31.10.05 13:00) [62]

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

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

Меня, как автора вопроса, интересовало именно это "иногда". Коллеги, приведите лучше примеры ситуаций когда без многозвенки просто не обойтись! И на чем по вашему мнению их лучше создавать - CORBA, DataSnap или что-то VS-нетовское? Слышал, что используя .NET многозвенки пишутся НАМНОГО быстрее и качественнее. Это так или просто маркетинг?

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

> Juice © (01.11.05 10:15) [81]
> Меня, как автора вопроса, интересовало именно это "иногда".
> Коллеги, приведите лучше примеры ситуаций когда без многозвенки
> просто не обойтись! И на чем по вашему мнению их лучше создавать
> - CORBA, DataSnap или что-то VS-нетовское? Слышал, что используя
> .NET многозвенки пишутся НАМНОГО быстрее и качественнее.
> Это так или просто маркетинг?

Готов забожиться, что круче, чем "VS-нетовское" я еше не видел!
Изучите книжку "Microsoft .NET Remoting" (Скотт Маклин, Джеймс Нафтел, Ким Уильямс) и вопросов не будет.

> Изучите книжку "Microsoft .NET Remoting" (Скотт Маклин,
> Джеймс Нафтел, Ким Уильямс) и вопросов не будет.

Оно и было, вспомнил. Штука действительно волшебная судя по описанию. Но все таки скажите свое веское слово в сторону DataSnap, стоит ли тратить время и практиковаться в ней или нет ? Думаю что нет, но хочу услышать подтверждение своим словам. Этим я закрою для себя тему "технологии Borlanda", не в том плане что забью на них :) а просто наконец-таки все станет на свои места - что когда и в каких случаях использовать.

> Но все таки скажите свое веское слово в сторону DataSnap

К сожалению не могу сказать от себя, т.к. не работал с ней. Но мои коллеги, которые работали с DataSnap, ни в какое сравнение с .NET Remoting ее не ставят.
Лучше я скажу свое слово в сторону .NET Remoting.
С ее помошью можно создать весьма эффективную распределенную систему, даже не углубляясь в ее изучение, а используя примеры на уровне "Hello? World!"
Основа ее идеологии - создание объекта (класса), который реализован и "установлен, активирован..." на одном домене, а используется приложениями на других доменах (компах, хостах и т.п.).
Т.е. описываете класс с методами типа FillSubjectsDataSet(out DataSet ds)
так, что в его теле происходит доступ к БД (это сторона сервера приложения).
А со стороны клиента вызываете эти методы "как родные".
Т.е. вызов со стороны клиента метода навроде RemoteObject1.FillSubjectsDataSet(out ds); вернет датасэт ds, заполненный нужными данными. (А датасэты в .NET - многотабличны и включают в себя релэйшны и констрэйнты).

> ANB © (01.11.05 09:57) [79]
> Трехзвенка в этом все равно не помошник. SQL у оракла и
> MS SQL настолько разный (особенно хранимок), что чтобы обеспечить
> совместимость хотя бы на уровне запросов, придется перейти
> на ANSI и жестоко потерять в производительности и возможностях.

Это что за догма про потерю производительности?
Зачем нужны ХП, если бОльшую часть работы по защите целостности данных в процессе их ввода, модификации и удаления берет на себя ADO.NET? Насчет триггеров еще можно поспорить, но без ХП отлично работается!

> А датасэты в .NET - многотабличны и включают в себя релэйшны
> и констрэйнты

Может у меня мозги уже высохли, но толку от многотабличности не увидел.
А связи и ограничения - так за ними и так база следит

> Зачем нужны ХП, если бОльшую часть работы по защите целостности
> данных в процессе их ввода, модификации и удаления берет
> на себя ADO.NET?

Как по мне, так защищать как то надежней средствами самой базы, ну а если с нервами не в порядке так еще и в приложении можно затычек наставить:).

Все ИМХО - .NET этот только пощупал и расстроился, один фиг само не кодится :(
:)

> Зачем нужны ХП, если бОльшую часть работы по защите целостности
> данных в процессе их ввода, модификации и удаления берет
> на себя ADO.NET?

Может это и справедливо для MS SQL, т.к. T-SQL довольно ограниченная штука и на клиенте(сервере приложения) многое проще реализовать (ИМХО). Однако на PL/SQL реализуют полностью логику бизнес приложений, используя в качестве клиента обычный браузер. Плюс - хранимки в оракл таки быстрее клиентской обработки.

> TohaNik © (01.11.05 13:56) [87]
> Может у меня мозги уже высохли, но толку от многотабличности
> не увидел.
> А связи и ограничения - так за ними и так база следит

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

> Как по мне, так защищать как то надежней средствами самой
> базы, ну а если с нервами не в порядке так еще и в приложении
> можно затычек наставить:).

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

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

Хочу .Net !!!. Вообще то гуляла у меня мысля занятся этим в делфи. Но если .Net так крута, то зачем изобретать велосипед. Хотя берут меня жмуткие сомнения, что это все корректно работает и без ручного программирования. Иначе зачем бы народ покупал дорогущий Oracle Application, в котором без ручного программирования все равно не обойтись ? Все имхо.

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

> ANB © (01.11.05 16:28) [90]

Без ручного программирования - никак! Я этот пример про трехзвенку прям с открытого проекта привожу. Точнее с решения (solution), которое включает 11 проектов (около 4000 файлов). Но в VS это настолько запросто живет и поддерживается, что не замечаешь масштабности.
Однозначно скажу, что есть предел глобализации проекта, когда уже усложнять невозможно - все рушится, друг с другом не согласуется, конфликтует и т.п.
У Делфей этот порог гораздо ниже.
А на "Oracle Application, forms, discoverer..." или на САП любят себя автоматизировать крупные монстроидальные корпорации. Во-первых, бабло удобно списывать, во-вторых - штат невдолбенно дорогих спецов "из своих" прикармливать и понты бросать. Есть предубеждение, что на "полупрограммируемых полуфабрикатах" типа перечисленных или даже совсем убогонькой 1С, поддерживать и совершенствовать систему проще. Типа "не в исходниках копаться, а модулями ворочать и скрипты подстраивать".

> Val © (01.11.05 16:31) [91]
> ...а в триггерах дублирование кода :) зачем вслепую отказываться
> от предлагаемых возможностей сервера? все равно ведь в теле
> триггера на диалекте писать будете :)

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

> Курдль © (01.11.05 15:30) [89]

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

Например есть у нас ИНН на тыщ 20 контрагентов, ну не вижу я смысла проверять ни на каком уровне кроме как самой базой, тоже со счетами в комбинации с МФО.
Ну всеравно это "всем списком" не приведет ни к чему хорошему, тем более чем больше связей в сущности(многотабличном датасете) тем быстрее и не приведет.

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

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

Ну почему не поверим, охотно поверим, наверняка причины были.
Оч интересно какие?

> TohaNik © (01.11.05 16:59) [94]
> Ну всеравно это "всем списком" не приведет ни к чему хорошему,
> тем более чем больше связей в сущности(многотабличном датасете)
> тем быстрее и не приведет.

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

> Val © (01.11.05 16:59) [95]
> непонятно, к чему вы это...я оспариваю ваше высказывание о ненужности хп вообще-то :)

А я не говорил о не нужности ХП в глобальном масштабе. Я говорил, что без них легко можно обойтись на уровне сервера приложений, если требуется проект, который может быть приспособлен к какой угодно СУБД на выбор заказчика. И это все вытекало из пользы трехзвенки, что напрямую связано темой топика! :)

> Разве не прЭлЭстно, когда датасэт копирует часть модели
> БД? Уверяю, что это весьма упрощает понимание БД, пограммирование
> доступа к БД и служит дополнительной защитой целостности
> данных.

Неужели без понимания БД стоит этот датасет создавать.
Что значит дополнительная защита целостности? Если она дополнительная в приложении к защите в базе то ее смысл наверняка в пояснительных диалогах и т.п., если нет то она не дополнительная, а основная т.к. база эту целостность не обеспечивает.

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

> Я не придираюсь, просто был свидетелем и потенциальным участником
> проекта с использованием этих самых многотабличных датасетов.

А я не могу понять, разве работа с сущностью, которая предполагает использование пяти таблиц, легче происходит с пятью разрозненными делфевыми датасэтами, чем с одним пятитабличным ADO.NET-овским?

> Неужели без понимания БД стоит этот датасет создавать.

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

> И как же удобно, когда на экране открыта схема датасэта,

А никто и не спорит что видеть удобно, я про "всем списком" из [89], тем более для пяти таблиц. Для того же контрагета, в чем преимущество вставки скопом шапки и и списка банковских реквизитов?

> пятью разрозненными делфевыми датасэтами

Разрозненный он и один может быть, смотря что понимать по разрозненностью.

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

> Polevi © (02.11.05 10:03) [103]
> непонятно нафига тащить схему хранилища на клиента
> клиенту вообще по барабану в каком виде это все хранится

Ты не работал с VS.
Повторю свой пример - датасэт с таблицей юриков, их сотрудников и их банковских счетов.
"Бросаешь" такой датасэт на форму, бросаешь туда же DataGrid а лучше - dxControlGrid и получаешь таблицу с раскрывающимися нодами (типа аутлук), в которых на верхнем уровне иерархии юрики, а на следующем - все остальные.
Кроме того, я считаю бесценной возможность "гулять" по релэйшнам типа GetChildRows, GetParentRow. Есть и другие приятные возможности, которые на "однотабличном" датасэте реализовывать затибидохаешься.

> "Бросаешь" такой датасэт на форму, бросаешь туда же DataGrid
> а лучше - dxControlGrid и получаешь таблицу с раскрывающимися
> нодами (типа аутлук), в которых на верхнем уровне иерархии
> юрики, а на следующем - все остальные.

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

Ну все, мне уже тяжко спамить на эту тему :)
Я сам раньше очень любил программировать на ассемблере, но винды всю малину испортили. А теперь еще эта поганая .NET! :)

← →
freejack (2005-11-02 11:07) [108]

> Если не секрет какой проект имелся в виду? Что-то до боли
> знакомое...

Не думаю что знакомое...
Просто на одно из предприятий приехали бывшие советские граждане и решили показать как надо работать чтобы за год создать систему управления предприятием. А за год потому что VS и NET, а еще потому что они официальные представители MS. :)

← →
ali_tash (2005-11-02 19:54) [110]

они нужны чтоб откатать бабки за сервер приложений.

ГЫ ГЫ

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