Тут как-то сформулировал для себя, почему я больше никогда по своей воле не буду иметь дело с продукцией Интерсистемс и производными от нее:

1. Нетехническая часть

1.1. Лицензионное соглашение и Договор на поставку Иск
требует, чтрбы Ла (License Agreement) регулировалось штатом
Массачусетс (США). Это не всегда просто объяснить российским
заказчикам. Конкуренты допускают такое для Ла, но не для
Договора!

1.2. Практикой Иск является то, что стоимость лицензий
регулярно (ежегодно) повышается. В среднем повышение
для России составляет 10% в год. В результате, похоже, Каше
стала самой дорогой Субд. В частности, Каше существено дороже
Оракл для сравнимой конфигурации.

1.3. Ежегодное повышение стоимости лицензий влияет и на
стоимость сопровождения, так как стоимость сопровожденя
привязана к текущей стоимости лицензий. И если на покупку
новых лицензий можно получить скидку, то на сопровождение
скидок не дается.

1.4. Иск стоит пересмотреть свою лицензионную политику в
части уменьшения числа лицензий - если я стал использовать
меньше лицензий, то платить за поддержку и обновление должен
за все ранее купленные.

1.5. При увеличении числа пользователей (при достижении
некоторых пороговых значений) стоимость каждой лицензии
(каждого пользователя) возрастает! Бред! Иск объясняет это
повышением функционала, но реезультатом является то, что
бюджет на Субд тяжело заплвнировать точно.

1.6. У Иск есть приятная возможность - аренда лицензий.
Единственный минус - стоимость аренды каждый год
увеличивается, так как рассчитывается от стоимости лицензии.
Исходя из повышения на 10% в год стоимость аренды удвоится
через 10 лет.

1.7. Vision у компании меняется каждый год. Это странно.

2. Безопасность

2.1. Разделение ролей между DBA и DBSO (офицера по
безопасности) в Каше принципиально невозможно - у роли %All
всегда должен быть хотя бы один пользователь, то есть
суперадминистратор, который может абсолютно все. В других
промышленных СУБД разделение возможно. DBA может все,
кроме настройки контроля за действиями пользователей, в том
числе себя. Такой контроль есть только у офицера
безопасности. Выделение роли офицера безопасности оставляет
контроль за суперадминистратором - он может все, кроме того,
что потереть информацию о своих действиях и быть пойманным. В
Каше такое невозможно - суперадмин может все, в том числе замести следы.

2.2. При использовании прямого доступа можно случайно разрушить структуры данных для объектов или таблиц. Никакой защиты нет. Нужна возможность запретить прямой доступ для админов, но такой возможности нет.


3. Сопровождение

3.1. Период сопровождения версий у Иск -1 год. Это очень мало
и неприемлемо для промышленных Субд, которые эксплуатируются
по несколько лет. Понятно, что таким образом Иск подталкивает
пользователей на использование более новых версий и снижает
свои накладные расходы. Но следствием, например, является то,
что сертифицированная по К1 152ФЗ версия Ensemble не
поддерживается.

3.2. У Иск крайне ограничен набор вспомогательных утилит для администратора. Наприме, перенести БД - проэкспортировать схему БД и ее содержимое в смысле SQL невозможно. Иск рекомендует копировать cache.dat. Этот путь опасен, так как может быть нарушена целостность данных. Кроме того он не сработает при различии в кодировках в базах или при различии в использовании Unicode или для платформ с разным порядком байт.

4. Техническое

4.1. Ensemble workflow несовместима ни с чем, модель нельзя не передать, ни импортировать. Более того, модель нельзя распечатать (printscreen не в счет).

4.2. Производительность Каше является вещью в себе. Возможности по тонкой настройке отсутствуют. Впрочем, существуют специалисты, знающие некоторые недокументированные возможности. Но использование таких возможностей чревато, более того, настройки обычно слетают при обновлении версии.

4.3. Быстродействие Каше является мифом. Каше можкт показать сравнительно высокую производительность только на компьютерах с небольшим ОЗУ. Модель данных Каше рассчитана именно на такие компьютеры - она не менялась последние 40 лет. При добавлении памяти Каше начинает проигрывать MS SQL Server даже на маленьких транзакциях. Агрегатные функции и сложные запросы Каше не умеет оптимизировать вообще - простой перебор таблицы. Каше не умеет распараллеливать запросы, для пользовательских сессий создаются не нити, а процессы, по одному на каждую сессию.

4.4. В прямом доступе транзакции в Каше не поддерживаются - существующие команды TStart и TCommit исходят из предподожения, что есть только один пользователь. Многопользовательский доступ никак в транзакциях не учитывается. Блокировки и конкурентный доступ нужно делать на уровне приложения. Ошибка в реализации или неверное действие админа в терминале приводят к неконсистентности данных. База может просто посыпаться. Найти такую ошибку очень трудно.

4.5. В SQL у Каше реализовано всего 2 уровня изоляции - dirty read и read committed. Причем read committed реализован частично - он не распространяется на доступ к индексам. Поэтому даже при правильно написанном приложении возможно самопроизвольное рассыпание базы и эффект мерцающих ошибок. Такое ощущение, что Иск не подумал о том, что с системой может работать более одного пользрвателя.

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

4.7. Версия СУБД Каше должна быть не ниже версии клиентских программ. Это неудобно - обновляя СУБД на сервере надо обновлять и всех клиентов. У конкурентов обычно наоборот.

4.8. Очень слабое документирование. Ннапример $zu. Некоторые гуру знают и используют недокументированные фичи. Для промсистем так делать нльзя. В Каше без этого нельзя.

4.9. При работе с SQL если захочется добавить новый индекс (это обычная практика по настройке производительности), то надо перекомпилировать все связаннык классы, по факту обычно надо перекомпилировать весь проет - чтобы быть уверенным, что база не развалится. Перекомпиляция реальных бд может занимать дни.

Что именно не верно? Какой пункт? Конкретику, пжл.

Проект, где перекомпиляция шла днями (проект, умерший, в том числе и по этой причине) - ПФ РФ

Про проблемы с индексами - это только у Каше. Это было документировано, это была "фича". То есть, уровень есть, а использовать нельзя. Фишка только в Каше.

Про Ирис - не скажу. А в Каше накатка версии требовала перекомпиляции базы. Отсюда и полтора суток на обновление базы в МО. Исправили? Хорошо.

Про неумение готовить код - ну да, все просто. Отказываемся от встроенного SQL)))). Или "разогреваем" после обновления. Ручками) или умением программировать)). Почему у Оракла и прочих для этого ничего выдающегося на уровне *софта* делать не надо? В крайнем случае, админ запустит обноаление статистики. В фоне.

А еще база растет и статистика меняется. "Разогревать" каждый раз?

Конечно, все преодолимо. Вопрос цены, надежности, времени, удобства.

Обновление приложения в Каше - это обновление классов. Перекомпиляция класса в Каше тянула за собой и пересборку связанных с классом таблиц и индексов. Даже если хранение не затрагивалось, а речь шла о каком-то расчетном методе. Если говорить о прямом доступе, то такой проблемы, конечно, не возникало. Так что именно в Каше при использовании объектов не удавалось отделить логику приложения от логики хранения.

Обновление статистики можно делать, но оно не повлияет на ту логику, которая была использована на момент компиляции встроенного SQL. Если компилятор на момент компиляции метода со встроенным SQL решал, что запрос реализуется через прямой перебор записей таблицы, то эта логика оставалась той же и при увеличениии объемов таблицы в тысячи раз. Здесь надо было перекомпилировать класс на реальной базе, чтобы учесть новую статистику - возвращаемся к проблеме долгой перекомпиляции классов.

Это не бред. Оно так работало. Почему оно так работало - вопрос к Иск. Когда а ПФ РФ аозникли проблемы с этим, на ушах стяла вся Иск. Какой-то апдейт для частичного устранения проблемы выпкстили. Помогло мало. Глобпльно (хорошее слово)) ничего сделать не смогли. Проект закрыли.

Вы, вероятно, из Летографа, и таких подробностей не знаете. Кстати, как поживает Летограф как продукт (про фирму не спрашиваю, знаю)?

PS Кстати, а хорошо ли Летограф переваривал большие объемы данных и число пользователей более 5? )))

PPS Каше хорошо работало только тогда, когда становилось М-ом.

PPPS Я правильно понял, что из 20 пунктов "почему не Каше" сомнение вызвал только 1? )))