Форум: "Базы";
Текущий архив: 2005.12.18;
Скачать: [xml.tar.bz2];
ВнизЗачем нужны многозвенки ? Найти похожие ветки
← →
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, там такие люди есть. Да и здесь, возможно, найдутся. Вот, Сергей Маслов, например.
Страницы: 1 2 3 вся ветка
Форум: "Базы";
Текущий архив: 2005.12.18;
Скачать: [xml.tar.bz2];
Память: 0.57 MB
Время: 1.869 c