Dynamics ax как заложник прошлого.

[axm2017]

Слушая лекцию по разработке задумался что в принципе axapta находится в сильной зависимости от прошлого и решений для выхода не видно. В тренде параллельности и прочая

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

[Raven Melancholic]

Цитата:

Сообщение от axm2017

...axapta находится в сильной зависимости от прошлого и решений для выхода не видно.

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

[Raven Melancholic]

Цитата:

Сообщение от axm2017

...сейчас тренд выноса любых constraint в код вместо бд.

За более чем 30 лет работы в IT изменений трендов видел столько, что даже не могу сказать какой из трендов является "генеральной линией партии".

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

[axm2017]

Вопрос реализации 20лет назад потоки и прочее было сложно. Сейчас это повседневность.
Axжестко привязана к ms sql что иногда забавно: так как многие в ms по легендам были не в курсе существования ax к примеру при каких то преобразованиях sql

[sukhanchik]

Цитата:

Сообщение от axm2017

тренд выноса любых constraint в код вместо бд.

Цитата:

Сообщение от axm2017

Axжестко привязана к ms sql

Никак не связанные вещи. Если судить по тренду развития AX (2009 -> 2012 -> D365FO), то скорее идет тренд отвязки приложения от архитектуры БД настолько, насколько это возможно без значимой потери производительности.

К MS SQL AX очень условно привязана. Ну т.е. она конечно привязана, но используется далеко не весь функционал и логично предположить, что разработчики MS SQL могут не знать про АХ. Для них АХ - это один из бытовых потребителей MS SQL

[Raven Melancholic]

Цитата:

Сообщение от sukhanchik

...используется далеко не весь функционал...

Очень мягко и корректно сказано.
По моим ощущениям Акса использует примерно то, что заложено в MS SQL 2000. Только в DAX2012 хотя бы появилась поддержка возможностей MS SQL 2005 (или 2008, точно не помню) - использование полей индекса, включенных в индекс ,но не составляющих его сущность.

[axm2017]

Цитата:

Сообщение от sukhanchik

Никак не связанные вещи. Если судить по тренду развития AX (2009 -> 2012 -> D365FO), то скорее идет тренд отвязки приложения от архитектуры БД настолько, насколько это возможно без значимой потери производительности.

Это фича скорее: так как разрабы аксаптеры вымирают ака класс то в МС привлекают обычных программистов а те тянут с собой фичи прогресса. Зачастую через ж как с теми же аналитиками.

Цитата:

К MS SQL AX очень условно привязана. Ну т.е. она конечно привязана, но используется далеко не весь функционал и логично предположить, что разработчики MS SQL могут не знать про АХ. Для них АХ - это один из бытовых потребителей MS SQL

Разработчтки ms sql нет но ax привязана и вряд ли отвяжут иначе совместимость и прочее станут под вопрос

[Владимир Максимов]

Цитата:

Сообщение от axm2017

тренд выноса любых constraint в код вместо бд

Поясните, пожалуйста, что именно Вы понимаете под термином constraint применительно к Axapta. Какие именно constraint в Axapta есть в БД?

Цитата:

Сообщение от axm2017

но ax привязана и вряд ли отвяжут иначе совместимость и прочее станут под вопрос

Поясните, пожалуйста, что именно Вы вкладываете в понятие "привязана к БД"?


Похоже, каждый понимает под этими терминами что-то свое

[axm2017]

Цитата:

Сообщение от Владимир Максимов

Поясните, пожалуйста, что именно Вы вкладываете в понятие "привязана к БД"?

Буквальное. Вот захотел завтра postgresql под капот вместо ms sql и боюсь не получится.

Более подробно почему так подумал смогу наверное лишь после отпуска. Может и не прав но в моменте так казалось.

[Raven Melancholic]

На а когда в SQL 2005 вместо некоторых системных таблиц для отслеживания состояния работы перешли на соответствующие представления, то в Аксе не нашли ничего более правильного, чем просто убрать из меню форму отслеживания блокировок.

[sukhanchik]

Любая система так или иначе оптимизирована под определённую БД... если она от БД использует чуть больше функций, нежели есть в MS SQL 2000. В этом контексте "оптимизирована" = "привязана", т.к. "захотел завтра postresql" не пройдёт даже для "захотел завтра накатить SP2" для объёмных баз.
Каждая БД по своему строит планы запросов. И если какие-то вещи оптимизировать для MS SQL, то в PL/SQL (Oracle) не факт, что "взлетит", если просто перенацелить приложение. Поэтому тут лишь вопрос - где вендор "поставил затычку" - на уровне инсталляции приложения или на уровне ограничения использования возможностей той или иной СУБД.

[axm2017]

Цитата:

Сообщение от sukhanchik

Любая система так или иначе оптимизирована под определённую БД... если она от БД использует чуть больше функций, нежели есть в MS SQL 2000. В этом контексте "оптимизирована" = "привязана", т.к. "захотел завтра postresql" не пройдет.

Не соглашусь: как понял из общения с try программистами тренды последнего времени выделять базы данных и общение с ними в отдельный слой. Фактически это позволяет в том числе и подменить бд (на слое логики нет завязки на то что это ms sql)
когда то это соблюдалось и для ax (кривинько и косенько но работало) когда был oracle и ms. Но потом понятно ушло.

[sukhanchik]

Цитата:

Сообщение от 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 до сих пор не удалось изжить).

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