Основные важные для меня сейчас вопросы по форуму

1. Язык движка. Самое очевидное, конечно, PHP, но вдруг у кого-то на эту тему есть мысли? Что я вижу тут:
1.1. Perl - медленнее в работе с MySQL (ориентировочно - основным и массовым движком), труднее (в наше время) отладка и оптимизация, более опасный синтаксис.
1.2. C# - было бы великолепно и по скорости и по компактности, но проблемы с большинством хостингов.

2. Структура БД. Варианты:
2.1. Классический формат нынчешних форумов - "всё в одной таблице". (То, что в БД таких таблиц много - это непринципиально). Дата постинга, автор, текст, служебные поля...
2.2. Использовать нынешнюю структуру CMS, реализация иерархических объектов на плоских БД. Каждая таблица примитивная - идентификатор ресурса и данные. Отдельно таблица для текста постингов, отдельно - для описания. Отдельно - для дат этих постингов и т.п.

Плюсы классического - меньше нужно писать PHP-кода, больше операций возлагается на БД. Минусы - плохая расширяемость, возможно (нужно проводить исследования) меньшая скорость на больших и сложных базах, особенно в JOIN-запросах.

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

4. Делать ли форум совершенно автономным или же вместе с CMS? Всё же, общего там будет едва ли не 2/3, если не 3/4

> Язык движка.

Java?

1. PHP однозначно. Массовость на первом месте.
2. Не скажу - не спец, но... у юзеров (aka админы) имеется потребность работать с базой на разных серверах. Я в их числе, т.к. мой хостер, зараза, постоянно роняет базу на пол и ниже, вплоть до полного андеграунда и мне, как админу, хотелось бы иметь копию базы на другом сервере с возможностью её аварийного подключения. Или, как вариант, разгрузить часть базы у одного хостера и нагрузить у другого... ВСЕ варианты глупо описывать - достаточно вспомнить все варианты RAID при хранении данных... Аналогия близка - не так-ли? Что мешает поставить знак равенства?
3. Не понял - это про файлы в /source и /skin ? Тогда "да". Админу проще дома, не спеша, вносить туда изменения, чем скорей-скорей-время в базе данных ковыряться... Это вообще бесовская выдумка для увеличения доходов провайдеров.
4. Да! Система управления контентом позволит (вероятно) строить ресурс по своему вкусу. Скажем, я сейчас под двушку расписал (мечты расписал) кучу фич, которые на мой взгляд были бы полезны для проекта "материнство". Полезны юзерам. Но как сильно придётся курочить двушку (IPB 2.0)... аж жуть! CMS может быть упростит... С эти столкнётся каждый админ, который строит не ради личного интереса (есть такие - им не до юзеров), а для людей... для своих юзеров.

Как расширение п.2 скажу, что у меня сейчас использовано 3 Гб дискового пространства. На них хранятся аттачи пользователей. Мой хостер предоставляет только 1 Гб и не более... Пришлось купить 2 хотинга по 1 Гб (плюс хороший человек со своим сервером). Да, так вот... аттачи грузятся на три разных сервера, а не в папочку /uploads которую любезно предоставил разработчик. Т.е. нужно сделать и возможность загрузки аттачей не только на свой сервер, но и на удалённые тоже...

...в теле такая приятная гибкость образовалась...

Наблюдатель>2. Не скажу - не спец, но... у юзеров (aka админы) имеется потребность работать с базой на разных серверах. Я в их числе, т.к. мой хостер, зараза, постоянно роняет базу на пол и ниже, вплоть до полного андеграунда и мне, как админу, хотелось бы иметь копию базы на другом сервере с возможностью её аварийного подключения. Или, как вариант, разгрузить часть базы у одного хостера и нагрузить у другого... ВСЕ варианты глупо описывать - достаточно вспомнить все варианты RAID при хранении данных... Аналогия близка - не так-ли? Что мешает поставить знак равенства?

Имеешь в виду - часть БД на одном хостинге, часть - на другом? Вообще, это будет уровень драйвера БД, так что расширить функциональность форума до такой всегда можно будет. А имеющаяся сейчас идеология БД CMS, в принципе, позволяет это.

Наблюдатель>3. Не понял - это про файлы в /source и /skin ? Тогда "да". Админу проще дома, не спеша, вносить туда изменения, чем скорей-скорей-время в базе данных ковыряться... Это вообще бесовская выдумка для увеличения доходов провайдеров.

Нет. На этом форуме, ещё со времён переделки UBB при написании каждого сообщения сохраняется его некомпилированный (языком разметки) оригинал. Для последующего редактирования и для цитирования при ответах. Все известные мне форумы и CMS либо хранят только уже скомпилированный HTML и для редактирования проводят декомпиляцию, что весьма затрудняет реализацию сложной разметки, либо хранят оригинал и компилят каждый раз на лету, что негативно сказывается на производительности.

Наблюдатель>4. Да! Система управления контентом позволит (вероятно) строить ресурс по своему вкусу. Скажем, я сейчас под двушку расписал (мечты расписал) кучу фич, которые на мой взгляд были бы полезны для проекта "материнство". Полезны юзерам. Но как сильно придётся курочить двушку (IPB 2.0)... аж жуть! CMS может быть упростит... С эти столкнётся каждый админ, который строит не ради личного интереса (есть такие - им не до юзеров), а для людей... для своих юзеров.

Отчасти это многое упростит в движке форума. Скажем, сейчас скины страниц в CMS - это обычные же страницы на CMS. Также можно будет реализовать и скины форума. Каждый пользователь, имеющий доступ сможет создавать страницы прямо из форума. Например, подготавливая какой-то материал и т.п.

Но это несколько усложнит движок. С точки зрения администратора. Напомню, скажем, одну из причин предпочтения многими пользователям phpBB преде iPB - именно простота администрирования phpBB.

Хотя, наверное, можно предусмотреть два уровня администрирования. Упрощённый и развёрнутый

Наблюдатель>Т.е. нужно сделать и возможность загрузки аттачей не только на свой сервер, но и на удалённые тоже...

Это как раз несложно. Предыдущая реинкарнация CMS умела работать со страницами удалённых хостигов по FTP. К нынешней версии эта возможность была удалена в связи с появлением своего сервера Но - можно вернуть. Хотя не с полной функциональностью. Понятно, что многие вещи реализовать для удалённой машины не выйдет.

По третьему вопросу. Наверное, возможно компромиссное решение в виде отключаемого кеширования откомпилированного текста. Т.е. тексты хранятся в исходниках. Кому не нужно - кеш комиплированных текстов выключают и не используют вообще. Каждая страница генерится на лету. Годится, понятно, только для простой разметки. Или тормозить будет. Кому не жалко отвести N Мб под кеш - пусть отводят, тогда страницы при генерации будут брать тексты оттуда. Ну и поверх этого всего - см. предложение в Как на счёт статических страниц для форума?

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

>1. Язык движка. Самое очевидное, конечно, PHP, но вдруг у кого-то на эту тему есть мысли?
Мне кажется, пока надо писать на PHP, а там будет видно. Кто-то уже высказывал мысль, что при большом желании всё можно и переписать, сделав разные варианты. Но на сегодняшний день, если учитывать цели, PHP мне кажется наиболее адекватным вариантом.

>2. Структура БД. Варианты:
>2.1. Классический формат нынчешних форумов - "всё в одной таблице".
>2.2. Каждая таблица примитивная - идентификатор ресурса и данные.
А я считаю, что надо совмещать эти подходы. Например, в том же PhpBB (в отличие от IPB) текст постинга хранится отдельно от таблицы остальных параметров постинга. Мысли (дилетантские, ибо не имел дела с подобными проектами - в плане объёма БД и расширяемости) у меня такие.
1. Если каждое данное хранится отдельно, придётся делать слишком большое количество отдельных запросов к БД. Зачем тогда нужна СУБД? Может, тогда уж и альтернативную СУБД написать? Поэтому то, разделять что нет причин (перечисляемых ниже), следует объединять в одной таблице.
2. Если какое-то поле является типичным полем данных переменной длины (типа TEXT, BLOB etc.), его логично выносить в отдельную таблицу, чтобы не мешалось при поиске по остальным полям.
3. Если разные группы полей имеют разные области применения (проще говоря, обычно выводятся на разных страницах), мне кажется логичным для наших целей разносить их по разным таблицам.
4. Большинство модулей (и уж точно все написанные "сторонними разработчиками") должно быть независимы. И основные таблицы должны изначально продумываться с учётом расширяемости.
Если попытаться принять этот вариант, то это большая работа на стадии планирования структуры БД. И надо бы действительно проводить исследования, ибо критична скорость.
А если говорить о структуре БД в разных форумах, то когда я сравнивал бесплатные, самой красивой (т.е. логичной) мне показалась структура БД PhpBB. А вот в некоторых деталях структуры БД IPB я не смог разобраться, пока сам его не поставил.

>3. Требуется ли хранить исходник сообщения. Нынешний язык разметки слишком сложен для адекватной декомпиляции. Хотя этот вопрос можно сделать опциональным.
Полностью согласен. Точнее, можно сделать не совсем так. Мы предлагаем два варианта (для выбора меньшего из зол). Первый - с "удвоенным" объёмом БД. Второй - с урезанными возможностями языка разметки, который допускает адекватную декомпиляцию. А дальше пусть админ выбирает.

>4. Делать ли форум совершенно автономным или же вместе с CMS?
Вот по этому вопросу у меня пока мнения нет. Возможно, имеет смысл широко поспрашивать владельцев сайтов / форумов.