22.05.2012, 18:32 | #1 |
Участник
|
Проведите ликбез по DAX, плиз )
Решаем сейчас на чем реализовывать проект по автоматизации бизнес процессов в телевидении, и один (основной вариант) это использовать Dynamics AX. Плюс есть уже введенные в эксплуатацию проекты сделанные на Delphi который хотелось бы как то интегрировать с Dynamics.
Dynamics AX потому что хочется "вживую" конфигурировать цепочки бизнес процесса, очень уж по разному на каждом канале они проходят. Проект только боком касается стандартных учетных функций, в 95% процентах операции никак не будут касаться денег и уж тем более бухгалтерии. 1. Имеет ли смысл делать на Dynamics AX сложные интерфейсы ? (по прикладной области там есть несколько мест где нужно делать довольно сложную графическую визуализацию данных - десятки тысяч записей из БД, на одной форме данные из пары десятков таблиц (тоже в графическом виде)). Скорее всего самописные контролы под всё это дело. Или лучше вынести это в отдельные third party модули и формы ? (если такое возможно конечно) 2. Можно ли авторизировать DAX через логины SQL сервера ? (это наверное уж совсем ламерский вопрос, но все же )). В предыдущем проекте используется довольно обширная и гибкая система авторизации которая как раз базируется на этом. 3. Работает ли клиент DAX c доступом к БД по интернет, что нибудь в стиле WCF, например ? Вообще есть часть проекта которая работает с большими обьемами данных - там нужно по максимуму оптимизировать работу с ними, отсюда и вопросы 5 Есть данные которые напрямую не играют роли в бизнес данных, в основном статистические - рейтинги, доли и тд. Они нужны для построения сложных интерфейсов, они используются при конечном просчете бизнес данных - но их миллионы записей в месяц, выбираются они или оптимизированными stored процедурами или динамическим SQL и вообще это все на грани производительности сервера. Имеет ли смысл заносить их в данные DAX или лучше хранить их рядом на том же SQL сервере а в DAX записывать только агрегации и конечные бизнес данные ? 6 Можно ли использовать stored процедуры для выборок в DAX ? Вообще у нас есть несколько путей на выбор --Набирать команду(или нанимать партнера) и писать все с нуля на DAX, если нужно использовать WinForms или WPF компоненты, если нужно писать эти компоненты с 0. --Использовать DAX как обвязку бизнес процессов и интегрировать с ним уже существующие системы на том же Delphi+AppLayer+SQL Server, где и обрабатывать сложные "документы". --Использовать DAX как обвязку бизнес процессов, а для сложных документов сделать обработку в виде подпроекта на Winforms+WCF+EF, ну или тупо на Winforms+ADO.NET Я понимаю что часть вопросов, наверняка не корректна вообще и в принципе, но сделайте скидку на ламерство, плиз )) Несколько дней уже читаю информацию про DAX, но какой то слитной картинки никак не получается. Заранее Спасибо за ответы ) |
|
23.05.2012, 08:53 | #2 |
Участник
|
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Сообщение от Andey
Есть данные которые напрямую не играют роли в бизнес данных, в основном статистические - рейтинги, доли и тд. Они нужны для построения сложных интерфейсов, они используются при конечном просчете бизнес данных - но их миллионы записей в месяц, выбираются они или оптимизированными stored процедурами или динамическим SQL и вообще это все на грани производительности сервера.
Цитата:
Наймите нормального внедренца для проведения предварительного обследования и помощи в выборе подходящей системы автоматизации. Такой проект будет стоить лишь несколько процентов от стоимости проекта внедрения системы и позволит сэкономить кучу времени, сил и средств в дальнейшем. |
|
|
За это сообщение автора поблагодарили: lev (5), Andey (1). |
23.05.2012, 09:21 | #3 |
Участник
|
Поддерживаю совет от gl00mie - вам будет крайне полезно провести короткую фазу для:
- описания бизнес процессов и входных-выходных данных для них - формулирования требований к системе - сбор используемых (и перспективных) шаблонов документов и отчетов, которые должны проходить через систему - провести анализ нескольких систем и подходов "путей на выбор" по принципу GAP\FIT анализа с требованиями к системе Если своими силами это все неподъемно, то нужно звать спецов фирму или фриланс. |
|
|
За это сообщение автора поблагодарили: Andey (1). |
23.05.2012, 12:27 | #4 |
Участник
|
Спасибо большое за ответ )
Тяжко квотить, отвечу плейн текстом ) Стандартный функционал Аксапты явно останется невостребованным. По поводу обьема данных и интерфейса - тут несколько вопросов ироничного плана по поводу больших обьемов данных и тд, но примите это как данность )) Именно эту задачу мы не решали, это новый проект, но и раньше в подобных случаях писали свои компоненты отображения. Это прикладная область такая, практически все разработки которые я видел на эту тему так или иначе решали проблему с нестандартным интерфейсом. А по поводу данных, очень смежно просто со статистикой - для расчета качественных характеристик некоторых документов нужно больше миллиона записей использовать, а для просчета KPI в реальном времени при редактировании нужно часть из них в интерфейс тянуть и тут же считать. Поверьте я уже не первый раз слышу скепсис по этому поводу, но он быстро исчезает по мере знакомства с прикладной областью. Идея же использовать DAX произошла из "MICROSOFT SOLUTIONS FOR MANAGING THE MEDIA SUPPLY CHAIN", там реализована часть нужной нам архитектуры со связующим звеном в виде DAX. Спасибо за ликбез по DAX ) на самом деле много прояснилось. |
|