original
технические аспекты (максимально сжато, но достаточно подробно и из личного опыта, всё ИМХО):
ИСПОЛЬЗУЕМЫЕ СУБД:
Navision Server
Navision Server - примитивный безSQL серверок, просто подающий записи на клиента. Ни с кем другим не совместим и не похож.
До 140Гб данных, Не более 1Гб ОЗУ, 1CPU. Поддерживает только одну (!) базу.
Для использования 2-х баз нужно ставить 2 копии сервера :).
Для работы в однопользовательском режиме сервер вообще не нужен и Navision работает с файлом данных подобно ACCESS с *.MDB,
но в отличие от ACCESS второй пользователь уже не зайдёт :)
Сервер работает довольно шустро, но при небольшом кол-ве юзеров, а когда их около 30, и кто-то запустил сложную задачу,
легко добиться сообщения "Кеш переполнен. Подождите", хотя при этом размер кеша достаточен.
Navision Server использует только блокировку на уровне таблицы, поэтому, если делается какой-то масштабный update/delete/insert в
важной таблице (например "Товарный журнал") то все ждут окончания всей операции, которая может продолжаться минутами.
Чтобы изменить данные в наборе строк, их нужно пробежать и для каждой строки программно поменять, что создаёт большой траффик.
Есть понятие транзакции. Даже если действие шло 5 мин. и на последней строчке прошло с ошибкой, все сделанные этим батчем модификации отменяются.
Механизм надёжен и работает по умолчанию. Есть возможность делать COMMIT в процессе выполнения батча.
Нет понятия "Дата с сервера". Все даты идут с клиента.
Приличных ODBC драйверов не встречалось. Те, что встречались, использовать нельзя, из-за вопиющей кривизны.
Изменять данные не через Navision-Client опасно, т.к. триггеры на таблицах в этом случае не работают.
Наверно единственный сервер, где размер базы нужно увеличивать вручную (!), и следить за свободным местом.
Нагружает CPU слабо т.к. практически отсутствуют собственно-вычисления. Ведёт себя стабильно т.к. просто устроен.
Стабилен. Потери данных наверно редкое явление.
MSSQL
часто используется в качестве СУБД. Как правило из-за возможностей наращивания производительности и построения отчетности.
При маленьких объёмах данных всё работает хорошо. Но на больших объёмах (>50Гб) ситуация резко меняется, т.к. MSSQL не любит широких таблиц с сотней полей, из которых большинство - текстовые... :)
Скорость роста базы - примерно 1.5 от аналогичной в Navision Server.
Никакой логики на стороне сервера не хранится. Никаких ХП , view, триггеров. Вся логика выполняется на клиенте. Как собственно в большинстве аналогичных систем.
Ввиду сложной организации данных, делать репортинг внешними средствами - занятие не из приятных. Даже на MSSQL.
Navision - двухзвенка. Иногда за 3-е звено некоторые пытаются выдать Navision Application Server, который не более чем клиент без интерфейса.
Запускается как служба и служит для выполнения репликации и заданий по расписанию. Работает чуть быстрее обычного клиента.
Репликации:
Репликции - только On-Line, т.е. нужна "прямая видимость" в лок.сети.
Стандартная репликация - глючная и дорогая. Но неплохо работает репликация от Lanstainair входящая в Адд-Он для розницы.
Случаи потерь при репликации есть, но это случается с умеренной частотой, т.е. "жить можно".
Интерфейс:
Обычный Win-MDI. Спартански прост, довольно удобен, хотя местами примитивен:
+ Навигация по контролам стрелками в любом направлении и с комбинациями Alt и Ctrl.
+ Вычисление значений прямо в поле: 2+3 внесёт 5
+ Из поля можно прыгнуть в его источник, например из суммы получить строки, её формирующие. Это стандартное поведение для всех полей.
+ Прямо в поле можно наложить фильтр и получить список согласно фильтра. Фильтры удобные, но только в пределах этого поля. Например field1<>field2 сделать можно только в отчете.
+ Из любого грида можно скопировать в EXCEL через буфер.
+ Любой контрол и поле могут иметь мультиязычную подпись, в .т.ч. в отчётах.
+ Довольно удобный автопоиск.
- Невозможно сделать сложную форму со сложным наборами данных в каждом из контролов.
Изначально интерфейс ориентирован для показа данных из одной таблицы либо по принципу шапка-строки, но не более.
- Нет такого контрола, как дерево, хотя его неплохо заменяют гридом с отступами и жирным выделением.
- Весьма сложно отобрать записи по некоторому условию из другой таблицы. Только через временную таблицу.
- Добавить нестандартный контрол можно только через OLE.
- Внутрений репортер прост, но примитивен. Некоторые задачи делаются мучительно.
- Сортировка возможна только по существующему индексу.
- Поля с датами не содержат выпадающего календаря, хотя существует доработка: формочка а-ля календарь.
- В принципе невозможен Drug-n-Drop
- Иногда встречаются неясные внутренние ошибки (Ошибка ХХХ в модуле ХХХ), но возможно это не проблемы интерфейса.
Программирование:
Встроенный паскалеподобный язык C/AL, хотя нет многих фундаментальных паскальных команд, например BREAK/CONTINUE.
Легко освоить. Много ограничений. Многие свойства контролов не меняются программно.
Всё программирование сводится к построчной навигации по данным (NEXT, FIND, SKIP, SETFILTER), поэтому чуть-чуть напоминает ФОКС-ПРО.
В связи с тонкостями лицензирования есть проблема при создании форм, отчетов, таблиц - их надо покупать и они должны быть в интервале
предусмотренных вашей лиценцией номеров (все объекты имеют внутр. ID). Стоимость новых таблиц существенна.
Для обмена данными через ТХТ-файлы есть понятие DATAPORT. Довольно удобно, но... импорт/экспорт ....в DOS-кодировке. :)
Например украинские буквы I,i не имеют инвариантных аналогов в DOS-кодировке. Чтение файла в Вин-кодировке представляет сложность.
Замена/Дополнение программного кода делается легко и "на лету". Можно выгрузить нужные модули/формы/репорты в спец-файл и "накатить"
его на другую базу. Нельзя удалить поле, если в нём есть данные. Нет понятия NULL. Числовые поля по умолчанию 0, Текстовые ='', Дата=0.
Мощная штука - FLOWFIELD (SIFT). Виртуальное поле, данные в котором по установленным условиям вычисляются почти мгновенно по данным из другой таблицы.
Большинство вычислений в Navision сводятся к вычислению значений этих полей. Например весь товарный учёт основан именно на этом и например,
складское наличие это сумма всех операций с начала работы системы. Даже при миллионах записей механизм работает очень быстро.
Для работы такого поля необходим индекс со всеми полями, участвующим в условии. Суммировать можно только одно поле и поэтому выражение типа sum(Field1*field2) недопустимо.
Несмотря на простоту програмирования, делать изменения непросто и небыстро , т.к. структура данных перенасыщена таблицами и полями,
полное назначение которых могут не знать даже Navision-гуру. Документация помогает слабо, т.к. суть и логика данных может быть уже давно изменена "неизвестным художником от ERP".
Даже в демо-базе большое кол-во ошибок и недоделок.
Обращаться к двум и более физич.базам почти невозможно, хотя нечто подобное делает репликация, но это немного другой случай :)
Администрирование:
Основная проблема: бешенный рост размера базы. Ключевые таблицы (товарный фурнал, журнал стоимости) имеют огромное кол-во полей и индексов.
и могут составлять 60% от всего объема данных. 70% полей обычно незаполнены.
Перспективы и Вердикт (ИМХО):
К нам на праздник автоматизации Navision немного опоздал. :)
Из-за проблем с масштабируемостью его вряд ли можно рекомендовать как корпоративную платформу (хотя сейлсы рекомендуют по невежеству).
Хотя для небольших и нерастущих :) предприятий он вполне приемлим при правильном внедрении.
Для мелких фирм он безумно дорог. Найти золотую середину - крайне непросто.
Новые версии выходят редко и версия 3.7 может быть последней. Развитие Navision со стороны Microsoft начинает сокращаться в пользу более
перспективных продуктов. Поэтому выбирая систему "на вырост" следует сто раз отмерить, прежде чем один раз отрезать.