Локшин Марк ASCRUSмаксимум скорости (централизованная обработка в пределах сервера, без передачи всех данных, необходимых для расчета клиенту по сети)
Ну это смотря сколько и чего передавать. Сетка в 1ГБит + 50 celeron 2Гц на определенном круге задача сделают очень крутой сервер.
Да ладно, уже это сто раз обсасывали на "Сравнении СУБД". Пока что то не очень выявили в повсевдневной жизни такой круг задач. Причем даже на мои тесты, где примитивно через table scan одновременных 20 параллейных сессий ASA мучают 10 миллионов записей ФС-ники дали только теоретические выкладки, что если бы сеть была широкой, да клиентские машины не заняты антивирусами, да во время чтения никто не поставил блокировку с MessageBox, уйдя покурить ... то наверное бы на клиентских машинах все быстрее посчиталось, чем в КС. В общем одни если бы, да кабы :) Так что я думаю что тот круг задач, о которых Вы говорите настолько узок, что он никак не вписывается в то, что мы тут обсуждаем. И то, даже для того "узкого" круга задач я бизнес-логику вынесу на Application Server в 3-е звено и по любому не буду ее пихать в клиентское приложения, мешая интерфейс с сложной логикой расчетов в одном месте.

Локшин МаркА при чем здесь ФС-ники...
Так это главные "приверженцы" утверждения, что КС уступит ФС, если у ФС широкая сетка и мощные клиентские компьютеры и что получаются чуть ли не распределенные вычисления. Зайдите на форум "Сравнение СУБД", там 24 страницы обсуждения идет КС vs ФС, а фактически где выгоднее держать логику - на сервере или клиенте.

rcryoПеречитывая ваши топики пытаюсь по крупицам выудить полезную для себя информацию о вашей методологии, хочется отделить здравый смысл от пропаганды. Большинство аргументов вашей агитации идут для меня мимо кассы, а вот полезных крупиц по прежнему мало.
Пропаганды чего/кого ? Полезных крупиц каких ? Что именно Вы надеетесь от меня услышать - обычную истину, что централизованное управление при грамотной реализации и подходящей под условия задачи выгоднее в разработке и сопровождении разброса бизнес-логики по разным платформам ? Вы что то еще имеете в виду или Вы не согласны с этим ?

rcryoМожет поподробнее остановимся на этом?
авторпри граммотно проектировании метаструктуры описания обьектов, их параметров и связей
Я не буду обьяснять что такое обьект, аттрибуты, ссылки, методы, свойства и интерфейсы, думаю это Вы знаете. Однако все вышеперечисленное спокойно ложиться на РСУБД, правда не в той форме, которую мы привыкли видеть в ООП языках, пункты которые позволяют это сделать, я уже перечислили выше. Так что давайте сами поподробнее, что именно Вам здесь не понятно ?

Локшин Марк ASCRUSТак это главные "приверженцы" утверждения, что КС уступит ФС, если у ФС широкая сетка и мощные клиентские компьютеры и что получаются чуть ли не распределенные вычисления.
Гм, а чем же это не распределенные вычисления. Фактически теже идеи эксплуатируются в предлагаемой Вами трехзвенке (по поводу распределения вычислений). В принципе, 2-х звенку с логикой на клиенте при определенном подходе к проектированию системы на уровне ПО можно рассматривать как 3-х звенку :)
Я "предложил" 3-х звенку при условии "крайнего" случая, когда все остальное не помогло, т.е. реализуемая логика действительно требует распределенных вычислений, которые невозможно реализовать штатными средствами СУБД и внешними хранимыми процедурами на языках низкого уровня (Си, Java). Плюс хочу заметить, что в этот "крайний случай" не попадает работа по предварительной подготовке информации, которая будет храниться в БД как бинарная - здесь как раз выгоднее всего это делать на клиенте. Я думаю Вы согласитесь, что при проектировании приложений нельзя руководствоваться догмами "Только так, а не иначе". Желательно руководствоваться здравым смыслом, который правда очень серьезно зависит от опыта проектировщика БД. Поэтому я не понимаю людей, которые или все пихают на клиентское приложение или все пытаются вынести в виде обьектов на 3-е звено или же офисные документы пытаются обрабатывать прямо на СУБД. Из виденных/реализованных мною задач с достаточно тяжелыми алгоритмами расчетов и обработки информации были самыми сложными "Расчет зп", "Расчет коммунальных платежей" и "Расчет потребления электроэнергии промышленными абонентами". Вся бизнес-логика лежала на РСУБД и если ее ложили "прямо", сервера достаточно успешно справлялись с поставленной задачей, не требуя выноса логики на клиентские или третьи звенья. Думаю это достаточный факт, чтобы признать за современными РСУБД большую самодостаточность и функциональность для обработки информации, а не только ее хранения и поиска, что частенько еще практикуется (правда по множеству разных и бывает уважительных причин).