Umorist,

Я бы не стал ни в коем случае проводить сравнение различных СУБД с Cache (именно я, из-за недостатка понимания сравниваемых объектов ).

Главная причина, на мой взгляд - Cache нужно сравнивать с тем продуктом, который одновременно является и сервером БД, и сервером приложений, и сервером представлений.

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

Тут постоянно пытаются сравнивать малую часть функционала Cache с полным функционалом других СУБД.

Вы же не станете сравнивать одного футболиста Пеле с целой командой Европейской сборной, каким бы талантливым не был Пеле.

А теперь по Вашей заметке (тут я буду говорить только о том о чем знаю и понимаю).

I – Плюсы для конечного пользователя действительно есть: простота в обслуживании, низкие требования к аппаратуре, легко разворачивать новую систему для нового заказчика, низкие требования к персоналу сопровождения, чаще всего пользователь получает именно то что он хочет, пусть даже путем поэтапного развития проекта.
Есть, конечно же, и минусы. Мне кажется, что основной минус – это нетрадиционный подход к решению задач, необычный образ мышления при реализации задач.

Совершенно ничего не понимаю «при анализе котировок акций», но понимаю, что для АСУТП подобные инструментальные средства необходимы. Причем не важно, Cache это или нет, лишь бы продукт обладал такими же возможностями. Лично меня сильно удивляет тот момент, что при анализе технологий в первую очередь рассматривается только одна прикладная область – счета, проводки, отчеты, одним словом бухгалтерия (образно). Наверное это потому, что в свое время только тут можно было разработчикам заработать деньги.

II - Скорость обычной выборки, наверное в Оракле будет даже выше, он специально для этого предназначен. А как быть с необычными выборками, ну если прикладная задача требует этого и без этого ну никак нельзя? А если еще и данные невозможно разложить в строгие структуры хранения, такие структуры постоянно меняются, причем вид структуры хранения будет определяться входящим потоком данных. А потом эти, заранее не известные, хранимые структуры нужно разобрать при очередной выборке, на ходу, а по вынутым данным произвести расчеты и снова уложить данные в еще никому не известные структуры.

III – Опять же ничего не знаю про котировки. Знаю только то, что существует множество прикладных задач, которые годами не решаются из-за ущербности широко используемых инструментальных средств, или из-за большой дороговизны их объединения для комплексного решения. Новое время выдвигает новые задачи, новые задачи выдвигают новые требования, а новые требования ждут новых технологий (иногда новое, это забытое старое).Вины программистов в этом нет, все они хорошие люди.


А вот и Ваши вопросы:

1. Тут Вам консультанты из ИнтерСистемс скажут больше, за рубежом может и есть подобные решения.
2. Я не знаю как там на рынке, но при решении задач производственного характера, ситуация именно такая. Не скажу, что Cache обладает супер способом организации хранимых данных, но приведу примитивный пример ( в нем есть ряд неточностей синтаксиса) .
Write ^Arhiv(Европа, Украина, озера, Сиваш, 2008, Май, содержание солей)- ^Arhiv(Европа, Украина, озера, Сиваш, 1963, Август, содержание солей)

В этом выражении одновременно осуществляется выборка, расчет и представление результата который показывает динамику изменения засоленности в абсолютных величинах. Такое выражение исполняется практически мгновенно.

Неправильно будет считать, что все расчеты (именно расчеты) в Cache будут выполняться быстрее, чем в других языках. Но вот сочетание выборки данных, расчетов и представление результата можно уже с чем-либо сравнивать.

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

Быть может работать с В-деревьями в Оракле не оптимально, по причине того, что для Оракла это некая надстройка (не родное) а вот в Cache это родное и самое быстродействующее. Так же как в Cache работа с данными, представленными в реляционной модели, не будет самой быстродействующей, хотя разработчики Cache постоянно совершенствуют этот механизм, дополняя его все новыми и новыми технологическими решениями. Опять же, новые технологические решения основываются на древовидную схему хранения данных, новые возможности постоянно развиваемого базового языка программирования.

3. Вот точно также, как нельзя прямолинейно сравнивать продукт 1С с различными СУБД, также нельзя сравнивать прямолинейно Cache с другими СУБД. Нельзя прямолинейно сравнивать красивую мордашку Мисс Европа с каменным лицом боксера тяжеловеса. Хотя и тот и тот - человек.

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


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

6. Применение Cache уже сейчас дает преимущества там, где именно данные управляют всем ходом событий, именно там будущее и развитие технологий ИнтерСистемс, Cache, Ensemble, Deep See, и два других чисто медицинских продукта про которые я ничего не могу сказать. Могу только сказать что все они построены на ядре Cache. Проходит то время, когда рассуждали так, мы вам тут все собрали в наших СУБД а вы теперь сами разгребайте, кому как надо.