Использование View как Data Source или Нормализация Базы Знаний в Axapta

[rohlenko]

Уважаемые коллеги!

Проблема в двух словах:

На сегоднешний день любой сложностти SQL запрос в .NET или JAVA можно использовать как Data Sources на форме. Как с этим работат в Axapta?

Объясню:

Передомной стал общий вопрос Нормализации БД. Дело все в том, что я пришел
В «мир Axapta» из «С++, C# , MSSQL» недавно, и продолжаю мыслить привычными
категориями. Сотрудники , которые с Axapta уже 4 года работают, пытаются меня убедить в том, что в Axapta не все возможно, по этой причине разрабоитка модели БД
будет вестись с учетом не сегоднешний день реальных представляемых возможностей
Axapta. К примеру введено правило не использовать Views! Причина для этого указывается весьма сущственная, то что Views не обнавлются на SQL Server при компиляции или синхронизации. При определенном количестве клиентов эта проблема
достигает размеров при которых использовния Views в Axapta становится просто мучением. Я лично этот факт не проверял, так утверждается коллегами.
Меня как то это вопрос задел. Дело все в том что, я пытаюсь внести предложения, пока еще можно на фазе разработке модели БД, максимально нормализировать и оптимизиролвать базу на что встречаю сопротивление, типо это в Axapta невозможно или проблемотично. Мои идеи по Версионизации Контрактов (сохранение истории изменения контракта по любому полю) отклоняются, и доходит до ужасстно неэфективных решений типа клонирования того же контракта со всеми его «потрахами». А я ходел Veiw исспользовать как Data Source на форме, с идеей того все равно как я разделяю физические таблици как Entity (Сущность). Т.е получается что Таблици разрабатываются так как Axapta может а не так как это идеально подходило бы для решения. Я почитал форум. Вот эта тема мне очень понравилась
http://www.axforum.info/forums/showt...ht=Data+Source

я понял что использования n- го количества Data Sources на форме , где каждая в свою очередь делает JOIN к другой делает возможным то что я думаю.
Можно ли Queries использовать как Data Source?
Какие будут мнения на счет всего этого? Кто нбудь встречался c подобной проблемоой? Могу ли я имет подообну свобооду в проэктирвании БД, как и в других языках, системах?

Заранее благодарен вам за ответ на достаточно не легкий вопрос.

С уважением

Виктор

[Alks]

Цитата:

Изначально опубликовано rohlenko
Уважаемые коллеги!
...
К примеру введено правило не использовать Views! Причина для этого указывается весьма сущственная, то что Views не обнавлются на SQL Server при компиляции или синхронизации.
...

У нас Axapta 3.0 SP 2 - всё обновляется, указанной проблемы с View нет.

Цитата:

Дело все в том что, я пытаюсь внести предложения, пока еще можно на фазе разработке модели БД, максимально нормализировать и оптимизиролвать базу на что встречаю сопротивление, типо это в Axapta невозможно или проблемотично.

Думаю это преувеличение. В Аксапте действительно нет 100%-ой поддержи стандартных средств SQL + иногда движок аксапты глючит и делает невозможным использование некоторых конструкций, но это достаточно редкие случаи.
Могу выделить наиболее проблемные места:
1. В Аксапте нельзя в SELECT-ах использовать ф-ии (т.е. например вычленить часть строки из поля невозможно, поэтому база должна быть МАКСИМАЛЬНО нормализована)
2. нет конструкции в WHERE типа [NOT] EXISTS (SELECT ...). Однако её почти всегда можно преобразовать в EXISTS JOIN, так что это не большая проблема
Других столь же мощных ограничений не припомню.

Цитата:

я понял что использования n- го количества Data Sources на форме , где каждая в свою очередь делает JOIN к другой делает возможным то что я думаю.

n-ые кол-ва датасоурсов на форме (где n - константа определяемая во время разработки) в Аксапте возможно сделать без труда. А вот что вы хотите с помощью этого добится не понятно. Если опишите вашу проблему попонятнее, скажу наверняка возможно это сделать или возможно только с очень большими трудностями.

[Ruff]

Цитата:

Изначально опубликовано Alks
Могу выделить наиболее проблемные места:
1. В Аксапте нельзя в SELECT-ах использовать ф-ии (т.е. например вычленить часть строки из поля невозможно, поэтому база должна быть МАКСИМАЛЬНО нормализована)
2. нет конструкции в WHERE типа [NOT] EXISTS (SELECT ...). Однако её почти всегда можно преобразовать в EXISTS JOIN, так что это не большая проблема
Других столь же мощных ограничений не припомню.

Я бы еще добавил:
3. Нет конструкции UNION, хотя решается в Query несколькими DataSource-ми одного уровня.
4. View-шки нельзя "ветвить", можно только "углублять", отсюда невозможность сделать UNION при помощи View, что весьма прискорбно

[Dron AKA andy]

Добавлю свою каплю пессимизма, напомнив, что вьюшки аксаптовские не работают при использовании механизма виртуальных компаний...

[wb]

Цитата:

Изначально опубликовано Ruff

Я бы еще добавил:
3. Нет конструкции UNION, хотя решается в Query несколькими DataSource-ми одного уровня.

хочется пример, по возможности
заранее благодарен

[Hamster]

>Добавлю свою каплю пессимизма, напомнив, что вьюшки аксаптовские не работают >при использовании механизма виртуальных компаний...

Добавлю стакан оптимизма - найден способ это обойти

[Dron AKA andy]

Поделитесь с общественностью, плиз.

[Hamster]

Все в моей статье...

[mazzy]

Hamster, а где эта статья?
Можно ли разместить на сайте у маззи?
если статья уже опубликована, то готов сделать ссылку.

[rohlenko]

Цитата:

У нас Axapta 3.0 SP 2 - всё обновляется, указанной проблемы с View нет.

У нас Axapta 3.0 SP 2 тоже.
Был бы очень признателен если бы вы описали конфигурацию софта (версию и SP MS SQL Server, используется ли AOS и.т.д.). Т.к. указанная проблема с View у нас есть, и я хотел бы выяснить при каких условиях она изчезнет.

Цитата:

n-ые кол-ва датасоурсов на форме (где n - константа определяемая во время разработки) в Аксапте возможно сделать без труда. А вот что вы хотите с помощью этого добится не понятно. Если опишите вашу проблему попонятнее, скажу наверняка возможно это сделать или возможно только с очень большими трудностями.

Я имел тут ввиду что если предположить,что действительно отказатся от View, то как же в одной форме показать в одном Grid данные происходящие от 2,3,4..... таблиц.
из примера в форме tutorial_Form_Join я сделал вывод, что можно создать на форме Data Source 1 потом Data Source 2 и наложить JOIN на Data Source 1 потом Data Source 3 и наложить JOIN на Data Source 2 и.т.д ....
Data Source 1 ------join---->Data Source 2-----join--------->Data Source 3---join----------->.....Data Source n, что в принципи я расчитывал сделать в View из соображений прозрачности решения и производительности.

[Hamster]

Статья про View в Axapta готовится к публикации.
Как добью - сразу пришлю...

[mazzy]

Спасибо

[Alks]

Цитата:

Изначально опубликовано rohlenko
У нас Axapta 3.0 SP 2 тоже.
Был бы очень признателен если бы вы описали конфигурацию софта (версию и SP MS SQL Server, используется ли AOS и.т.д.). Т.к. указанная проблема с View у нас есть, и я хотел бы выяснить при каких условиях она изчезнет.

MS SQL Server 2000, АОС (хотя и без него полюбому всё будет работать)

Цитата:

Я имел тут ввиду что если предположить,что действительно отказатся от View, то как же в одной форме показать в одном Grid данные происходящие от 2,3,4..... таблиц.
из примера в форме tutorial_Form_Join я сделал вывод, что можно создать на форме Data Source 1 потом Data Source 2 и наложить JOIN на Data Source 1 потом Data Source 3 и наложить JOIN на Data Source 2 и.т.д ....
Data Source 1 ------join---->Data Source 2-----join--------->Data Source 3---join----------->.....Data Source n, что в принципи я расчитывал сделать в View из соображений прозрачности решения и производительности.

Да, это легко делается, если n определяется на этапе разработки.

[Dron AKA andy]

To Hamster:
Как там статья поживает? Хочется все же узнать про использование view в виртуальных компаниях...

[Dron AKA andy]

Цитата:

Изначально опубликовано Hamster
Статья про View в Axapta готовится к публикации.
Как добью - сразу пришлю...

И вновь интересуюсь, как там обещанная статья поживает... Если я что-то пропустил - направьте по пути истинному.

Либо статья не написалась, либо user is dead