Цитата:
Сообщение от
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 - сервера ни то, ни другое не имеет никакого отношения.