IMS

[crazy-mike]

Одна из самых первых СУБД от IBM. SQL тогда "ещё не родился"...;)
http://www-306.ibm.com/software/data/ims/

Но её идеи живут в интерфейсах dbm,ndbm и в Berkeley DB (которую съела Oracle)!!!!!!!!!!!!!!!!!!!!
Вот этим кончила sleepycat software:
http://www.oracle.com/database/berkeley-db/index.html

[смешно]

базы данных....моя слабость...:bis:

Майки, а Клиппер помнишь?

[crazy-mike]

базы данных....моя слабость...:bis:

Даже dBase2 и MUMPS помню. :grum: Но мы здесь будем говорить о настоящих мужских DBMS - а не о Female Search Query Language.

[Alex_3112]

Даже dBase2 и MUMPS помню. :grum: Но мы здесь будем говорить о настоящих мужских DBMS - а не о Female Search Query Language.

Ладно тебе, все бородатые ныне программисты начинали с FoxPro и dBase

[crazy-mike]

Ладно тебе, все бородатые ныне программисты начинали с FoxPro и dBase

Ну нет у меня бороды. Усы - есть. На System/360 никакого dBase не было. Да и наборы данных там больше похожи на dbspace чем на современные файлы. И каждый из access methods представлял собой DBMS.

[crazy-mike]

Кстати у рассматриваемых здесь СУБД есть одно интересное преимущество по сравнению с "родственниками с поддержкой SQL".
;)
Допустим - нам нужно держать очень много числовых данных в двоичной форме. Т.е. я хочу - чтобы целое число занимало четыре байта (или восемь байт) без всяких заморочек с числом значащих цифр и нужно всё это вытаскивать из "хранилища" по каким либо "двоичным критериям" (если функция - аргументом которой являются данные из БД - вернёт нужное значение то ...).
SQL запрос выполняет "преобразование данных из формы хранения в форму вывода" - если "преобразование" вообще не нужно - (когда просто выбирается начальное приближение для запуска какого-нибудь метода численного интегрирования к примеру или "поиск на графе") - то от SQL целесообразно отказаться и воспользоваться "помощью его предков" (с их родными интерфейсами)...;)

[смешно]

Что ни говори, а СУБД далеко не продвинулись за последние много лет, в сравнении с другими системами, да и вообще. Производительность говяная, слишком всё усложнили, администрация, требования к железу постоянно растут. Чего так?
Почему DB вообще до сих пор нужна OS?? И опять же эти 32 бита/64 бита. Чё за куйня? Сделайте 128 бит да подешевле, и железо и DBMS.
Такой ящичек, типо PlayStation, называться будет "128 bit DB", подключаешь куда хочешь. Так нет, бабки здесь огромные завязаны и политика гигантов...

[crazy-mike]

Что ни говори, а СУБД далеко не продвинулись за последние много лет, в сравнении с другими системами ...

;) Не совсем так. Довольно много интересных методов хеширования придумали и реализовали. С B-деревьями научились сравнительно эффективно работать...
В ранних системах 70-х годов в самом деле не было чёткого разделения на файловые системы и DMS /DBMS . "Файловые системы общего назначения" - это уже где-то в Multics,Unix и т.д. Конечно была и RT-11 и RSX-11. Но в RT-11 так называемый "файл" занимал смежные блоки на диске...Появление PC с MS-DOS в какой-то мере было "шагом назад". Хотя подфункции int 21h поддерживали очень усечённый вариант DMS. Том БД - больше было характерно для систем IBM. Тем не менее вариант "DBMS вместо файловой системы" существовал практически во всех LISP-системах и MUMPS-системах.
;) MUMPS очень интересно "эволюционировал" от работы с B-деревьями к комбинированным методам с использованием хеш-функций...

[Alex_3112]

Почему DB вообще до сих пор нужна OS??

А кто будет разруливать хардверные конфликты с 100,000 устройств от 1001 производителя?

[crazy-mike]

А кто будет разруливать хардверные конфликты с 100,000 устройств от 1001 производителя?

;) Существовала идея "машины Баз Данных" - с поддержкой аппаратной архитектуры , ориентированной на работу с СУБД. Там монитор аппаратных ресурсов должен был представлять собой что-то похожее на BIOS (или скорее на микроядро)...