Serzh KZМСУпропущено...

Для этой "плюшки" ты тащишь все данные из БД, после всё это добро рендерится в гриде?
Если в качестве "плюшки" то, да любую таблу можно показать юзеру в виде куба, более того юзер имеет возможность настроить параметры вывода(фильтры) в любой табле для себя (отойти от дефалтных настроек), на стороне сервера.
В общем У меня юзер может выкатить всю таблу(представление) к себе, которые ему позваляют роли и потом переключать гриды.
Если решать конкретные задачи, то сперва конфигурю представление, со всей вычиляемой логикой и тп, потом так, же их в куб либо просто в обычную таблу, где можно группировать, фильтровать и все такое.
Ну продолжать, думаю, не стоит. Такой функционал - игрушка для юзера, не более того. Просто представь себе, что будет с твоим приложением, если пользователю потребуется по твоим фактам из сотен миллионов записей на десяти-двадцати измерениях состряпать выборку...
Для решения задачи нужно хранить твой где-то пространственную схему данных где-то в кешах (MOLAP). Нужен хостинг и агрегатов. Возможна реализация хранения фактов, измерений и агрегатов в виде обычных реляционных таблицах. По сути, ты изобретаешь ROLAP велосипед. Если потребуется масштабирование всей этой красоты, то нужен некий симбиоз подходов, который выливается в HOLAP велосипед. В результате на реализацию очередной OLAP системы у тебя уйдут годы. Зачем это надо? Возьми готовый BI и радуйся.

ViPRosМСУ,

вот ты показал статичный код
мне это не подходит
мне надо что бы такой шаблон сгенерировался налету и исполнялся
то есть в контроллере у меня должен быть один метод - ДайРожуМакротипа(Макротип)

http://www.umbraworks.net/bl0g/rebuildall/2009/11/17/ASP_NET_MVC_and_virtual_views
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx

ViPRosможно налету?
В том и замечательность HTML и view engine , что можно гуй собрать хоть на лету, хоть вплавь. Можешь UI вообще в виде строки хранить в БД.

ViPRosпотому я и хочу перепрыгнуть их и перейти на сенча кенду и т.д. которые один в один винформс :)
Ты сильно ошибаешься, потому что не понимаешь, о чём говоришь :)

ViPRosКоманда LoadMacrotype(...) из метаданных генерирует модель и вью и биндит вью в модель
тож самое мне надо для веб
Не понял. В каком виде у тебя получается сгенерированная модель? Object, dynamic, IModel?

Зачем что-то генерировать? У тебя в базе находятся все матаданные. С помощью Razor прям во вью ты типизированно отстраиваешь свой UI, описанный в метаданных.

ViPRosМСУпропущено...

Не понял. В каком виде у тебя получается сгенерированная модель? Object, dynamic, IModel?

Зачем что-то генерировать? У тебя в базе находятся все матаданные. С помощью Razor прям во вью ты типизированно отстраиваешь свой UI, описанный в метаданных.
модель сейчас у меня - обычный ДатаСет
Так выше я тебе для датасета отстроил простецкое вью. Ты чё мне моск насилуешь? :)

ViPRosу меня клиент контроилирует валидацию, всякие целостности, подгружает нужные связи для лукапов и т.д.
протсо нтмл с данными ниче не дасть
Так тоже самое можно делать и для html, только в разы проще. Вот, шарепоинт тому пример. Или мс црм.

Serzh KZУ меня, есть данные по ляму в год накапливаются
Ну это копейки. Вот по 10 лямов в день было бы уже поинтересней.

Serzh KZтак вот они пишут промежуточные таблы каждая для конкретных задач при чем редактируемые т.е. для них первые представляются регистрами все это работает на уровне связей.
На рисунке изображены, физ таблы которые заполняют верхнию, при чем первая в свою очередь может заполнять нижнии.
Да хоть во что не пиши, хоть в промежуточные таблицы, хоть в таблицы на луне - речь о хранении агрегатов, измерений, мер, пространственных схем. Только так можно добиться быстрого отклика и мгновенного расчета куба по заданным измерениям и фильтрам. В твоем же случае ты на клиента тащишь весь 1 млрд записей и приступаешь к агрегации в разрезе заданных измерений, которые юзер накликал в гриде. Это полный алес капут :)
Ты понимаешь о чем я пишу? У меня складывается ощущение, что мы говорим на разных языках...

Serzh KZНе надо так восполяться, я панимаю, о чем речь.
Я вроде как объяснил как я решаю проблему больших данных т.е. путем построения промежуточных данных плюс фильтрации на стороне сервера, где собственно и агрегатные вычисления хранятся в разрезе нужных измерений, если нужны иные измерения, то строю еще одну промежуточную все что можно порезать датой или еще каким либо значением режется на стороне сервера в виде "параметров" на скрине, он есть для всех табл, которые я создаю для каждой таблы индивидуальные или для всех , далее пользователь может изменить их тем самым отфильтровать не нужное для конкретного результата.
Как то так, могу еще как то изложить.
Так я ж, вроде, спокойно и объясняю, что твои "промежуточные" данные могут быть вполне приличной выборкой, которую придется тащить всем 100500 клиентам для пережевывания в гриде. Фильтры дело хорошее, но часто требуется делать выборки за достаточно широкий фильтовой диапазон. На фильтры надежда небольшая. Для аналитических задач нужен полноценный движок OLAP, который отложенно на BI сервере пережевывает куб в различных плоскостях. На клиент попадают только рассчитанные проекции, а не все твои бизнес факты.

ГхостикМСУУ меня складывается ощущение, что мы говорим на разных языках...Конечно на разных. Он тебе говорит, что у него лям в год, а ты ему про обработку миллиардов. Оценивай объем задачи прежде чем BI втюхивать.
Рассказал, что для большего текущий подход не годится, и достаточно - будет знать, что есть другие решения и выйдет на них при необходимости.
Сегодня лям в год, завтра функционал расширится, добавятся еще n систем, которые успешно проинтегрируются и... приплыли. Все начинают с "ляма в год". Я подсказываю автору о том, что если уже дело попахивает киросином доходит до аналитики, то не стоит изобретать велосипед. Намного лучше рассмотреть различные OLAP системы, в разрезе приемлемых условий лицензирования и их себестоимости. Писать поделку в гриде, который тянет на всех клиентов (к тому же двухзвенных) весь сред данных для пересчета по измерениям - идиотизм. Поэтому, планируя ERP систему, лучше завязываться на нормальные аналитические инструменты ведущих вендоров (SSAS + Excel + SSRS + SSIS, к примеру), а не заниматься мазохизмом.

Serzh KZПока, это у меня "плюшка-игрушка" для пользователя, что бы смотреть на не большие данные(до 100 тыш. строк) в виде куба далее выводить на печать для начальства (начальство любит кубики).
Ну, наконец, мы поняли друг друга :)
Самое главное нужно понимать, когда наступит час икс (наработаете приличный объем данных или потребуется интеграция с данными других систем), начальство может расстроиться тем, что кубики начинают собираться часами / днями / неделями.

Serzh KZВ настоящий момент у меня клиент нормально пережовывает 300 тыш. строк в действительности для аналитики из наблюдений им нужно около 10тыш максимум, т.е. решают фильтры на стороне сервера.
Ну это да, тормозов не должно быть особенно.

Serzh KZТо есть всему свое время, я прикрастно понял о чем речь, МСУ :)
Ок :)

Сахават, комьюнити требует веб морду!