Froggy-BLC 1.02 (Книжная Система Сайта, CMS)

Спрошу у автора: а чем работа на файлах без БД лучше работы с локальной БД, например, SQLite? Там тоже файл, только один, дополнительные процессы запускать не надо, как и файлы, работает на любом утюге. Тоже почти «вещь в себе», из дополнительных зависимостей только одна библиотека.

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

Тоже почти «вещь в себе», из дополнительных зависимостей только одна библиотека.

Посмотрел в портах FreeBSD, у самой sqlite тоже зависимости есть (хотя, наверное, по большей части на этапе сборки):

sqlite-2.8.17_5
    SQL database engine in a C library
    Description : Changes : Packages
    Maintained by: freebsd-ports@FreeBSD.org
    Requires: gettext-runtime-1.0_1, gmake-4.4.1, indexinfo-0.3.1_1, pkgconf-2.4.3_1,1, readline-8.3.3, tcl86-8.6.18_1

(Опять tcl, странно…)

в случае частичной порчи данных из отдельных файлов (они ещё и текстовые, наверное?)

ИМХО, если что-то можно логично хранить в виде текстового файла, превращать в бинарь – нонсенс.

Я с SQL мало дел имел. Такой вопрос: насколько БД useable с системами контроля версий?

насколько БД useable с системами контроля версий?

Сам файл БД? Настолько же, насколько и любой другой не текстовый формат.

ИМХО, если что-то можно логично хранить в виде текстового файла, превращать в бинарь – нонсенс

Можно совместить, все метаданные в БД, текст книг оставить в файлах. Профит от БД как минимум быстрый поиск.

Всё очень просто: я не знаю SQL. А на момент начала написания этой системы — научить меня было некому. Я тогда даже Чат-ЖПТ не умел использовать (то есть не знал про него ничего).

К SQLite у меня множество вопросов по части Мульти-Доступа на запись и блокировках. Мне именно нужно сделать было так, чтобы БД комментов была для каждой статьи своя, и БД контента — всё лежало отдельно, так-как с одним-единственным файлом в очередях блокировки образуется «пробка», + кроме-того, мульти-доступ записи очень опасен. — Мне надо, чтобы каждый писатель, писал свою Копию *.new.$PID и в файл DBNAME.lock, атомарно, под блокировками LOCK_EX, LOCK_SH, LOCK_UN — записывался последний пришедший на запись $PID. И из этой «лотерейной записи» брался тот писатель, который победил в «конкурентно-кооперативном конфликте», и его файл переименовывался сразу атомарно в DB_REAL. (Проигравшим писателям выводится текстарея с постом, который только-что хотел запостить корректор или комментатор) … Причём, вся логика обмазана идеями KERNEL_PANIC; Это fopenOrDie(), freadOrDie(), fwriteOrDie() итд. — Смысл в том, что если в системе что-то искарёжилось плохими данными — она не доедет до ренэйма *.new.$PID в DB_REAL, никакие данные не испортит, а просто упадёт со строчкой сообщения о панике, чёрным по белому.

То есть, моя система отказоустойчивая.

Кроме-того, БД комментов представляет из себя li/ul-лапшу, чем-то похожую на XML. Древовидность комментов там до мозга костей файловая.

Мне кто-то говорил, что SQLite не даёт возможности писать из нескольких пидов сразу, многопоточно. И мне так представилось, что для неё сделать блокировки гораздо сложнее, чем на файлы. Кроме-того, если хранить всю базу в одном файле, то все данные скопом, при копировании в *.new.$PID — при набежавших писателях завесят много на диске.

Просто мне хотелось иметь железный контроль над всеми алгоритмами, а об SQLite я не осведомлён.

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

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

И у меня есть поиск по этому ужасно-длинному меню, на джаваскрипте.

А какое твоё мнение о Thalassa CMS от @Croco?

Мне кажется, раз дядька написал ЦМСку на Си — он очень суров. В его скилле я не сомневаюсь, просто иногда кажется, что он либо отстал от жизни малёх, либо, местами читал документацию по диагонали. Но скилл есть.

Я не настолько хорош, чтобы судить других программистов и кодеров (и прочих девопсов). Я просто бешенный скрипткед-шыз, You know…

Всё очень просто: я не знаю SQL.
К SQLite у меня множество вопросов по части Мульти-Доступа на запись и блокировках

Ты даже SQL не знаешь, но откуда то у тебя множество вопросов к SQLite... Научись решать проблемы по мере их поступления.

SQLite… Научись решать проблемы по мере их поступления.

Или можно изначально не создавать себе проблем.

sql БД берут, что быть иметь: 1) надёжность 2) многопоточность/многоклиентность 3) независимые от ЯП встроенные функции

SQLite не умеет ничего из этого. Да он минималистичен, но кроме как хранить в себе простые конфиги больше ни для чего не пригоден. По всем вышеперечисленным пунктам обычные файлики лучше. Особенно если хранить и править картинки - склайт на такой задаче сдохнет.

Или можно изначально не создавать себе проблем.

Почему ты думаешь что автор уже не создал себе проблем?

Последние версии SQLite вполне себе надёжны, умеют в многопоточность на чтение и гибкую систему автоматических блокировок при записи(намного надёжнее того, что ТС реализовал у себя с файлами и PID'ами, так как работает не на уровне процессов, а на уровне соединений, хотя есть режим с использованием одного соединения, но я его не проверял), обладает широким набором встроенных функций, которые предоставляет SQL. Я, например, использую скулайт в одном своём проекте. Там у меня плодятся сотни горутин, которые очень много читают и десятки, которые пишут. Когда я говорю, много, я имею ввиду сотни запросов в секунду. Отлично работает, затыков нет, скорость работы не проседает. И не нужно в коде задумываться о парсинге файлов и ручной реализации локов при записи. Я в этом проекте поначалу тоже файлы хотел использовать, но потом провёл несколько экспериментов и таки решил использовать скулайт.

писал свою Копию *.new.$PID и в файл DBNAME.lock, атомарно, под блокировками LOCK_EX, LOCK_SH, LOCK_UN

Вот это уже проблема. Автор сам называет это лотереей.

Ты даже SQL не знаешь, но откуда то у тебя множество вопросов к SQLite...

Можно представить, сколько вопросов будет, когда (и если) он узнает хоть что-то «за SQL»... ;))

К SQLite у меня множество вопросов по части Мульти-Доступа на запись и блокировках

А к текстовым файлам это не применимо, не?.. ;))

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

В общем, скукота!.. ;)))

@Rodegast @shell-script

Рэбьята! Я не говорю, что SQLite плох. Я утверждаю, что мне очень хотелось сделать на файлах, так как никто не верил, что это вообще возможно.

Интерес был исследовательский.

так как никто не верил, что это вообще возможно

Ну это ты загнул. Посмотри на dokuwiki. 100500 лет работает на файлах.

SQLite не умеет ничего из этого. Да он минималистичен, но кроме как хранить в себе простые конфиги больше ни для чего не пригоден.

У меня в актуальном пет-проекте (десктопном, не веб) в скулайтовской базе где-то 70 тысяч записей (из них 40 тысяч в одной таблице), работает вполне шустро и надёжно. Это, мягко говоря, не «простые конфиги». Да, это не постгре, не фаербёрд и тем более не оракл. Но со своей задачей справляется, про «простые конфиги» сейчас прозвучало ну очень смешно.

Картинки хранить, может, и не надо. Даже в движках на основе MySQL, который в отличие от SQLite клиент-серверный, я видал такое, что в базе лежит только структурированная информация, а картинки, торрент-файлы и прочая блобень хранится в файловой системе, и из БД на неё ссылки кидаются. Наверное, авторы не зря так сделали. А, и имя пользователя в БД там было отдельное, никак не связанное с аккаунтами движка. То есть насколько там используется многоклиентность БД, вопрос тоже открытый. (Речь, в частности, про старую версию движка рутрекера, когда он ещё назывался torrents.ru, про картинки не помню, но вот торрент-файлы там точно лежали отдельно от БД.)

Да мы верим, верим. Просто интересно же обсудить альтернативы.

в базе лежит только структурированная информация, а картинки, торрент-файлы и прочая блобень хранится в файловой системе

Вообще-то так правильно... Всегда так делал.

Дополню по первому абзацу: то, что ты перечислил, это про клиент-сервер. «sql БД» это совершенно не обязательно синоним клиент-серверных СУБД. Локальным реляционным СУБД лет примерно столько же, сколько и ПК: dBase, потом FoxPro, Paradox… Просто в эпоху DOS применение SQL в них было скорее исключением, чем правилом, железо было слабенькое (хотя вот у Борланда через BDE можно было через SQL работать и с перечисленным). Но последние 25-30 лет вполне комфортно гонять SQL и в локальном варианте. Чем SQLite и пользуется.

Я утверждаю, что мне очень хотелось сделать на файлах, так как никто не верил, что это вообще возможно.

Проблема не в возможности, а в целесообразности. Тебе так SQLite советуют как раз потому что это наиболее правильный вариант хранения информации в файлах. А SQL учить в любом случае придётся, ну если конечно захочешь дальше развиваться.

Спасибо!

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

Ну и чтобы они написали на SQLite и грамотно. Я буду смотреть на их реализацию функциональности в коде, и сам буду делать так-же, «повторенье — мать ученья».

Чтобы без посредничества фриланс биржи — спрошу прямо здесь, на ЛОРе. Условия лишь таковы, что из прототип-макета надо попытаться вытащить как можно больше самых нормальных функций, и в перерывах, по вечерам обсуждать со мной работу. Естественно, никаких дедлайнов.

Вся беда в том, что мне говорят:

• Не пытайся в хэллоуворлде повторить алгоритм гипертекстуры Кармака, в 2026 будущее за Директ-Стримингом, и так уже никто не делает. Только замучаешься и ничего тебе это не даст.
• Не пиши Шаблонно-Объектную генерацию Радиант-Локаций DragonAge 2, так-как этот алгоритм выглядит как тупейший копипаст уровней, и не имеет никакого значения его «прикольность».
• Статический свет RAGE и DragonAge 2 — устарел. Перестань насиловать логику. Эти гипер-оптимизации сегодня никому не нужны. Будущее за РэйТрейсингом. Учись лучше писать на C++ внутри Unreal Engine.

…И я разве кого-то слушаю? — Нет. Делаю контр-продуктивные вещи. Их в 2026 делать нельзя, а я всё-равно буду.

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

В докувики скорее-всего одна статья — один файл, и нет БД комментов.

Потому там нет функций конкурентного доступа.

То, что написал я — это типа-как технодемка, что-то вроде демосцены. Типа «Смотрите как я могу».

Это так сделано потому, что очень хотелось написать типа-как «свою СУБД», но «без головы / без SQL».

Задача была именно «проникнуться пониманием», и пожертвовать вещами типа Поиска по БД.

Самая сложная задача была в обработке одной строки БД: Трункейт() + fwrite(ab) + TailConcat()

Это потому я так радуюсь, что сделал конкатер через exec()

Потому там нет функций конкурентного доступа.

Есть. Там несколько человек могут одновременно редактировать одну статью.

Это потому я так радуюсь, что сделал конкатер через exec()

У меня на серверах запрещён exec() ;) Поэтому этот момент я просто не стал комментировать.

На моём хостинге — он оказался включён глобально.

Я, чтобы все разузнать — замучил службу тех-поддержки

Тут вопрос это на каких объёмах. У меня например были объёмы вплоть до бесконечности: если не под свой сервачок пишу, я же не знаю, сколько пользователь положит данных. И оперативки не знаю, сколько у пользователя. В общем, при нагрузочном тестировании 100Гб объём базы в виртуалке и 8Гб выделенной ОЗУ, оно сдохло. А файлики работали предсказуемо как часы.

Кроме того, файлики бесплатно параллелятся, архивируются или версионируются: смотря на какую ФС положишь. С склайт так не выйдет.

Последние версии SQLite

Но я давно проверял, может в случае последних версий вы и правы

Так это раньше. Сейчас если те 3 пункта не нужны, берут nosql обычно.

100 гигов база - это уже такой серьёзный объём даже для нормального прода. Тут я точно смотрел бы уже на что-нить типа постгреса, даже не мускля.

берут nosql обычно

Вот честно, не люблю, когда везде пихают nosql. Это стильно-модно-молодёжно, но не везде оно работает как надо. Много проблем из-за этого встречал.