Flat ,
С записями одинаковой структуры это замечательно. Есть вопрос как хранить структуры с переменным числом полей, наподобие ассоциативных массивов?

Еще вопрос - как редактировать/удалять записи из такой структуры?

Думал об этом. Вот в реляционных базах, кстати, не используются многомерные представления в одной и той же таблице. Там используют ссылки на отдельные таблицы. Почему бы не поступить также? Можно, конечно, и эмулировать многомерные массивы таким примерно образом:

123|1|igor|ссылка1&ссылка2&ссылка3&ссылка4|следующее поле

Здесь четвёртое поле представляет из себя массив каких-то, например, ссылок, которые разделены другим, отличным от | знаком, в данном случае &. Парсить это очень легко. Если массив превышает определённую длину, то расширяем его вышеописанным образом.
Так что, возможен любой вариант.

На данный момент вот такие соображения.
Например имеем базу с пользователями. Если надо удалить пользователя из базы, то возможны три варианта:
1) Если в каждой записи сделать дополнительное поле удалён/неудалён, то при удалении пользователя просто помечаем "удалён", а следующего зарегеного пользователя помещаем на место удалённого и присваеваем ему тот же номер.
2)Последовательно сдвигаем остаток базы с затиранием этой записи. Следующего зарегеного добавляем в конец базы.
3) Ничего не делаем(не удаляем физически).

По первому варианту.
Тут возможно следующее: если имеем несколько записей одного пользователя, а новый не совпадает со старым, то придётся как-то сдвинуть или расширить остаток базы.
Второй вариант более предпочтителен. Ведь удаляем мы сообщения или юзеров не часто, поэтому не важен небольшой оверхэд при сдвиге элементов. Если сдвигать по одной записи, то это и безопасно, ибо если на сервере произойдёт сбой, то мы, по крайней мере, потеряем единственную запись. Если же сдвинуть остаток целиком, то мы потеряем этот остаток. Сдвиг даже большого числа записей происходит за приемлемое время. Тем более, что обычно удаляются новые юзеры или относительно новые сообщения, которые находятся в конце(внизу) базы. Поэтому эта операция довольно быстра.
Правда в этом варианте номера удалённых пользователей больше не используются..

При редактировании сообщения сдвигаем "хвост" и вставляем текст.

Удаленные записи/части записей лучше помечать как удаленные, фактически оставляя удаленные блоки без изменений.

Реальную очистку производить по запросу VACUUM (в СУБД так и происходит).

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

Произвольную структуру в записи можно хранить в виде текста (использовать сериализацию или json).

Согласен. Всё же, частый сдвиг - небезопасен.

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

Правильно. Один ум хорошо, а два лучше. Даже если после редактирования сообщения текст уменьшится, то оставляем как есть, ничего не сдвигая. Это правильное решение, спасибо что навели. Базу лучше не трогать, пусть себе лежит, как лежит.

Такс, а тут уже проблемы.. Ведь наша база, как предполагается должна быть упорядочена, например по id сообщения, то есть в конце будут самые последние сообщения, так мы их и выводим. Если записать отредактированное сообщение в конец файла, то порушится принцип упорядочености, и уже будет неприменим бинарный(двоичный) поиск по такой базе, то есть пропадёт основное её преимущество. В этом случае придётся применить некий принцип, который кстати используется при работе с файловыми системами и в базах данных.
Часть, которая влезает в редактируемое сообщение мы помещаем на место старого, а остаток, который не влезает, добавляем в конец файла, в запись, в которой в первом поле, где находится номер сообщения, записываем признак, того, что эта запись является продолжением другой записи, которая, в свою очередь, находится в другом месте, то есть, что данная запись разрывна. Например добавляем букву r в начало поля id:
r123|igor|привед медвед, это сообщение.
По букве r мы поймём, что это продолжение записи под номером 123 и не будем учитывать её при поиске по базе.
В первой же записи придётся записать индекс записи продолжения, для чего выделить своё поле. Такое поле будет и в записи продолжения, по которому мы поймём где искать дальнейшее продолжение. Это как в файловой системе, например такая система была в DOS. Да и в cqlite вроде используется.
Такая система несколько более сложная, однако позволит избавится о частого сдвига элементов.

Тоже интересное предложение. Например в тех же ссылках могут быть символы-разделители, что неприемлемо. Поэтому вы правы, если имеем многомерную структуру, то её лучше загнать в поле в json или каком-либо другом общепринятом виде, например csv или сериализовать.

Хочу обратить внимание ещё на один момент.
Система, которая используется в нынешнем exbb тоже имеет право на жизнь потому, что использует упрощённую иерархическую модель баз данных. А как известно иерархии очень эффективны что касается непосредственного доступа и лёгкости изменения, тем более, что данная модель поддерживается аппаратурой на низком уровне - это файловая система. Так что смысла полностью отказываться от данной модели нет. Просто она нуждается в переделке. Например: в данном движке одна папка, в которой находятся все файлы с юзерами. Известно, что файловая система начинает тормозить примерно от 1000 файлов в одной папке. Значит нельзя пихать туда большее их количество. Если следовать принципу иерархии, то имеет смысл разбить пользователей по разным папкам. В одной папке будут все пользователи на букву a, в другой на b и так далее. В этом случае тормозов не будет и при количестве пользователей несколько сотен тысяч. Или идёт разбивка по номерам пользователей: в одной папке все номера до 1000, в следующей от 1001 до 2000 и т.д.
Файлы с темами тоже имеет смысл разбить на отдельные страницы. Тогда редактирование сообщений будет относительно элементарной и быстрой операцией..

К тому же, память файлам выделяется страницами. Обычная страница 4 килобайта. Если файл будет иметь размер например 250 байт, то истинный размер файла на диске всё равно будет 4 килобайта. Поэтому маленькие файлы не выгодны. Если наша база будет весить 100 мегабайт, то на диске она будет иметь 400 мегабайт, на лицо явный перерасход памяти(и денег). Однако именно такие файлы лежат в папке members.. Чтобы этого избежать необходимо в один файл записывать информацию о хотя бы 4-х пользователях..
Или использовать такую схему: оставить одну папку members, но файлы иметь по например 100 пользователей. Такой файл целиком качается в память и разбивается в массив очень быстро. Если файлов будет 1000, то пользователей будет 100000. Этого с лихвой достаточно для любого форума.

Итак, вот что я решил..
Делать вменяемую СУБД возможно, но на это уйдёт куча времени, да и база будет недружелюбна к простым пользователям, ибо сообщения будут разбиваться на куски, которые к тому же будут валяться в разных местах файла.. Просто есть уже cqlite, зачем изобретать велосипеды.. Таким образом мы уходим от в общем-то здравой концепции exbb, которой необходимо придерживаться, иначе это уже будет совершенно другой форум..
Итак, оставляем концепцию формата хранения типа:
123|1|igor|следующее поле
То есть без сериализации. Это сохранит нам много нервов и дискового пространства.
Далее, в папке members в каждом файле сохраняем по 100 пользователей. Это даст нам постоянную высокую(ибо файл то небольшой) скорость загрузки даже при большом числе пользователей(несколько сот тысяч), а также избегаем потери дискового пространства из-за страничной организации памяти в современных ОС.
Также это обеспечит нам простой механизм изменение полей записей. К тому же это позволит нам иметь базу, в которой АБСОЛЮТНО(до самого последнего символа) отсутствует лишнее пространство. Если сообщение имеет определённую длину, то оно будет иметь ту же длину в файле, при этом ничего делить не потребуется, сообщение будет цельное, а также легко редактируемое.
Вчера написал функцию, проверки есть ли такой пользователь в базе или нет имея в виду новый формат файловой организации. Извините, если кому внушил ложные надежды, но мне нужен форум, который устраивал бы лично меня, а там уж кому нужно будет использовать мои наработки или подключится к его развитию.

Чувствую, последнее предложение ни у кого энтузиазма не вызывает..
Хорошо, - оставляем структуру папки members, как сейчас, то есть один файл на пользователя, но структуру записи делаем такую:
return array('id'=>1 ,'name'=>2,'pass'=>'21232f297a57a5a743894a0e4a801fc3');
Об этом я писал выше. Как видно здесь я избавился от лишних пробелов и переводов строки, которые оставляет функция var_export. Пусть занимает столько же места что и сериализация, однако место и так пропадает, и выделяется по сути с запасом на страницу памяти, так что ничего страшного. Зато легко сохранять многомерные структуры и база легко читаема и изменяема вручную. Не будем революционизировать движок. оставим концепцию в сохранности. Так будет легче конвертировать. Изменим общую структуру движка, сделав её более модульной. На том и порешили?
Написал новую более продвинутую функцию удаления непустой директории, а также функцию добавления в базу и функцию чтения из базы, которые позволяют уйти от проблемы обнуления. Юрий говорил, что проблема снята, однако судя по старым функциям проблема осталась на прежнем месте.

Flat , вот и правильно. Численность даже самых крупных форумов на exBB не превышает первых тысяч. И это при том, что очистка от неактивных пользователей далеко не на всех форумах делается.

Спасибо, что откликнулись, Yamaliya .
Да, так я и сам подумал. Зачем городить огород. Если нужен форум под миллион пользователей, то лучше выбрать воблу(вбюллетин)) или любой форум на mysql. Форум до ~50 000 пользователей может с успехом работать и на подобном этому движке.
Всё, нужно включаться в работу, поэтому писать буду только по делу, по делам текущим.

Flat, как Ваши успехи с файлами прямого доступа?

Постом выше я писал:

Однако идею не оставил. Похоже, что надо будет предусмотреть оба варианта: один на файлах прямого доступа, а другой традиционный подход - один файл-один пользователь. Соблазн велик, что ни говори.. Да это и правильно так сделать, одним словом: по-компьютерному, так как и должно быть.. Но сейчас я был занят авторизацией. Авторизация практически готова. Та что в движке, меня не устраивает. Там идёт раздельная обработка разных состояний, в зависимости от включённости кук у пользователя, наличия "старой" сессии или "новой" и т.п. Головной модуль, через который подключаются другие, тоже практически готов.
Сейчас сделаю основные модули, типа: авторизация, входа/выхода с форума, регистрации, а затем всё остальное.
Знакомясь с кодом движка exbb некоторые вещи вызывают недоумение. Например, в файле fm.class.php есть функция _CheckBannedIP(). В ней есть такая строчка:

Функция array_filter вторым параметром принимает имя collback функции, которая вызывается на каждом элементе массива. Здесь указана функция "Banned", однако ни в одном файле движка я её так и не нашёл.. Выходит что IP не проверяется? Вэб-мастер может быть подскажет что тут не так. Вроде везде искал, в том числе и в новом 2.0 движке..
Далее, в файле common.php дублируется код

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

В файле lib.php есть функция

Про lib.php я и забыл.. Извиняюсь.