DorsajПривет всем присутствующим.

Сегодня потратил целый день на выяснение, что лучше РСБУД или ОСУБД. Перелопатил кучу инфы. Приобрел кучу бесполезных знаний, но так и не понял. Мне важно понять. Имеет ли смысл уделять знакомству с Cache' много времени или нет. Не смог найти ни одного мало мальски достойного подтверждения что это лучше чем к примеру Oracle.

Во всех сравнительных анализах стоит либо прямая ссылка на intersystems. либо эта ссылка в числе прочих в списке литературы. Но позвольте, это же то же самое что спрашивать что лучше, Cache' или Oracle на oracle.com.
99% людей работающих с Cache и MUMPS расхваливают его на все лады. (Как сейчас помню, как у моего знакомого появился линукс дома, один из первых в моем городе, и как он его потом расхваливал.. уши вяли).
В многомерности не увидел ни одного преимущества, наоборот - Двумерные таблицы приучают, на мой взгляд, к дисциплинированности чем всю базу представлять единым n - мерным массивом.
Возможность обращаться напрямую к портам... Но простите, разве нельзя написать хранимку в оракле на java.
В этом самом топике прочитал что COS это язык низкого уровня как "С++ и даже глубже", долго смеялся.

Я знаю компанию, монополиста в моем и близлежащих регионах, которая перешла на оракл с Cache'

Дело вот в чем. Мне не жалко потратить время на плотное изучение ее. Но не хотелось бы тратить время на ерунду.

DorsajПривет всем присутствующим.

Сегодня потратил целый день на выяснение, что лучше РСБУД или ОСУБД. Перелопатил кучу инфы. Приобрел кучу бесполезных знаний, но так и не понял. Мне важно понять. Имеет ли смысл уделять знакомству с Cache' много времени или нет. Не смог найти ни одного мало мальски достойного подтверждения что это лучше чем к примеру Oracle.

Во всех сравнительных анализах стоит либо прямая ссылка на intersystems. либо эта ссылка в числе прочих в списке литературы. Но позвольте, это же то же самое что спрашивать что лучше, Cache' или Oracle на oracle.com.
99% людей работающих с Cache и MUMPS расхваливают его на все лады. (Как сейчас помню, как у моего знакомого появился линукс дома, один из первых в моем городе, и как он его потом расхваливал.. уши вяли).
В многомерности не увидел ни одного преимущества, наоборот - Двумерные таблицы приучают, на мой взгляд, к дисциплинированности чем всю базу представлять единым n - мерным массивом.
Возможность обращаться напрямую к портам... Но простите, разве нельзя написать хранимку в оракле на java.
В этом самом топике прочитал что COS это язык низкого уровня как "С++ и даже глубже", долго смеялся.
Я знаю компанию, монополиста в моем и близлежащих регионах, которая перешла на оракл с Cache'

Дело вот в чем. Мне не жалко потратить время на плотное изучение ее. Но не хотелось бы тратить время на ерунду.

1. Целый день - это много, конечно, но, видимо, не достаточно):
2. Видимо под ОСУБД Вы понимаете СУБД, основанные на парадигме ООП. Поскольку ООП не имеет никакого отношения к БД, то такие СУБД не могут продвинуть теорию и практику БД к новым вершинам, так сказать. Дейт, в частности, достаточно логично показазывает не достатки таких ОСУБД. Кроме того, "объектные технологии" (на основе ООП) внедрены во все существующие СУБД в той или иной степени.
3. Oracle, в частности, никогда не была "реляционной СУБД", хотя бы по той простой причине, что РМД принципиально не реализуема. И заимоствовала из mumps, все что могла, хотя это и было не понятно большигству разработчиков, так как выходило за рамки "реляционной теории" и, мягко говоря, не выглядело органично. ROWID, конечно, были объективно необходимы, причем не только для организации индексов (кстати говоря, они используются и в объектных ссылках). Появившиеся в 8i IOT типичный кусочек mumps, но как объяснить преимущества этого инородного для "реляционной технологии" кусочка - даже у Кайта не очень получается. И т.д.
4. Почитайте отчеты IBM 1968-1969гг. Кодд хотел бы обеспечить хоть какую-то семантику данных путем поддержки сущностей и связей между сущностями. Но не получилось. Победила "алгебра". И БД радикально утратили идентификацию, навигацию и семантику. А если называть вещи своими именами - БД перестали быть БД. Кодд мечтал приблизить данные к пользователю (благодаря практически естественному ЯМД), а получилось принципиально наоборот. Теперь данные находятся на "сервере БД" и доступны только для шаманов (архитекторов, программистов и прочих "разработчиков"). Чтобы просто получить фамилию сотрудника нужно идти к шаману):
5. Я, по этому поводу, 15 лет назад спросил Паскаля: а что думает об этом печальном результате сам Кодд (с которым Паскаль был знаком). Однако господин Паскаль был уже несколько раздражен, так как не смог ответить по-существу на несколько вопросов, и сказал: "Не надо преувеличивать". Ну коненчо, не надо. Ни преувеличивать, ни преуменьшать.
6. mumps единственная целостная технология баз данных, предназначенная, в первую очередь, для создания СУБД. Очень хорошо на mumps реализуется классическая объектная СУБД, так как, в частности, идентификаторы экземпляров принципиально отделены от свойств объекта (что невозможно в "Р"СУБД). Далее все органично вытекает одно из другого: связи естественным образом реализуются связями между идентификаторами, семантика данных поддерживается естественным образом именно благодаря тотальной идентификации метаданных.
7. В результате, можно (и это уже давно сделано на практике) создать систему, позволяющую радикально сократить программирование (в частности, вообще отказаться от программирования интерфейсов), прекратить шаманство и приблизить данные к пользователям.
8. О какой многомерности Вы говорите вообще непонятно. mumps не является "многомерной" системой в смысле MS AS, например. Но на mumps прекрасно работает OLTP+OLAP в рамках одной системы.
9. "Таблицы" в ОСУБД на mumps тоже есть, как внешнее представление объекта, причем, в отличие от Oracle или MS SQL на количество "колонок" в таблице нет ограничений (так же как и на "длину записи").
10. Наверное, Вам следует продолжать "долго смеяться". Здоровее будете):
11. Мой Вам совет: не тратьте время на изучение mumps. Сейчас не те времена. Продолжайте шаманить, так как это хороший, в коммерческом отношении, путь):