Именно такой запрос я вбил в Гугл - "how to write a simple database program". И нашёл не так уж много информации.
В статье на Quora просто описали схему. Парсер разбирает запрос, создает дерево на основе реляционной алгебры. Далее при обработке запроса это дерево нужно будет рекурсивно обойти. Для ускорения поиска по БД нужны индексы. Для реализации индексов чаще всего используют хэш-таблицы и деревья. Существуют статические индексы, которые не меняются при добавлении/удалении/модификации данных (примеры - StaticHash и ISAM),
а также динамические, которые, соответственно, меняются при упомянутых операциях (примеры - DynamicHash и B-деревья).
В обсуждении на Stackexchange советуют учить матчасть, изучать исходный код открытых СУБД (таких как redis, flockdb и RavenDB), а также дают ссылки на книжки.
А потом оказалось, что среди разработчиков есть пословица (adage), которая звучит так "never write your own database". Именно такое название дал некто Терри Кроули своей статье. И объяснил, почему при работе над OneNote он с соратниками это правило нарушил. Терри говорит:писать СУБД - дело крайне непростое, почитайте, говорит, хотя бы статью в Вики про ESENT. Но если говорить об эффективности....
Кстати, а не почитать ли про ESENT?
Комментариев нет:
Отправить комментарий