Об альтернативном программировании SQL-сервера в Dynamics AX

[glibs_imported]

IMHO, не достаточно объективный подход в статье. В частности, авторы упускают в статье следующие аспекты.

1. Двухуровневая архитектура клиент-сервер, которая так ярко описывается в статье, в настоящее время уже устарела. И ей на смену пришла трехуровневая.

2. Одним из факторов не использования хранимых процедур и примитивного SQL является кросс-платформенность.

3. Для OLTP систем тяжелые процедуры и тяжелые SQL-запросы в совокупности с тяжелыми триггерами не всегда оптимальны. Могут возникнуть тяжелые блокировки, что будет тормозить работу пользователей на OLTP операциях. Чем больше пользователей в системе — тем актуальнее проблема. Альтернативный подход к решению проблемы можно посмотреть в Аксапте в процедуре многопользовательского закрытия склада.

4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД. Либо делать распределенные БД. Последнее далеко не всегда приемлемо или эффективно. А отдача от дополнительных вложенных ресурсов в одну коробку имеет тенденцию к снижению, начиная с определенного предела. То же самое касается большого количества машин в кластере. Сервера приложения масштабировать легче, а при их использовании нагрузка на ресурсы серверов БД снижается.

В общем, необходим сбалансированный подход.

[mazzy]

Цитата:

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

4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД.

Нормально двузвенка масштабируется: Можно устроить кластер из БД.

Согласен, что нужен сбалансированный подход.

[Palevo]

Цитата:

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

1. Двухуровневая архитектура клиент-сервер, которая так ярко описывается в статье, в настоящее время уже устарела. И ей на смену пришла трехуровневая.

Трехуровневая схема или в просторечии «трехзвенка» еще называется «тонкий клиент». Почему? Потому, что ее цель – экономия ресурсов клиентской станции, а не повышение эффективности обработки данных. Девиз трехзвенки – «работать в axapta с мобильного телефона». В пределе, трехзвенка превращает локальную сеть компьютеров в мультитерминальный комплекс. Вычислительные ресурсы N – компьютеров (клиентских станций) заменяются ресурсами всего одного компьютера (сервера приложений). Если производительность этого компьютера имеет тот же порядок, что клиентская станция, то эффективность обработки данных не увеличивается, но падает в N – раз!
Алгоритмы же обработки данных, к которым наши основные претензии, одинаковы, что в трехзвенке, что в двухзвенке, как и сказано в статье.

Цитата:

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

2. Одним из факторов не использования хранимых процедур и примитивного SQL является кросс-платформенность.

Главной целью выработки стандарта языка является «переносимость» написанных на нем текстов. Поэтому, для того, чтобы быть «кросс-платформным», подъязыку SQL-axapta следует догонять стандарты SQL-92 и SQL-2000, а не оставаться в реликтовых диалектах.

Цитата:

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

3. Для OLTP систем тяжелые процедуры и тяжелые SQL-запросы в совокупности с тяжелыми триггерами не всегда оптимальны. Могут возникнуть тяжелые блокировки, что будет тормозить работу пользователей на OLTP операциях. Чем больше пользователей в системе — тем актуальнее проблема. Альтернативный подход к решению проблемы можно посмотреть в Аксапте в процедуре многопользовательского закрытия склада.

Во-первых, мы не утверждаем, что «альтернативное программирование сервера» всегда оптимально. Мы указали в статье ряд задач, в основном пакетной обработки, когда оно дает очевидную выгоду. Во-вторых, обращения axapta к базе данных заканчиваются тем же самым стандартным SQL, реализованным на сервере, и с успехом могут быть источником «тяжелых блокировок» при неудачном программировании. В-третьих, мы считаем, что близкий к оптимальному код может быть написан и на существующем подъязыке SQL – axapta, только стиль программирования должен быть другим.

Цитата:

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

4. Запросно-триггерное программирование имеет узкое место — сервер БД. Двухзвенка тяжело масштабируется. У вас есть только один вариант — наращивать ресурсы сервера БД. Либо делать распределенные БД. Последнее далеко не всегда приемлемо или эффективно. А отдача от дополнительных вложенных ресурсов в одну коробку имеет тенденцию к снижению, начиная с определенного предела. То же самое касается большого количества машин в кластере. Сервера приложения масштабировать легче, а при их использовании нагрузка на ресурсы серверов БД снижается.

Масштабирование – это привлечение аппаратных и программных средств для снижения времени ожидания выполнения запросов к серверу. Речь идет о создании собственного экземпляра сервера для каждого пользователя (отдельная машина, отдельный процессор, реплика базы данных). В этом смысле двухзвенка – аппаратно масштабированная клиентская часть программы, а трехзвенка, в которой клиентские части спроецированы на сервер приложений (на одну машину), только программно масштабированная клиентская часть. К масштабированию SQL - сервера ни то, ни другое не имеет никакого отношения.

[Vadik]

Цитата:

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

Главной целью выработки стандарта языка является «переносимость» написанных на нем текстов

Как Вы оцениваете трудоемкость переноса отчетов, разработанных по Вашей методике, на другую СУБД по сравнению со стандартными отчетами Axapta?

Цитата:

Поэтому, для того, чтобы быть «кросс-платформным», подъязыку SQL-axapta следует догонять стандарты SQL-92 и SQL-2000, а не оставаться в реликтовых диалектах.

Полагаю, это случится не раньше, чем T-SQL и PL/SQL на 100% реализуют стандарт ANSI (хотя бы ANSI 92). Т.е. никогда

[glibs_imported]

Цитата:

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

...
Потому, что ее цель – экономия ресурсов клиентской станции, а не повышение эффективности обработки данных.
...

Опять однобоко. Трехзвенка в отличии от двухзвенки способна (в конечном итоге все зависит от разработчика) обеспечивать защиту данных. Двухзвенка этого не делает. Т.е. в трехзвенке возможна реализация контроля доступа на прикладном уровне, причем не на клиенте. В двухзвенке сам клиент имеет "доступ к телу" сервера СУБД. Что как минимум чревато атаками на сервер с самым ценным (т.е. с данными). При работе в трехзвенке сервер с данными может быть далеко запрятан (недоступен снаружи).

На примере той же Аксапты хорошо это просматривается (3-я версия работает в режиме толстого и "полутонкого" (в смысле не классический mainframe терминал) клиента).

Это вопрос терминологии, но при реализации трехзвенки клиент не обязан быть предельно тонким, как вы пишете. Я на терминалах не комплексную. Даже браузер не является тонким клиентом с т.з. классической теории.

В общем, я не сторонник терминалов, а сторонник распределения обработки информации по трем узлам (хранилище - прикладной сервер - клиент).

При таком подходе можно выиграть на трафике.

И последний для вас пример. Решает ли (упростим формулировки в предложениях) MS SQL (пусть будет с использованием T-SQL) задачи построения сложной отчетности? А для чего тогда MS выпустил OLAP?

PS. Я сам довольно часто использую прямые запросы к базе. Практически всегда работает быстрее. Но в базе в таких случаях я, как правило, работаю один. А запросы использую для решения аналитических задач, чаще разового характера. (Чтобы никто не подумал, что я враг SQL).