Ну выскажу и я своё мнение
Поставил для пробы 1.1 beta2, в админке конечно добавили кучу всего...
Но как-то работает он помедленнее, 1.0. Интересно было глянуть как выглядят таблицы теперь (после того как их грозились улучшить). Жалкое зрелище честно говоря, стало еще хуже, чем раньше. Как так можно делать??? Или Мэтту слово планирование вообще не известно. Типы данных вообще ощущение, что выбирались случайно. К тому же загадочная любовь к типу BIGINT (это число до 1.8*1019), я вообще не представляю зачем в форуме могут понадобится такие числа, разве что если даты все сохранять в виде количества микросекунд прошедших начиная с эпохи появления человека.
Типы в разных таблицах не согласованы, например, ip в одной таблице VARCHAR(16), в другой VARCHAR(32), в третьей VARCHAR(64), ну ладно, допустим сложно было посчитать что ip это максимум 15 символов, но мог бы уже остановиться на каком-то одном числе.
id юзера (по определению это целое число больше 0) - в IBF для него используются следующие типы INT, BIGINT, VARCHAR(32). А вообще-то если немного поразмыслить есть же ограничение на размер таблицы (в разных системах от 2 до 4 гигабайт), тот же тип INT это 4 байта, т.е. получается если хранить только номера юзеров, то максимум мы сможем сохранить 537 миллионов записей, но ведь мы храним достаточно много инфы о юзере, пусть даже 200 байт о каждом юзере (хотя реально получается значительно больше), получится, что в таблицу мемберов влезет ну максимум 3 миллиона записей, т.е. тип MEDIUMINT перекрывает нужный нам диапазон в 5 раз, и при этом он почти в 3 раза меньше чем BIGINT.
Тем более что поле id обычно индексируется, получаются индексы в несколько раз больше, а как результат медленнее работа с базой. Ну, а когда VARCHAR используется для хранения чисел, за это вообще по голове нужно хорошо давать.
И на таком же уровне структура всей базы. Можно наверное в учебники по MySQL добавить, в качестве примеров, как нельзя делать.
В общем я разочарован...
Может скинемся подарим Мэту книгу по MySQL