Достали уже эти революционеры, а вот мы, а вот у нас…. Система 80-х, незаслуженно забытая, но мощная и для «реального» мира очень даже подходящая !

По пунктам :

1. С информационной точки зрения есть только две сущности: исполняемый код и данные.

Так можно много до чего договориться: с химической точки зрения есть только ~100 элементов, с физической – только электрон, нейтрон и протон. Какое всё это имеет отношение к моделям представления данных и реализациям СУБД ? Да никакого, но с «точки зрения m есть всего n сущностей», звучит научно.

2. Место хранения исполняемого кода это, наверное, библиотека программ, а место хранения данных – база данных.

Почему ? Какие достоинства ? Какие недостатки ?

3. БД как совокупность последовательных файлов рассматривать не будем.

ОК. Не будем.

4. С точки зрения ОС, БД это файл с прямым доступом к сегментам диска.

А может быть и без доступа к диску вообще (всё в памяти) или только к сети (всё на удалённом хранилище). Вообще-то с точки зрения ОС – БД это процесс или группа процессов.

5. С логической точки зрения (или с точки зрения ядра СУБД) БД это совокупность блоков со ссылками друг на друга.

Возможно. По крайней мере сейчас большинство БД хранят данные именно так – просто и удобно, производительности тоже хватает. Только БД – это не только способ хранения.

6. Есть внешнее представление данных и внутреннее.

Точнее есть данные и операции над ними.

7. Внутреннее – это то, как данные запихиваются в блоки и как из них извлекаются.

Называется – способ хранения.

8. Внешнее – это то, как данные видит пользователь: дерево, таблица, объект, или что-то еще.

Как печатается в документе, как передаётся по сети и прочее, прочее.

9. Переводом данных из внешнего представления во внутреннее и наоборот занимается ядро СУБД.

Оп - па ! А целостность, непротиворечивость, оптимизация, транзакции, блокировки это кто – пользователь ?

10. Вопросы обеспечения сохранности данных и их логической целостности не рассматриваем, т.к. если они не решены, то это не СУБД, а какая-то фигня.

Решены в проекте БД, а РЕАЛИЗОВЫВАТЬ те же уровни изоляции, например, кто будет, клиентские средства ? Не получится т.к. доступ к ядру нужен. Да и тягостно те же блокировки в клиентской части реализовывать.

11. Внутреннее представление данных у всех СУБД принципиально не отличается.

Угу. Так же как внутренне «представление» большинства ОС (везде есть процессы, файлы и прочее), однако CP\m уже в прошлом :)

12. Следовательно, различие СУБД лежит во внешнем представлении данных и предоставляемом сервисе по работе с данными:

Точно.

- доступ к данным как к деревьям с набором функций обработки деревьев (М-системы);

Иногда может быть удобно, иногда нет.

- доступ к данным как к таблицам с языком SQL (реляционные БД);

SQL != RDBMS и RDBMS != SQL, впрочем об этом уже говорили. SQL только язык.

- доступ к данным как к объектам (постреляционные БД).

Отнюдь. Про постреляционные см. ниже.

13. Термин «постреляционные» очевидно проистекает из того, что поиск объектов в постреляционных базах производится не объектыми методами, а либо через SQL, либо с помощью прямого доступа.

Постреляционные – звучит как постматематические, если у вас не реляционная модель, назовите её своим именем (иерархическая, сетевая, объектная, графовая), если у вас новая модель назовите её ещё как-нибудь.


14. Реляционные БД и SQL это логическое продолжение БД типа набора последовательных файлов и хорошо укладывается в прямоугольное представление о мире.

Опять мимо. В реляционную модель укладывается и иерархическая, и сетевая, и модель хранилища. И число измерений может быть любым. Если производительности СУБД достаточно и\или есть доп. возможности (как например аналитические запросы в Oracle) , можно эффективно оперировать иерархическими данными которые представлены в виде таблиц.

15. Ни один из вышеперечисленных способов представления данных в чистом виде не позволяет построить оптимальную информационную модель достаточно большой информационной системы.


Это почему ? Пока что мы их просто перечислили. И уже делаем вывод :)

16. Критерий оптимальности: максимальная скорость реакции при минимальных требованиях к ресурсам и максимальная информационная отдача при минимальном количестве действий пользователя + минимальные усилия по сопровождению и развитию системы.

Сначала сделали вывод – «…не позволяет построить оптимальную информационную модель…», теперь перечислили критерии оценки.

17. Прослойки типа SQL и хранимых объектов может быть и облегчают жизнь разработчику, но для достижения главной цели (оптимальности) вредны.

Следуя логике предыдущих пунктов можно сказать что всё БД вредны, да и ОС тоже вредны. Давайте писать всё на чистом ASM-e, а лучше прямо в кодах, без всяких прослоек типа ОС и БД они вредны ибо не оптимально, так ? Сдаётся мне вы остались где-то в 80-х годах вместе с М-системами …

18. М-СУБД позволяют, помимо прочего, рассматривать хранимые данные и как деревья, и как многомерные ассоциативные массивы. На базе такого представления не составляет проблем приложить некоторые усилия для создания инструментария обеспечивающего общение с данными эквивалентное SQL и работе с объектами.

«…рассматривать хранимые данные и как деревья, и как многомерные ассоциативные массивы…» - позволяют и реляционные СУБД.
Переписать свой SQL заново ? Получится лучше чем в Oracle или DB\2 ? А сколько это займёт времени, сил, денег ? Хватит ли квалификации, SQL это ведь язык так ?

19. М-СУБД больше подходит термин не СУБД, а Хранилище Данных (Data Store), позволяющее реализовывать нужные модели СУБД и их комбинации.

Хранилище данных – это всего лишь способ представления данных, не более, при желании можно построить хранилище и на файлах хранящихся в ОС.

20. Этот термин (ХД) явно используется производителями GT.M – М-системы, бесплатной под Linux.

И что ? Первый – значит лучший ?

21. Вывод: выбор GT.M для разработки серьезных информационных систем – единственно верное решение.

Вывод – вырнитесь назад к своему майнфрейму с GT.M или попробуйте почитать про аналитические запросы скажем в Oracle а заодно и про настройку производительности.