Предпочитаю флэт файлы.

(Reply to this) (Thread)

чтобы потом изо всех сил руками писать кривой аналог SQL для добывания из них всяких данных? смысл?

чистый текст хорош только для одной цели: чтобы дать хумансу что-то почитать. если нужна хоть минимальная обработка — его смысл сразу пропадает.

скулит же обладает в том числе и тем достоинством, что при помощи его стандартной cli-утилиты можно делать с базой что угодно — в том числе и получать оттуда тексты для хумансов в любом удобном виде, хоть html.

а если файлы ещё и не текстовые, а бинарные — то смысл использовать их вместо скулита вообще отрицательный: зачем писать и отлаживать код для работы с ними, для проверки целостности, и так далее — если этот код уже десятки лет как написан, со всех сторон оттестирован и отлично работает?

(Reply to this) (Parent)

p.s.: и да, скулит позволяет в том числе открывать одну базу из нескольких процессов. так что пентаграмма может спокойно писать в лог, а я в это же время могу лог обрабатывать. без, кстати, необходимости проверять на частичные данные: скулит автоматически обеспечивает консистентность.

(Reply to this) (Parent) (Thread)

Вот, к примеру, anki. Карточки надобавлял туда, думаю теперь, как их оттуда выковырять. В какой-то, сука, дебильном СУБД-формате оно там, в текстовом редакторе не читается. Код дебильный, бидон и руст, автор - ламо, копаться противно. Сама же программа имеет довольно фашистское представление, что надо юзеру. Что (она считает) не надо - запрещено, ибо ибо! А я вот не люблю, когда за меня фюрер думает.

Люблю читать и руками править. А то как нахуярят БД ваще везде, где надо, и где не надо... И язык sql - дурацкий, живу без него уже много лет, и отлично себя чувствую.

Как данные обрабатывать? А проще надо быть: file->list, в память загрузил, обработал и list->file, выгрузил. До миллиона записей отлично всё работает. Тоже можно рассматривать как БД, "объектную", хехе. А если разово что-нибудь поправить, то в текстовом редакторе - replace all... А то делать мне нечего, cli к тысяче говнотулзов учить.

Ну, а сломается что, так не беда. Бэкап файлам сделаем, ручками починим, если чо.

(Reply to this) (Parent) (Thread)

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

в как чужая так разумеется сразу фащизм и фюрер, cli к тысяче говнотулзов учить, и язык дурацкий, и руками читать-править нельзя.

(Reply to this) (Parent) (Thread)

Нет, это тут ни при чём. Аргументы здесь независимы от структуры БД. Одна и та же структура может быть храниться в РСУБД, ООСУБД, бинарных файлах или плоских текстовых файлах.

(Reply to this) (Parent)

вот поэтому и нахуй не надо хранить в кастомных форматах. формат базы SQLite десятка два лет уже стабильный, отлично обрабатывается стандартной скулитовой cli-тулзовиной. и там внутри в виде служебных табличек лежат все CREATE. читай и правь, какие проблемы-то?

>А то делать мне нечего, cli к тысяче говнотулзов учить.
не учи. достаточно одной тулзы. и SQL. который, кстати, весьма хороший декларативный язык. во многих случаях кроме простых запросов через sqlite3 и писать ничего не надо.

(Reply to this) (Parent) (Thread)

Для меня это пройденный этап. Я этим страдал, когда ещё sqlite-а и в помине не было. Я ещё foxpro помню, на СМ машине патчил как-то хрень какую-то бухгалтерскую, на советской клавиатуре, типа такой, хехе:


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

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

так, для придания более верного направления: скулит — это встраиваемое (serverless, соответственно; embeddable) key/value хранилище. очень быстрое и очень надёжное. с дополнительным сахаром в виде возможности оперировать хранилищем через SQL-запросы.

(Reply to this) (Parent) (Thread)

Ну, я пользовался MS SQL. Табурет фокспро - то вспомнилось, типа такой я старенький ужо. Но микрософтовское говно посложнее sqlite-а будет, не так ли?

(Reply to this) (Parent)

Я понял, что ты его как хэш таблицу в свою прогу встраиваешь, но от этого оно не перестаёт быть СУБД, ага?

(Reply to this) (Parent) (Thread)

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

(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)