Приветствую. Думаю стоит начать обсуждать структуру форума.
Первый этап и параллельно я бы начал делать конвертер из файлов.
У кого какие мысли и предложения?

Можно попросить актуальный код и пару файлов на поиграться?
Или код хранения данных не менялся и достаточно расковырять дистрибьютив ExBB FM 1.0 RC1? (кстати, его обновляли без смены номера версии, последний раз, насколько вижу, 15.07.2009)

По новой структуре я пока жду обновление репозитория. Имеющиеся наработки по форуму DeepVarvar'ом вроде бы ещё не опубликованы.

Не опубликованы - я застрял на обвязке пользака (вход, выход, рега, форгот).
Но могу быстренько пойти на сближение залив тупо базовую структуру БД и контроллеры+шаблоны вывода.
Сделать?

Хороший вопрос.
Мне пока хватит и только базовой структуры - расковырять имеющиеся файлы и соображать что куда писать надо.

Готово. Лежит в репо.
А еще вопрос - почему дата время регистрации пользака в CURRENT_TIMESTAMP ?
Всмысле зачем в таймстампе?

0) потому что умеет default CURRENT_TIMESTAMP (datetime научился этому только в 5.6). Зачем заполнять данные по-умолчанию на приложении, если это может сделать СУБД?
1) за предстоящие 20 лет ещё много раз всё поменяется, форум будет заменён ещё раза 3, а mysql вообще загнётся
2) компактнее в два раза

А это не повлияет на:

1) сравнения,
2) сортировку,
3) форматирование при выборке дат/времен,
4) часовой пояс установленный через SET time_zone = '+03:00'

?

1-3) нет, date, datetime и timestamp - очень близкие родственники.
4) зависит от. таймштамп хранится всегда в UTC и обращает внимание на time_zone, в отличии от datetime. Если записать что-то в timestamp, изменить таймзону и прочитать обратно - строковое значение будет другое. Но если пересчитать в изначальную таймзону - то идентичное.

Хмм, а я вот проверял - работало. Версия 5.1.73-1
В любом случае убедил, т.к. либо ты вычитал в доках, либо руками напоролся на касяк с таймзонами в datetime, но таймстамп будет работать везде.

Исправь тогда, плиз, остальные datetime поля во всех табличках.
Заодно глянешь может еще где-то касяк есть.

Да, это из доков:
http://dev[dot]mysql[dot]com/doc/refman/[dot][dot][dot]en/datetime[dot]html

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

Продолжим тут отдельно про БД.

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

я бы подобные данные сохранял в формате таблицы
user_id, setting, val
где пара user_id, setting - есть уникальна или первичный ключ,а в setting хранится некоторый ключ сеттинга, все сеттинги изначально декларируются гдето и если такового сеттинга не найдено в бд то он берется из дефолтного значения, а после изменения последнего сохраняется в эту таблицу

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

В этой идее смущает только поле val - потому как хрен его знает, какого типа и какой длины значение ты туда запишешь. А может индекс понадобится пробросить еще.

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

Я именно про него.
Смысл писать в текст значение '1' только лишь для включения оповещения чего-то там на мыло. А дефолт как выставлять? А выборку как? А условия? Кастовать?