То есть, данные от клиента летят в виде xml и обрабатываются на сервере последовательно, так, что бы не запетлять, в этом как раз таки и суть конфигурирования избавить себя от лишних тех. мыслей при решении задач "бизнес" за, что собственно нам и платят.

Serzh KZViPRosSerzh KZ,

налету агрегация - не фигня :)

А на лету где? при выборке или при вводе данных?

ViPRos ты не ответил?

ViPRos,

Нуу извини я не хотел пугать :) Просто хотел поставить точку над понятием "представление" или "view"
Это генерация, поэтому местами не симпотичная :)

iscrafm__МСУ,

возможно он имеет ввиду не кеширование на клиенте, а то, как работает любая ERP система. EDIT_ENTRY->POSTING->DATA_TRANSFORMATION&AGGREGATION. В отечественных системах это называется "проведением", в западных "posting", в BI - ETL и т.п., но суть одна. При этом отчетность оперирует уже подготовленными данными.

Спасибо, за разъяснение, в общем я теперь более уверений себя чувствую, что это не плод моей фонтазии :)

МСУSerzh KZНа сколько я помню был вопрос, что я даю на вход пивотгриду, на стороне клиента, я ответил, что любую таблу. Я, что то пропустил?
Это есть зло. Сколько дней будет думать твой пивот грид, если факты будут несколько миллардов строк?

P.S. Ты так и не понял меня, о чем я писал тебе...

Мы ведь вроде уже оговорили, что не более 100 тыш строк :)
Т.е. для больших данных, я создаю промежуточную таблу с "агрегатными связями".

МСУ,

Создавать механизм OLAP-а, я пока не сабираюсь.

iscrafm__Чтобы не получилось как с постингом

А тут о чем речь? :)

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

МСУЗа кулинарию кубов на клиенте нужно расстреливать без суда и следствия.

P.S. Есть, конечно, исключения . Но это целые технологии с очень замороченными алгоритмами оптимизации, которые далеко не каждому под силу изобрести. Но я сомневаюсь, что это тот случай. Автор банально в лоб процессит на клиенте факты.
Эти отлично пережовывают десятки тыш строк на клиенте и не вижу пока проблем, что то дополнять туда, мне еще многое нужно организовать, разгоном работы тех или иных элементов, я займусь по позже и оптимизацией того, что генерится у меня в процедуры, тоже позже.
В любом случае, критика принята :)

iscrafm__Serzh KZiscrafm__,
Согласен, что мало осведомлен, тем что уже для многих очевидное :(
ток я не пытаюсь выдумывать, что то новое, я считаю это "Следствием" т.е. одно вытекает из другого, при решении каких либо задач :)
И все таки, я считаю, что применение каких либо методов или технологий не зная их имен, более существенней, чем знание о их существовании.
неправильное в корне мнение. Незнание о существовании, плюсах и подводных камнях какой-либо технологии приводит к тому, что через какое-то время, иногда достаточно продолжительное, разработчик попадает на множество проблем. Многие из этих проблем можно было бы обойти, зная о них заранее и зная о решениях, которые применяли ранее для борьбы с этими проблемами. На этом все начинания обычно и заканчиваются. Во-первых, переделывать уже нет ни времени, ни ресурсов, ни желания... А во-вторых, приходит понимание, что проще было бы воспользоваться чем-то готовым, только об этом не знал, потому что не поинтересовался историей вопроса, перед тем, как сесть творить
Принято.

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

iscrafm__Serzh KZiscrafm__,
Согласен, что мало осведомлен, тем что уже для многих очевидное :(
ток я не пытаюсь выдумывать, что то новое, я считаю это "Следствием" т.е. одно вытекает из другого, при решении каких либо задач :)
И все таки, я считаю, что применение каких либо методов или технологий не зная их имен, более существенней, чем знание о их существовании.
неправильное в корне мнение. Незнание о существовании, плюсах и подводных камнях какой-либо технологии приводит к тому, что через какое-то время, иногда достаточно продолжительное, разработчик попадает на множество проблем. Многие из этих проблем можно было бы обойти, зная о них заранее и зная о решениях, которые применяли ранее для борьбы с этими проблемами. На этом все начинания обычно и заканчиваются. Во-первых, переделывать уже нет ни времени, ни ресурсов, ни желания... А во-вторых, приходит понимание, что проще было бы воспользоваться чем-то готовым, только об этом не знал, потому что не поинтересовался историей вопроса, перед тем, как сесть творить
Хотел добавить, сам факт, что я вылез на форум и хочу критики, говорит о том, что я именно это хочу исправить у себя, т.е. я хочу знать как лучше решать те или иные задачи, тупо решить задачу, что бы просто решить не важно как я умею по жизни, если это требуют обстоятельства, от туда для меня не существует не решаемых задач.

МСУViPRosМСУ, автор просто вышел на тропинку джедая, которая может приведет его к магистрали, а может нет
многие просто топчутся в круге, а он вышел за круг
Пусть так, но век изобретения лисапедов давно ушел в прошлое. Модульность - вот оно что хорошо. Тем более, имея модульную популярную технологию (напр., SSAS) можно смело набирать отдельных специалистов именно по BI направлению. Специалисты именно по его системе вряд ли появятся на рынке. Опять же, стратегия.
SSAS не крутил, но использую SSRS и SSIS по началю я был доволен, что они есть.
Но к примеру SSIS все, что мне нужно было пришлось все решить в скрипте, вопрос нафига он мне тогда.
SSRS это не реально тормознючая "Х".
Считаю, что это все добро не для людей, а для маркетинга.