1. Идти надо, обязательно. В единственной на сегодня "зелёной книге" многих тонкостей нет, к тому же эта книга по четвёртой версии Cache'. Ответ на многие вопросы пока можно получить только у менеджеров IS, к сожалению. Однако минута живого общения стоит подчас многочасового чтения хелпов, книг и т.п.
Обучают очень качественно, я не пожалел. Затем (после курсов) еще и нянчатся с тобой, терпеливо отвечают на всякие глупые (и умные) вопросы etc. Персонал IS (московского пред-ва) заслуживает самых лучших слов.

У них есть (для зарегистрир. юзеров) "всемирный центр поддержки" (WRC), который весьма оперативно реагирует на твои вопросы (если они обозначены тобой как "критические" -- в течение 24 часов, кажется; обычные -- в течение 2-3 дней).

Форум у них тоже есть, но на Yahoo и он отвратительный (с принудительной рекламой и "непредсказуемо плавающей" кодировкой). Почему они не переедут все сюда -- не знаю.

2. Cache' не распространена просто потому, что у IS совершенно неправильная (неагрессивная) маркетинговая политика. Но поддержка тех, кто купил хотя бы 5 лицензий (минимум для юридич. лиц) -- образцовая.
Эта СУБД действительно "скорострельная", т.к. при обработке SQL-запросов с использованием JOIN'ов для связки нескольких таблиц (а таких запросов - подавляющее большинство) в Cache' вместо поиска в индексе используются прямые ссылки (адреса) на строки, т.е. что-то типа "смещений" от начала каждой из таких таблиц. А операция fseek() всегда будет быстрее поиска в индексе (B-дереве).

3. По поводу "крутости", быстродействие и т.п. Мы делали запрос в таблице в 5 млн строк (прайс-лист со стоимостями, указанными в разных валютах), связанной с маленьким справочником наименований этих валют (5 строк). Этот запрос проводился в Cache' и в Oracle. Машина была одна и та же (OS: Windows 2000), оба теста проводились сразу после (пере-)загрузки компа. Так вот: если вытряхивать данные из Oracle, то запрос _БЕЗ_ JOIN'a он выигрывает (примерно на 20%). Запрос с JOIN'ом сразу же уравнивает Cache' и Oracle.
Есть, однако, и "слабое звено": Cache' _НЕ_ поддерживает транзакции с уровнем изолированности SNAPSHOT, т.е. когда у тебя начинается "долгий отчет", то его на итоги могут повлиять данные, изменённые в БД уже после того, как этот отчёт стартовал (что не есть good!). Уровень изолированности READ COMMITTED поддерживается (грязных данных не видно).

4. Куда приткнуть знания -- вот пример, выдержка из рассылки InterSystems (29-04-2005):
begin quote
========
Работа в Москве
Московская компания - одна из ведущих и самых крупных в России поставщиков автомобильных запчастей импортного производства приглашает на постоянную работу с полной занятостью ведущего менеджера проекта - специалиста по созданию программных продуктов на основе СУБД Cache' и Web-технологий - для участия в разработке новой торговой системы и ее последующей эксплуатации и развития.

Обязательны: хорошее знание Cache', COS, CSP, HTML, Javascript, знакомство с Apache, а также опыт работы в группе программистов над созданием продукта на СУБД Cache' или хотя бы опыт самостоятельной разработки программного продукта.

Желательны: знакомство с Linux/Unix, стремление к самореализации и карьерному росту, творческий подход, самостоятельность, ответственность, организованность.

Зарплата - от $ 2000, премии, возможности кредитования. Перспективы карьерного роста. Индивидуальные условия в зависимости от результатов работы.

Место работы - район метро "Свиблово".

Готовы рассмотреть предложения от команд программистов, имеющих опыт разработки продуктов на СУБД Cache'.

Контакт - телефон: 783-60-90, кодовые слова - "по поводу приема на работу программиста"
===
end of quote

Честно сказать, такие вакансии пока не часто появляются. Но я видел и раньше приглашения на работу по профилю Cache' (причём, не искал специально, они мне сами попадались на глаза).

Хе-хе! На http://www.dimas.ru/ic/irw191.htm рассылочка-то старенькая, за 29-12-2004 (я же привёл за 29-04-2005). Ставки растут, однако, теперь уже два "косаря" предлагают...
Только жаль, куда-то "возможна неполная занятость" исчезла... ;)