iscrafm pkarklinГм... Это было описание архитектуры eBay.
Вы про это что-ли ?
То что SP выкинули, тригеры вижу... Чтобы join-или не вижу. Хотя правильно некоторые подмечают, что бывают ситуации когда такие операции быстрее сделать самому.

Страница 22

Ну, чего уж. Давайте и обеспечение ACID на сторону апп.сервера унесем. Так еще сотню лимонов строк кода можно написать.

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

Прохожий..... pkarklin
Вас послушать, так зачем люди ASP.NET учат, трехзвенки городят?
Взять да и перейти всем на прямые коннекты к MSSQL, кстати я непонял где автор вообще сказал, что он хочет MSSQL?
И юзать эти прямые коннекты наверно так:
Тынц

Гм... Это ВЫ спросите у тех, кто учит и городит. Свою точку зрения я уже изложил, причем неоднократно и не только в этом топике.

Это м.б. не MS SQL, а любой из серверов большой тройки.

Чем Вам, собственно, тынц, не понравился?

Прохожий.....Городим...
И будем городить, на данный момент горожу четырехзвенку на тех самых веб-сервисах. И жутко доволен! Если бы стали делать это же самое в двузвенке, получислось бы намного сложнее и геморойнее!

Ну, что ж. Я с удовольствием (говорю это без иронии) послушаю Вашу success story. Очень будет интересно в деталях узнать, при реализации какой функциональности и какой геморой с его реализацией на двузвенке заставил Вас принять решение о разработке N-звенки. Можно пару примерчиков?

iscrafmНа ту же сортировку списка дергать СУБД накладно.

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

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

Гм... А почему бы кластер с балансировкой нагрузки не сделать (Oracle RAC). Ну или Federated Database Servers на базе MS SQL? Зачем супер компютер?

Прохожий..... Вы живете по принципу - "Зачем просто, если можно сложно"?

Гм... Мне кажется, все как раз наоборот.

Прохожий..... Ну а загрузку каналов клиентов которые тоже от 64к до 256к на клиента, как распределить?

Куда чего Вы хотите распределять? У Вас же клиенты на узком канале сидят, а не сервер?! Или...???

авторУ меня например часть инфы от клиента идет на головной сервер ночью, предлагаете городить очередные спагетти?

Пусть идет. Макароны тут причем?

авторИли держать 10-30 компов в региональных отделениях круглосуточно подключенными к головному серверу?

Нужны данные - подключены. Не нужны - не подключены.

iscrafmмы об он-лайн сервисе говорим? Какая тут классическая двухзвенка. Это уже крайность, но с другого конца только. :)

Вы о чем?

Прохожий..... Я распределяю нагрузку по ВРЕМЕНИ, если 10 клиентов одновременно начнут таскать десятки мегабайт инфы работа встанет!

Они у Вас действительн по столько инфы таскают? Что за инфа?

авторДанные нужны головному серверу, а не им!

Так почему же Вы отвергли идею с репликацией? Выбранная Вами СУБД не позволяет?

2 iscrafm

Вот Вы о чем... Чем Вас не устроила моя "локальная сортировка"?

2 Прохожий.....

Понятно. Лучший способ защиты - это нападение.

ПрохожийВы вот тут громче всех кричите, автору нужна двузвенка.

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

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

Думаю, тысяч за $5 000 я бы взялся набросать техническую архитектуру для автора, но при наличие чуть более подробного ТЗ. Советы я могу давать бесплатно. На "слабо" меня брать не надо. Пока от Вас я только и слышу что "это будет работать медлено", это "вообще не реализуемо" без каких-либо расчетов скорости и затрат на реализацию.

авторЯ действительно не видел столь масштабных и приемлемо работающих двузвенок, может ВЫ нам откроете глаза?
Дерзайте! Нам всем уже интересно!

Я Вам уже упоминал о крупной компании-дистрибьютере, имеющую филиалы в 80 регионах (от Калиниграда до Владивостока) в которых работает двузвенка + репликация.

Сорри, рука дрогнула... Продолжу про репликацию.

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