OberonCore

(модератор) Похожая тема: Сложно ли написать свою СУБД?

Существует ли учебная СУБД?

Вот компилятор есть учебный - Oberon
Операционная система есть - Minix

А СУБД нету. Нехорошо...

Возможно Berkeley DB подошла бы... но слишком серьезная она. Да к тому же NonSql и написана на Си

Неплохо было бы иметь простую клиент-серверную СУБД в BlackBox

Внимание вопрос! Что она должна из себя представлять?

Я думаю что это должны быть таблицы типа DBF. (возможно внутри контейнера вроде OLE Structured Storage)
Типы полей обероновские + Blob.
Array поля только фиксированной длины.
Соответственно первичные и внешние ключи.
B-tree индексы и эффективный IO(блочное асинхронное чтение/запись и т.д.)
Простой компилятор и оптимизатор урезанного SQL
View (в терминах SQL)
Курсоры

p.s. Прошу дополнить(урезать)

А какая у Вас цель обучения?

Если типа "изучать SQL", то что мешает это делать на полноценной реализации? Или Вы хотите сделать курс по реализации СУБД?

Ах да забыл требования ACID еще включить.

Цель - создание учебной СУБД, на примере которой, студент мог бы изучать внутренности СУБД

Это в логике Системы Оберон. Думаю, очень правильная идея.

Думаю, что такой СУБД нет, но было бы хорошо ее создать, еще лучше написать ее на языке Оберон.

Мне кажется, что полезнее было бы разработать библиотеку компонентов для доступа к популярным СУБД. Вряд ли кому-то из студентов придется участвовать в разработке СУБД, а вот научиться использовать СУБД - это достойная цель. Да и для Оберона было бы полезно преодолеть изоляцию.

Есть (был) проект института системного программирования GNU SQL Server http://panda.ispras.ru/~gsql/.
Есть Третий манифест Дейта и Дарвена http://www.thethirdmanifesto.com/. Там есть ссылки на реализации.
В забугорной университетской среде может чего поискать

Всё верно, но досадно. Конечно надо учиться применять готовое, но когда же и где у нас будут готовить тех, кто сможет создавать новое.

Дело даже не в этом. Хорошее понимание того, как оно устроено, сильно помогает.

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

Компилятор Оберона - это полнофункциональный законченный продукт. Чтобы создать столь же полнофункциональную и законченную СУБД сил Оберон-сообщества явно недостаточно. Значит, это будет весьма куцый макет, на котором можно будет изучить только самые азы.

Нужно взять книжку "СУБД своими руками" и сбацать этот проект на ББ+КП

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

Азы и нужны.
Как показывает практика многие регулярно работающие с СУБД слабо представляют как оно устроено.

Должна быть маленькая (менее 20k строк кода, хорошо комментированных) СУБД, реализованная на внятном языке. Обозримая, так сказать...

Чудес от нее не требуется. Но она должна позволять "потрогать" то, что описано в "Алгоритмах" Вирта, в реальной системе.

А так же показать как "магический" SQL превращается в императивные конструкции

Какую изоляцию?

OLEDB, ODBC, DAO, ADO...
все доступно

И вот еще странная штука. Почему в сознании масс с базами данных так прочно ассоциируется SQL.
SQL довольно специфичная математическая абстракция. Есть вещи, которые довольно сложно (невозможно) сделать с SQL

Вот как раз насчёт сознания масс, по-моему, удивляться совершенно нечему

SQLite тоже есть. Btrieve/PervasiveSQL тоже.
Я тоже не понимаю, о какой изоляции речь.

К сожалению весьма распространённое у нас мнение. Может от того и не стало ни Имён ни Школ ни в области языков ни в СУБД и т.д и т.п.

Важен сам процесс "самописния", а также его нематериальные результаты. Впрочем, я не берусь Вас в чём-либо переубедить.

Изобретение велосипеда может быть как полезным, так и бесполезным (но не обязательно вредным). Всё зависит от того, какие цели ставит перед собой "изобретатель".