2lsi
Со многим согласен, хотя там не всё так уж хорошо. Некоторые цифры выдирать вовсе непросто.
Если есть несколько компаний(отдельные базы), то возможно появление разноименных таблиц одного назначения (немного коряво звучит). Производительность на MSSQL только в начале работы хорошая.
База растёт очень быстро. Нативный сервер очень производительный, но примитивен и "сам в себе". Внешний репортинг в нём не построишь.
Встроенный репортинг весьма примитивен, хотя для большинства задач хватает.
Для крупного предприятия с большим оборотом(напр. торговля) системка может не потянуть.

IgorK LSVБаза растёт очень быстро Это как это? База растет ровно на столько, на сколько быстро вносятся данные, ничего другого там не хранится. Видели реализацию FlowField полей на MSSQL ? Каждое такое поле - отдельная таблица. Сколько таких полей, столько таблиц. Видели кол-во полей в важных таблицах ? А вы посмотрите.....
Особенно т.32 и т.5802.
А кол-во индексов и кол-во полей в них !....
В этих таблицах могут лежать миллионы записей.
Более половины полей пустые или заполнены одним значением.

Косвенный показатель оптимальности - упаковка бекапа РАРом. Вместо обычных ~7крат. навиженская база пакуется в 10-13раз. Почему ? Потому что хранит пустоту .

Модератор: отредактировано

Думаешь 1С, OBES или SAP не хранит пустые поля?В любой системе есть пустые или продублированные поля. Это нормально. Не нормально, когда пустота и дубляж занимают 80% базы.
В прочем по мнению многих внедренцев и это нормально
Не совсем нормально, когда всего после года работы база занимает 60Гб и бекапится 4-6часов.
Нативная СУБД (Navision). Для MSSQL эти цифры надо умножить на 1,5.
На нативной базе бекап может работать нестабильно уже на 100Гб в чём я не раз убедился. Урезать данные было нельзя, т.к. информация за прошедший год нужна целиком.
На это был дан "мудрый совет" поставить отдельный сервер (10к$) и разворачивать на нём прошлый период, а в оперативной базе урезать....
Конечно в этом виноват не только Navision. Есть ещё человеческий фактор
А ведь рассмотрен только один (не самый критичный) аспект - размер базы.

у меня база 80Г бэкапится 20 минутВ Navision-Server ? Горячий бекап (обязательное требование) ?
80Г/20минут ????? да не смешите !.... На MSSQL поверю.
Правда райд-массив у нас был медленный: РАЙД-5. Но другого не было. :(
Ну и "консерватория" конечно тоже присутствовала...

IgorKна MSSQL конечно. А вот чисто теоретически - какая выгода от использования нативной базы?Более высокая производительность. При этом отличная устойчивость.
И кривыми ручками никто не залезет.

Из серьёзных минусов можно назвать поломку индексов (для полей типа code), при которой база работает нормально, но перестаёт делаться бекап. Лечится только созданием нового поля, переливкой значения ключа, перенос ключа в новое поле и т. д. для каждой поломанной таблицы.
Причём через пару дней проблема возникает вновь. Особенно на любимой до слёз табл.32
Появляется на больших объемах(~90Гб) и нагрузках. Это делает эксплуатацию практически невозможной, т.к. бекап удаётся сделать только вскоре после вышеописанного "ремонта" который может длиться много часов в практически монопольном режиме.
На MSSQL-опции эта проблема также присутствует, но лечится гораздо проще.
Всё это наблюдалось в Навижн 3.6