Комментарии 9
Во-первых, то что вы собираетесь создать, называется СУБД. СУБД, а не база данных. И это две разные вещи. Если бы вы собирались создать базу данных, вы бы взяли готовую СУБД, и написали бы описание своей базы и ее таблиц на языке SQL (если быть чуть точнее, DDL). И выполнили бы.
Во-вторых, чтобы научиться понимать, как это работает, полезно научиться абстрагироваться от мелких неважных деталей. Потому что начиная описывать с чтения команд с консоли, вы дойдете до конца к 50 статье. Если вообще дойдете.
Кроме всего прочего, чтение SQL откуда-то - это обычно так называемый клиент, или клиентская часть, а типичная СУБД этим вообще не занимается. Поэтому для понимания принципов это не особо-то и нужно. Было бы намного логичнее начать с чего-то типа слоя хранения, т.е. Б-деревьев, ну или парсера SQL (причем напрашивается просто взять готовый), ну или с той части, которая строит план запроса.
Во всем согласен кроме готового парсера
Просто как по мне интерес в написании таких проектов это именно все самому, чтобы понять как работает. А то по такому принципу можно взять готовый парсер, готовое управление данными, и написать 2 строки для коннекта. Или ваще взять постгрес и не писать ничего)
Я совершенно не против того, чтобы написать парсер SQL самому. Просто как по мне, это многовато для одного проекта, вместе с остальным.
Хотя конечно каждый сам оценивает свои способности и возможности.
Просто как по мне интерес в написании таких проектов это именно все самому, чтобы понять как работает.
Если писать свой парсер, то можно понять как работают парсеры. Это безусловно полезное знание, но к СУБД отношения не имеет. Вот тут bnf грамматики для старых версий sql, можете оценить объем работы.
А по мне так норм, начинать с консоли. Это сразу и тесты на минималках, при этом с возможностью проверять любые тесткейзы. И мотивирует сильнее, тк сразу видно, как система функциональностью обрастает. Например акронис труимадж если не начался (я этого не застал), то развивался через такую консольную тулзу и это очень удобно. Сам всегда начинаю именно с тулзы. Юнит тесты уже потом. А интеграционные уже можно и на ней писать.
Ну как бы вы вольны начинать с чего угодно. Я говорил о том, что у нормальной взрослой СУБД консоли как таковой обычно вообще нет, у нее интерфейс наружу - это как правило сокет, куда подключается тот или иной клиент, который уже может быть и читает с консоли. И начиная разработку с консоли, вы вот эту вот часть архитектуры просто опускаете, если не теряете. И вместо клиент-серверной архитектуры СУБД получается некая однопользовательская штука, умеющая выполнять запросы. А в данном конкретном случае вообще получился REPL, который не умеет пока ничего. Если уж задумывать REPL, то было бы желательно сделать автокомплит для SQL, например. А в текущей реализации вообще нет никаких признаков автокомплита. Более того, написанный уже код будет мешать его реализовать.
В статье упоминается путь в 1000 верст. Я посчитал, это 1 385 454 шага, видимо столько будет статей еще.
del
Заголовок - создаем свою СУБД.
Содержание - читаем строку из консоли.
Создаем свой аналог sqlite c нуля. Часть #1