Как стать автором
Обновить

Комментарии 12

Видел отечественный движок БД очень похожий на SQLite.
Он был сделан в почтовом ящике в конце 80-х.
Портирован на С на ПК в начале 90-х.
Язык команд подобен SQL.
Только команды русские:
ДТЬ — select
ИЗМ — update
ИСК — delete
ФКС — commit
и т.п.
И в нем была фишка автосоздания постоянных индексов для оптимизации запросов.
Как и в SQLite блокировка БД на изменение.
Транзакционность была на уровне буфера измененных страниц в памяти.
Эту БД решили делать, когда прочитали в конце 70-х в американском журнале статью IBM с описанием языка SQL.

Хипп, по сути, один из лучших программистов в мире в настоящем. Странно, что он не так популярен как некоторые другие. Но качество его кода просто запредельное.

Интересно, что мешает большему количеству разработчиков быть такими же? И большему количеству компаний спонсировать подобную разработку? Вот SQLite по сути закрывает проблему "надёжно и гарантировано сохранить данные", это идеальный универсальный файловый формат (делаешь своё приложение — просто пиши в базу, не надо придумывать свои "транзакции" для надежности, кастомный формат и т.д. лучше чем просто хранить в базу sqlite не будет, ни по надёжности, ни по скорости, ни по занимаемому месту), это движок БД с весьма широким диапазоном возможностей (по сути, закрывает все кейсы на одном компьютере/с одним пользователем) и его разработка стоит не так уж и дорого — один человек на протяжении многих лет. Но даже с таким примером большинство разработчиков продолжают писать мучительно раздутое нечто, оправдывая это стоимостью разработки, легкостью поддержки, требованиями бизнеса, чем угодно, кроме того, что им просто в голову не приходило, что можно по-другому. Будьте больше как Хипп, пишите больше софта как sqlite и мир станет более приятным местом для жизни.

Эскулайт пишет не один Ричард, посмотрите на сайте эскулайт раздел SQLite Developers. То есть Ричард сам пишет отличный код, делает отличные тесты, договаривается с коммерческими клиентами, обеспечивает поддержку всем пользователям, оперативно исправляет выявленные баги, собрал отличную команду, написал свою систему контроля версий,… А еще ему не мешают работать эффективные менеджеры :) В общем, чтобы в крупной компании такой человек-оркестр работал и ему не мешали — случается чрезвычайно редко.


закрывает все кейсы на одном компьютере/с одним пользователем

На самом деле, если задача позволяет все модификации базы выполнить в одном потоке, то эскулайт отлично работает на серверах, обслуживая уйму пользователей. Скажем, система навигации получает поток данных с миллиона машин, предобработанные данные пакетно пишет в эскулайт один раз в несколько секунд и всем водителям машин отображает текущую дорожную ситуацию — получаем все преимущества со сверхбыстрой выборкой данных, а еще можем легко ротировать минутные, часовые и суточные базы, которых эскулайт позволяет в одном соединении открыть и совместно использовать до 125 штук, см. https://www.sqlite.org/limits.html. Понятно, что множественные длинные пишущие транзакции в эту схему не укладываются, но вот в указанной задаче и многих других они просто не нужны.

Эскулайт пишет не один Ричард

Ух ты, целых трое. Это конечно инвалидирует мой поинт :) Ладно крупные корпорации — понятно, что они всему виной, в них менеджеры и т.д. Но личные пет-проекты и опенсорс? Там кто, кроме девелоперов отвественен? Мало кто говорит "я сосредоточусь на том, чтобы моя программа была железобетонно-надёжна, быстра и работала везде". Вместо этого чаще услышишь "у меня всё работает, а винда вообще не поддерживается, потому что мне пофиг запустить виртуалку и даже попытаться там собрать и вообще, баги тут потому что опенсорс и никто тебе ничего не должен" — да, не должен, но может у Хиппа так по-красоте получается много всего сделать и не мучаться с поддержкой как раз потому, что он изначально задал себе такой высокий стандарт?


На самом деле, если задача позволяет ...

Да, я просто хотел сделать упор на то, что sqlite 100% закрывает всю локальную часть, не то, что он не годится как сервер базы данных. Люди вообще катастрофически недооценивают современное железо и думают, что нужен кластер микросервисов везде, где надо больше пары человек обслуживать, когда одна жирная-жирная машина может в теории принимать по килобайту в секунду на каждого жителя страны, включая стариков и младенцев :)

А как же Redis? И автор тоже тиклер, заметьте. Если хотите крутой продукт от большой компании, то вот вам опен сорс и кроссплатформенный VTK Toolkit и основанный на нем ParaView. И в нем тоже раньше основной язык был тикль, потом переключились на питон. ParaView, в том числе, пилят и в Los Alamos National Laboratory, и если вы посмотрите, на каких кластерах ParaView способен распараллеливаться, то удивитесь, что он же отлично работает и на домашнем компьютере. Примеров подобных много, на самом деле, просто они обычно лежат за пределами общеизвестного софта.

Это лишь подтверждает мою точку зрения — десять миллионов программистов за десятки лет создали кучу фигни, многократно дублирующую друг-друга, и несколько редких бриллиантов :)

Нормальная эволюция же. Неужели вы претендуете быть мудрее природы и сразу создавать шедевры?:) Вот хотя бы сравните обычные Btree индексы в эскулайт и FTS индексы. Если первые не поддерживают сжатие индексов и вообще одинарное дерево, то вторые — мультидерево со сжатием индексов и zlib сжатием. Лет 15 назад я выкладывал сравнительные тесты для таблиц в миллиарды записей — и FTS индекс отлично работал даже на таких масштабах данных, в отличие от Btree. И да, FTS писали в гугл, а не Ричард, насколько я знаю. В архивах рассылки эскулайт можно найти длиннющий тред, где автор FTS подробно объясняет мне, как там все устроено и работает:) Так что все же один человек большой продукт не в состоянии сам написать с нуля, и нужно еще уметь организовать высококлассную командную работу, что не менее сложно, чем создавать отличный код. Я до сих пор удивляюсь, как подробно команда эскулайт в рассылках отвечает на вопросы — и именно благодаря всем этим объяснениям они сумели комьюнити создать.

Хорошо, убедили! Призываю всех быть как команда SQLite и все причастные разработчики — задавайте внутреннюю высокую планку, будьте дружелюбны и работоспособны и пусть ваш софт завоёвывает мир не потому, что остальной ещё хуже, а потому что лучше сделать практически невозможно :)

Кто-нибудь может объяснить, в чем удобство в отсутствии типов у колонок? В чем фишка? С первого взгляда выглядит скорее как минус, чем как плюс, но, может, я что-то не понимаю?

Попробуйте большой датасет из форматов типа CSV и подобных без строгой типизации загрузить в строго типизированную базу данных, например, в PostgreSQL. Вылезет уйма непредсказуемых ошибок типов, которые надо устранить до загрузки - то есть писать скрипты для построения гистограмм значений по столбцам для определения невалидных значений и прочее, что элементарно делается в SQL. Еще можно попытаться создать все столбцы текстового типа, потом вносить в них исправления и менять их тип, при ошибке снова проверять и исправлять. В результате окажется, что часть значений так сразу не поправить и тип многих полей останется текстовым, что потребует фильтрации невалидных значений и конвертацию остальных в нужный тип при каждом запросе… и так пока весь датасет не будет вычищен. Или можно загрузить датасет в SQLite с динамическими типами и сразу пользоваться всеми возможностями SQL для чистки данных и работы с ними. Поскольку SQLite создавался именно для замены разных самопальных форматов данных, такая возможность замечательно в том помогает.

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