AXForum  
Вернуться   AXForum > Рынок > Microsoft и системы Microsoft Dynamics
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.04.2023, 13:54   #1  
axm2017 is offline
axm2017
Участник
 
1,901 / 295 (13) ++++++
Регистрация: 15.05.2017
Dynamics ax как заложник прошлого.
Слушая лекцию по разработке задумался что в принципе axapta находится в сильной зависимости от прошлого и решений для выхода не видно. В тренде параллельности и прочая

Толкнуло к этой простой мысли небрежное замечание лектора что сейчас тренд выноса любых constraint в код вместо бд. На самом деле может это глубокая вещь так как позволяет юзать разные бд и даже их микс.

Последний раз редактировалось axm2017; 01.04.2023 в 14:07.
Старый 01.04.2023, 17:42   #2  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от axm2017 Посмотреть сообщение
...axapta находится в сильной зависимости от прошлого и решений для выхода не видно.
Мне как-то сложно назвать систему, в которой бы не было зависимости от прошлых решений по назначению, архитектуре и т. п.
Старый 01.04.2023, 17:45   #3  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от axm2017 Посмотреть сообщение
...сейчас тренд выноса любых constraint в код вместо бд.
За более чем 30 лет работы в IT изменений трендов видел столько, что даже не могу сказать какой из трендов является "генеральной линией партии".

А уж "вынос constraint в код вместо бд." пожалуй кроме продуктов от Oracle делают в 99 из 100 систем (в которых структура базы задается внутри системы или фреймворка).

Последний раз редактировалось Raven Melancholic; 01.04.2023 в 17:50.
Старый 01.04.2023, 21:01   #4  
axm2017 is offline
axm2017
Участник
 
1,901 / 295 (13) ++++++
Регистрация: 15.05.2017
Вопрос реализации 20лет назад потоки и прочее было сложно. Сейчас это повседневность.
Axжестко привязана к ms sql что иногда забавно: так как многие в ms по легендам были не в курсе существования ax к примеру при каких то преобразованиях sql
Старый 02.04.2023, 17:01   #5  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от axm2017 Посмотреть сообщение
тренд выноса любых constraint в код вместо бд.
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Axжестко привязана к ms sql
Никак не связанные вещи. Если судить по тренду развития AX (2009 -> 2012 -> D365FO), то скорее идет тренд отвязки приложения от архитектуры БД настолько, насколько это возможно без значимой потери производительности.

К MS SQL AX очень условно привязана. Ну т.е. она конечно привязана, но используется далеко не весь функционал и логично предположить, что разработчики MS SQL могут не знать про АХ. Для них АХ - это один из бытовых потребителей MS SQL
__________________
Возможно сделать все. Вопрос времени
Старый 02.04.2023, 17:16   #6  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
...используется далеко не весь функционал...
Очень мягко и корректно сказано.
По моим ощущениям Акса использует примерно то, что заложено в MS SQL 2000. Только в DAX2012 хотя бы появилась поддержка возможностей MS SQL 2005 (или 2008, точно не помню) - использование полей индекса, включенных в индекс ,но не составляющих его сущность.
Старый 02.04.2023, 17:22   #7  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
На а когда в SQL 2005 вместо некоторых системных таблиц для отслеживания состояния работы перешли на соответствующие представления, то в Аксе не нашли ничего более правильного, чем просто убрать из меню форму отслеживания блокировок.
Старый 02.04.2023, 19:03   #8  
axm2017 is offline
axm2017
Участник
 
1,901 / 295 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Никак не связанные вещи. Если судить по тренду развития AX (2009 -> 2012 -> D365FO), то скорее идет тренд отвязки приложения от архитектуры БД настолько, насколько это возможно без значимой потери производительности.
Это фича скорее: так как разрабы аксаптеры вымирают ака класс то в МС привлекают обычных программистов а те тянут с собой фичи прогресса. Зачастую через ж как с теми же аналитиками.
Цитата:
К MS SQL AX очень условно привязана. Ну т.е. она конечно привязана, но используется далеко не весь функционал и логично предположить, что разработчики MS SQL могут не знать про АХ. Для них АХ - это один из бытовых потребителей MS SQL
Разработчтки ms sql нет но ax привязана и вряд ли отвяжут иначе совместимость и прочее станут под вопрос

Последний раз редактировалось axm2017; 02.04.2023 в 20:29.
Старый 25.04.2023, 09:53   #9  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,696 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от axm2017 Посмотреть сообщение
тренд выноса любых constraint в код вместо бд
Поясните, пожалуйста, что именно Вы понимаете под термином constraint применительно к Axapta. Какие именно constraint в Axapta есть в БД?

Цитата:
Сообщение от axm2017 Посмотреть сообщение
но ax привязана и вряд ли отвяжут иначе совместимость и прочее станут под вопрос
Поясните, пожалуйста, что именно Вы вкладываете в понятие "привязана к БД"?


Похоже, каждый понимает под этими терминами что-то свое
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 25.04.2023, 10:17   #10  
axm2017 is offline
axm2017
Участник
 
1,901 / 295 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Поясните, пожалуйста, что именно Вы вкладываете в понятие "привязана к БД"?
Буквальное. Вот захотел завтра postgresql под капот вместо ms sql и боюсь не получится.

Более подробно почему так подумал смогу наверное лишь после отпуска. Может и не прав но в моменте так казалось.
Старый 25.04.2023, 16:15   #11  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Любая система так или иначе оптимизирована под определённую БД... если она от БД использует чуть больше функций, нежели есть в MS SQL 2000. В этом контексте "оптимизирована" = "привязана", т.к. "захотел завтра postresql" не пройдёт даже для "захотел завтра накатить SP2" для объёмных баз.
Каждая БД по своему строит планы запросов. И если какие-то вещи оптимизировать для MS SQL, то в PL/SQL (Oracle) не факт, что "взлетит", если просто перенацелить приложение. Поэтому тут лишь вопрос - где вендор "поставил затычку" - на уровне инсталляции приложения или на уровне ограничения использования возможностей той или иной СУБД.
__________________
Возможно сделать все. Вопрос времени
Старый 25.04.2023, 18:29   #12  
axm2017 is offline
axm2017
Участник
 
1,901 / 295 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Любая система так или иначе оптимизирована под определённую БД... если она от БД использует чуть больше функций, нежели есть в MS SQL 2000. В этом контексте "оптимизирована" = "привязана", т.к. "захотел завтра postresql" не пройдет.
Не соглашусь: как понял из общения с try программистами тренды последнего времени выделять базы данных и общение с ними в отдельный слой. Фактически это позволяет в том числе и подменить бд (на слое логики нет завязки на то что это ms sql)
когда то это соблюдалось и для ax (кривинько и косенько но работало) когда был oracle и ms. Но потом понятно ушло.
Старый 26.04.2023, 01:28   #13  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Не соглашусь: как понял из общения с try программистами тренды последнего времени выделять базы данных и общение с ними в отдельный слой. Фактически это позволяет в том числе и подменить бд (на слое логики нет завязки на то что это ms sql)
когда то это соблюдалось и для ax (кривинько и косенько но работало) когда был oracle и ms. Но потом понятно ушло.
Мы немного о разном говорим.
1. (Из истории). Поддержка oracle и ms действительно была - но она была обусловлена не трендом выделения базы в отдельный слой, а тем соображением, что ранние версии АХ (ещё до MS) были заточены (=оптимизированы) под Oracle, а MS-у нужно было естественным образом продвигать свою СУБД. Собственно, когда массово был выбит Oracle из клиентов - тогда и решили его исключить из поддерживаемых СУБД.
2. Действительно - с помощью Azure Microsoft вполне может базы данных небольшого размера (это важно) - выделить в отдельный слой для возможности подмены БД.
3. Но... для нагруженных баз, где требуется быстрый отклик, где объёмы данных ощутимо велики ... этот тренд просто не подходит. "Ощутимо велики" - это такой объём данных, при которых для пользователя становится заметной разница в выборке "по индексу" или "без какого-либо индекса".

А дальше - крупные компании, которые готовы тратить кругленькую сумму на оптимизацию и ускорение - будут шлифовать запросы и там не то, что смена платформы - там установка сервис-пака будет проходить в стиле "с этой даты запускаемся и собираем грабли". И они будут привязаны к платформе (=оптимизированы)
Небольшие компании с небольшим объёмом данных - да, могут спокойно для себя мигрировать без боязни потери производительности.

А теперь, внимание - риторический вопрос. В интересах кого в первую очередь будут развивать свои системы производители платформ (MS, 1С, SAP, Oracle, ...)? В интересах крупных компаний, которые им приносят больше денег, но которых мало или в интересах небольших компаний, которые приносят несравнимо меньше денег, но которых может быть много в количественном выражении?

MS взял курс на крупных клиентов. И применительно к крупным клиентам вопрос кроссплатформенности вообще не ставится. У них цель - оптимизировать свой продукт (MS SQL) так, чтобы он хорошо работал с большими объёмами данных (ибо тот же Oracle до сих пор не удалось изжить).

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

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
rumicrosofterp: Dynamics AX на Convergence 2012 Blog bot Microsoft и системы Microsoft Dynamics 0 13.01.2012 11:11
Dynamics AX на Convergence 2012 Blog bot Microsoft и системы Microsoft Dynamics 0 13.01.2012 10:52
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:27.