LINUX.ORG.RU

Реляционная база данных с нуля

 , , , ,


0

5

Испанец Тони Саро решил написать свою реляционную базу данных с нуля, не используя никаких сторонних библиотек. В результате получился интересный видео ролик с теорией и проект на языке Rust:

https://www.youtube.com/watch?v=5Pc18ge9ohI (видео)

https://github.com/antoniosarosi/mkdb (проект)



Последнее исправление: zg (всего исправлений: 1)
Ответ на: комментарий от PRN

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

FishHook
()
Ответ на: комментарий от FishHook

Ты ничего не понял, что тебе написали. Те кто пишет (кстати поправка) «отправлено с ифон» мне тоже ничего не «продают». И растоманы, особенно упоротые, мне тоже совсем ничего «продать» не хотят))

PRN
()
Ответ на: комментарий от FishHook

...тебя корёжит?

Из чего следует сей многозначительный вывод?

...почему тогда упоминание название языка программирования в топике про программирование - это реклама?

Там стоял знак вопроса, т.е. не утверждение.

sparkie ★★★★★
()
Ответ на: комментарий от anonymous

Как я написал выше, еще раз повторю: уши ФП торчат в Rust везде. Даже вот такие вещи: минимум мутабельности, неизменяемость в let по умолчанию, expression language вместо statement language, способ обработки ошибок Result как калька Either, RefCell как некое подобие IORef, характеристики trait как калька классов типов, generic constraints как калька ограничений по классам типов и многое, многое другое. Дальнейшее обсуждение по этому вопросу считаю бесполезным, очевидным для меня, но бесполезным для дискуссии (могу и не ответить).

и несколько видов списков, да

Лучше за современный сверх меры переусложненный ПЛ/1 поговорить. Мне тут будет интереснее почитать мнения - все же с языком C++ знакомы на порядки больше людей, и знакомы они на порядки лучше

вот кстати да, странно что он опять воспроизводит по сути простенький SQLite а не какую-то более адекватную базу данных.

SQL довольно много не нравится и вот чем — в целом, я с ним согласен по всем пунктам.

вот, например, про МУМПСы на BTree+ – любопытно было бы глянуть реализацию на Rust.

отсюда здесь на C++ когда-то была Open Mumps от Kevin O’Kane реализация, с компилятором M в С++ и хранилищем BTree как библиотекой.

с роликами на ютубчике: здесь

это не считая вполне продашенных открытых реализаций вроде GT.M, YottaDB (кажется, ещё на обычном С а не ++), простой реализации вроде FreeM того же.

самая простая реализация по-видимому была MicroMumps на CP/M под Z80, на ассемблере.

вот на PL/1, кстати, как бы даже не ещё проще получилось чем на С. например, датасеты которые в PL/1 и в КОБОЛ почему-то называют таким отдельным типом файлов вроде ISAM/VSAM.

на них в общем, древесные структуры данных как бы не проще было запилить.

и остаётся примерно такая структура СУБД:

«кеширующий сервер глобалов и рутин»

  1. хранилище глобалов в BTree+
  2. умная подкачка глобалов страницами на уровне mmap файлов
  3. умное хранение индексов вида: «несколько ключей – одно значение»
  4. умное кеширование
  5. реализация интерпретатора M, частичная компиляция там где возможно; 26 стандартных команд
  6. реализация JOBS и многозадачности через сопрограммы
  7. реализация блокировок (реализовать LOCK команду)
  8. реализация транзакций (TSTART/TCommit/TREstart/TROLLback)
  9. реализация стандартных функций
  10. реализация $zz-функций
  11. реализация структурных переменных
  12. паттерн матчинг
  13. реализация DLL библиотек
  14. демон для хранения данных 1..4, многозадачность
  15. файлы
  16. сеть
  17. импорт/экспорт глобалов, бекапы, стандартные процессы и реализация
  18. репликация, области, шардинг и т.п.

в общем, архитектурно по этому плану сам по себе MUMPS сервер СУБД выглядит как бы даже не проще реляционного SQL.

anonymous
()
Ответ на: комментарий от anonymous

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

просто берём какой-нибудь FOCAL и прикручиваем к BTree+ с более-менее умной многазадачностью, кешированием, и прочим рантаймом прямо из стандарта M.

в этом смысле, FreeM довольно прост и прозрачен.

Open MUMPS от Kevin O’Kane тоже довольно прост. там я так понимаю, в один момент он решил сильно не заморачиваться на тему пунктов 2,3 и решил тупо хранить глобалы в PostgreSQL.

неканонично с точки зрения быстродействия – зато легко в какой-нибудь скрипт интегрируется.

на эту тему он написал несколько книжек по ML и обработке и поиску, с примерами: IDF, ISR

в целом, есть ряд причин по которым реализация на PL/1, Ada, Rust была бы более адекватной для MUMPS СУБД чем на С++.

например, встроенная в язык многозадачность; кроссплатформность и переностимость в большинстве из них.

в общем: лучше бы он не SQL, а МУМПС православный на ржавом написал.

ну или на Аде или там PL/1, например.

anonymous
()
Ответ на: комментарий от anonymous

UPD: исходники MUMPS-MDH и прочего от Kevin O’Kane здесь source/MUMPS-MDH

я не знаю, возможно ли теоретически МУМПС написать на КОБОЛе, например. по идее, КОДАСИЛ же возник не просто так.

по крайней мере, в другую сторону, что YottaDB, что GT.M вызывать из КОБОЛа (или там из перла, го или руста) тоже не очень сложно.

прямо в GNU COBOL FAQ есть пример: 5.117 Can GnuCOBOL interface with MUMPS? link

comp.lang.mumps показывает битую ссылку.

из YottaDB как бы даже не проще GT.M

вообще, любопытно был бы в другую сторону.

реализовать MUMPS сервер на КОБОЛе либо PL/1, например.

а что? в нормальном PL/1 есть CALL TASK – многозадачность на корутинах.

должно быть достаточно чтобы реализовать демона и умное кеширование…

… вопрос, где же его взять, нормальный PL/1 компилятор.

pl1gcc кажется, так и застрял на недопиленной реализации.

в общем: на аде точно можно, и получится как бы даже не проще, чем на С++ (MUMPS-MDH и mumps-june-24-2024-src.tgz от Kevin O’Kane, например)

на pl1gcc – скорее всего, получится даже проще – если найти нормальный конпелятор PL1 с нормальной многозадачностью и нормальными ISAM/VSAM BTree+ датасетами файлами (файлы в PL1 это вам не linear sequential файл, это штука покруче)

на GNU COBOL – ну ХЗ. как там этого демона и многозадачность на КОБОЛе изобразить.

вообще, на КОБОЛе кроме UNSTRING какая-то обработка строк, например паттерн матчинг вообще в природе существует?

ну или какую-то обёртку к Си придётся городить, скорее всего.

а ФОКАЛ интерпретатор например брать готовый, уже на Си реализованный.

например, этот: focal-1.0.6.tar.gz со странички автора Dave Pitts

а вот с этой странички про маленький гробик ящик с Texas Instruments TI-990 можно скачать например реализацию на паскале ti990/source/focal.pas

взять например паскалевскую и на Аду оттранслировать через какой-нибудь pascal-to-ada

в общем, взять например и прикрутить к тому же GNU COBOL через C-подобный API не выглядит невозможным.

вот многозадачность в GNU COBOL придётся как-то в Си велосипедить…

чтобы демона кеширующего глобалы и рутины написать.

пока что наиболее адекватным языком всё-таки представляется Ада (а не С++)

хотя любопытно было бы увидеть реализацию на Расте, например.

anonymous
()
Ответ на: комментарий от anonymous

самые простые реализации M это: FreeM или RSM, Reference standard M.

бывший MUMPS V1 by Raymond Douglas Newman mumpsv1

впрочем, mumps-june-24-2024-src.tgz от Kevin O’Kane тоже не очень сложны.

самый production это по видимому, YottaDB как современный форк GT.M и собственно GT.M

хотя если сравнивать по размеру исходников, реализация под CP/M на Z80 MicroMumps довольно компактна.

anonymous
()
Ответ на: комментарий от anonymous

про реализацию от Kevin O’Kane: блогозапись – в блоге разработчика MiniMdb

видео по ссылке занятные. GTK+, Glade – делаем GUI и сопрягаем с MUMPS-ами.

=> накидали простое GUI приложение к базе данных.

anonymous
()
Ответ на: комментарий от anonymous

Как я написал выше, еще раз повторю: уши ФП торчат в Rust везде.

Как бы и должны торчать, первая версия же на OCaml была написана. Кроме того что ты перечислил еще и pattern matching и полноценные алгебраические типы данных, и урезанная модульная система из того же OCaml.

anonymous
()