История изменений

Если всё это делать надо эффективно, по сути тебе просто придётся изобрести что-то вроде своей уникальной СУБД. Так не проще ли взять готовую тогда?

Я могу, конечно, ошибаться, но я предполагаю, что Столярову интересно переизобретать велосипеды. В его проектах можно встретить те же реализации связного списка там и сям, хотя казалось бы - на C++ это уж можно реализовать один раз и переиспользовать.

Если рассматривать в этом контексте, то всё становится понятно. Очевидно, что любую СУБД можно реализовать в своём проекте. Частично, конечно. Причём в этом есть смысл, т.к. когда тебе от СУБД нужно конкретное подмножество функций, когда ты знаешь железо, на котором работает твоя СУБД, вполне может случиться, что ты реализуешь всё эффективней, чем это делает универсальный продукт.

К примеру СУБД проводит лексический анализ SQL запроса, строит план выполнения, использует накопленную статистику, выбирает индексы, которые разумно с её точки зрения использовать. Но если ты всё пишешь сам, тебе не нужен никакой SQL. Может быть у тебя ткаой простой запрос, что ты просто сам в индексе вытащишь смещение, и по смещению вытащишь данные. Тебе не нужно парсить SQL. Тебе не нужно строить план выполнения запроса, он у тебя уже в коде. Тебе не нужно обеспечивать мультиверсионность или блокировки, у тебя, например, смартфон с одним пользователем по определению.

Если всё это делать надо эффективно, по сути тебе просто придётся изобрести что-то вроде своей уникальной СУБД. Так не проще ли взять готовую тогда?

Я могу, конечно, ошибаться, но я предполагаю, что Столярову интересно переизобретать велосипеды. В его проектах можно встретить те же реализации связного списка там и сям, хотя казалось бы - на C++ это уж можно реализовать и переиспользовать.

Если рассматривать в этом контексте, то всё становится понятно. Очевидно, что любую СУБД можно реализовать в своём проекте. Частично, конечно. Причём в этом есть смысл, т.к. когда тебе от СУБД нужно конкретное подмножество функций, когда ты знаешь железо, на котором работает твоя СУБД, вполне может случиться, что ты реализуешь всё эффективней, чем это делает универсальный продукт.

К примеру СУБД проводит лексический анализ SQL запроса, строит план выполнения, использует накопленную статистику, выбирает индексы, которые разумно с её точки зрения использовать. Но если ты всё пишешь сам, тебе не нужен никакой SQL. Может быть у тебя ткаой простой запрос, что ты просто сам в индексе вытащишь смещение, и по смещению вытащишь данные. Тебе не нужно парсить SQL. Тебе не нужно строить план выполнения запроса, он у тебя уже в коде. Тебе не нужно обеспечивать мультиверсионность или блокировки, у тебя, например, смартфон с одним пользователем по определению.

Если всё это делать надо эффективно, по сути тебе просто придётся изобрести что-то вроде своей уникальной СУБД. Так не проще ли взять готовую тогда?

Я могу, конечно, ошибаться, но я предполагаю, что Столярову интересно переизобретать велосипеды. В его проектах можно встретить те же реализации связного списка, хотя казалось бы - на C++ это уж можно реализовать и переиспользовать.

Если рассматривать в этом контексте, то всё становится понятно. Очевидно, что любую СУБД можно реализовать в своём проекте. Частично, конечно. Причём в этом есть смысл, т.к. когда тебе от СУБД нужно конкретное подмножество функций, когда ты знаешь железо, на котором работает твоя СУБД, вполне может случиться, что ты реализуешь всё эффективней, чем это делает универсальный продукт.

К примеру СУБД проводит лексический анализ SQL запроса, строит план выполнения, использует накопленную статистику, выбирает индексы, которые разумно с её точки зрения использовать. Но если ты всё пишешь сам, тебе не нужен никакой SQL. Может быть у тебя ткаой простой запрос, что ты просто сам в индексе вытащишь смещение, и по смещению вытащишь данные. Тебе не нужно парсить SQL. Тебе не нужно строить план выполнения запроса, он у тебя уже в коде. Тебе не нужно обеспечивать мультиверсионность или блокировки, у тебя, например, смартфон с одним пользователем по определению.