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

(Reply to this) (Parent) (Thread)

Не, как раз об этом я говорил выше:

>>> Тоже можно рассматривать как БД, "объектную", хехе.

Мне, знаешь ли, удобней на своём GPPL запросы составлять, к обычным спискам или деревьям (структур). Могу стандартные запросы, типа фильтров, могу хитровыебанные, которые ты неделю в SQL писать будешь, хехе:

select * from a where i=blabla
(~>> a (select (λ~>> i (equal? "blabla"))))

(Reply to this) (Parent) (Thread)

Бля, этот SQL просочился на уже в мозг, вот же паразит, хехе, конечно надо писать:
(~>> a (filter (λ~>> i (equal? "blabla"))))

(Reply to this) (Parent)

>к обычным спискам или деревьям (структур)
а, ну да, линейный перебор рулит же. а SQLite категорически требует, чтобы всё было сделано одним огромным запросом, а иначе лично рич хапп придёт, расстреляет и отнекросодомирует.

а ещё кому-то будет очень прикольно пытаться прочитать твои «плоские файлы» лет через десять-двадцать, не имея на руках исходников. например, тебе, когда ты исходники нечаянно. потому что самые клёвые проблемы — это проблемы, которые ты создаёшь себе сам на пустом месте.

(Reply to this) (Parent) (Thread)

Ну, до миллиона линейно, а дальше хэш-таблицу можно сделать.

Никому мои файлы и через 100 лет не понадобятся. И твои тоже, хехе.

Но проблемы, - это да. Люблю создавать проблемы и решать их потом, бггг, - путь настоящих самураев.

(Reply to this) (Parent) (Thread)

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

>Никому мои файлы и через 100 лет не понадобятся. И твои тоже, хехе.
the famous last words, ага.

так, вспомнилось: был у меня когда-то (лет двадцать тому) весьма продвинутый клон lode runnner, к которому я и ещё пара человек нарисовали дохуя комнат, связаных друг с другом. всё это хранилось в уебанском формате, который я выдумал с недосыпа, с какой-то кастомной (не rle) компрессией. исходники проебайтунг, а формат я потом так и не реверснул. жаль, потому что игра была довольно забавная.

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

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

(Reply to this) (Parent) (Thread)

Что-то выдохся я спорить, однако. Потянуло на философские размышления.

Это всё эстетические предпочтения. У меня - минимализм, у тебя - робастность, например. Эстетика разная... и это хорошо.

(Reply to this) (Parent) (Thread)

без проблем: мы ж не «для победы» спорим, а так, для интересу — развлечься, да попутно может какие-нибудь интересные аргументы услышать.

(Reply to this) (Parent) (Thread)

может будет интересно. вот я писал сборщика информации, который сохранял данные в csv-подобные текстовые файлы. по информации потом надо было делать простые запросы вида select * where x = 'хуй'.

основные аргументы в пользу этого против СУБД были такими:

1. для просмотра таких файлов и 9 из 10 операций над ними нужен всего лишь текстовый редактор с поддержкой регэкспов. в крайнем случае за пять минут пишешь на питоне скрипт, который тебе эти данные нужным образом преобразовывает и/или обрабатывает.

2. исключительно простое чтение и запись, парсить результат можно хоть на паскале, не задумываясь о подвинчивании к СУБД. и никаких промежуточных состояний при записи: строку в файл вывел, сделал flush (или просто буферизацию заранее перевёл в newline-режим, если можно) - всё. разве что свет вырубят, но тогда даже в худшем случае попортится лишь последняя строка.

3. одна база = один файл, который как машино-, так и человекочитаем. это означает, что рабочая копия, экспорт и бекапы имеют одно и то же представление. у многих же СУБД база представляет собой дикий винегрет из файлов (передаю привет mariadb), а для переноса или бекапа базы приходится отдельно делать экспорт данных из неё.

4. если жёсткому диску станет плохо и база побьётся (и такое бывало), то в случае текстового формата ошибки затронут лишь конкретные строки, а значит их будет совсем несложно найти и либо исправить (если возможно), либо отбросить. когда же портится двоичный файл, то всё, сушите-свет-тушите-вёсла. и да, я знаю про встроенные средства восстановления в СУБД. sounds good, doesn't work (снова привет, mariadb!). плюс я хочу лично видеть побитые строки и степень их побитости, а не получать в итоге "вот это вот удалось спасти, а вот про это уже забудь", хотя там мб просто букву "о" в фамилии "Хуесосов" задело.

(Reply to this) (Parent) (Thread)

ля, подписаться забыл. это ЧД еслишо

(Reply to this) (Parent)

1. скулит идёт вместе с кли-тулзовиной. можно как собрать, так и скачать с сайта для кучи систем. дело одной минуты. и там внутре неонка. SQL, то есть. обрабатывай на здоровье. и ещё он умеет экспортировать в цсв, хтмл, жысон, и — кажется — откуда-то даже импортировать. и транзакции. по-моему, слабый аргумент вышел.

2. вот ты не поверишь, но примерно так работает и SQLite. ну да, аж целую одну дополнительную библиотеку надо. и благодаря журналам — тоже потеряешь только последнюю транзакцию (или несколько, если системный кэш не успел записать; но можно простой прагмой перевести в режим фулсинк. кстати, при ручной работе придётся каждый раз синкать руками. фу).

3. у SQLite так и есть: одна база — один файл. с форматом, который не менялся десятки лет. зачем тебе его «человекочитать» — мне не очень понятно. это небольшие конфиги имеет смысл (да и то вопрос спорный). а смысл «человекочитать» датасеты из raw-представления — нулевой. намного проще, удобней и эффективней написать простой select (в кли-тулзе даже автодополнение есть) и читать только то, что надо.

файл, кстати, можно читать из одного процесса, пока туда пишет другой процесс. сервер при этом не нужен.

4. это один из штатных сценариев SQLite. спецтулзы вытащат всё, что смогут, даже кашеобразное. и опять же см. про формат файла (он описан в официальной документации, подробно, побайтово). ты всегда можешь сам попробовать добыть что надо.

в общем, вижу сплошные преимущества SQLite здесь, и ни одного недостатка. ;-)

(Reply to this) (Parent) (Thread)

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

/ЧД/

(Reply to this) (Parent) (Thread)

ну вот, двумя фразами ты поломал мне весь нарратив.

(Reply to this) (Parent)