» Выбор бд для форумного клиента под Delphi

Суть вот в чем:
пишется клиент для форума (программа, которая позволяет работать с форумом без использования браузера и имеет ряд приемуществ в числе которых - хранение базы сообщений на компьютере пользователя), вот для этого хранения нужно и определится с бд.
Вопрос первый:
локальную или сетевую? если сетевую - то да, сомнений и вопросов нет - mysql, только здесь один существенный минус - согласится ли конечный пользователь руборда качать 11 мегабайт mysql server'a, а потом его еще и ставить? да и вдруг он выходит на форум с работы, из дома и от друзей, это че на всех машинах что ли ставить? интересно ваше мнение. Идем дальше, локальные бд. Тут есть из чего выбирать. BDE использовать не хочется по той же причине + глюкавость и сложность. Что остается:
1) ADO и Access - говорят неплохо, но когда размер базы не превышает 100-150 мб, дальше тормоза и прочие глюки. Кроме того у меняя за один день ничего с ним не получилось сотворить (я правда сильно и не пытался)
2) dbf, но не через DBE, опять же, а через какой-либо компонент. Упомянули TDbf, но, поискав, я убедился, что их немерянно, и фиг знает какой из них тот, что нужен. Есть врсии 1.11, 5.0.12 (!), документации нормальной нет, короче тоже трудности. Опыта работы с бд я не имею, так что выручайте.

Еще был какой-то вариант, какой-то компонент предлагали, но я не заомнил.
Что предложите/посовветуете вы и что скажете о вышеупомянутом?



Добавлено
вспомнил, Advantage - 3 вариант

Может имеет смысл связка MySQL (благо весь форум на нём и держится) + DAC for MySQL

Felix


Цитата:

Может имеет смысл связка MySQL (благо весь форум на нём и держится) + DAC for MySQL

я уже говорил про размер дистрибутива сервера

Это я понял. MySQL можно кастрировать до размера меньшего 2 Мб... и оставить его, при этом, в рабочем сосотоянии

Smog
FireBird - 4 mb
FibrPlus VCL - для делфи

c0r0ner

Цитата:

FireBird - 4 mb

ой, еще один поклонник птички

2ALL
сорри за офтоп, но нас таких мало!

Smog
Да, ты сперва опиши приблизительную архитектуру, а уже от нее можно давать конкретные рекомендации

c0r0ner

Цитата:

Да, ты сперва опиши приблизительную архитектуру

архитектуру чего?

Добавлено

Цитата:

FireBird - 4 mb
FibrPlus VCL - для делфи

а ссылочки?

Добавлено
Felix

Цитата:

MySQL можно кастрировать до размера меньшего 2 Мб... и оставить его, при этом, в рабочем сосотоянии

а поподробнеЕ?

Добавлено
c0r0ner

Цитата:

FireBird

качаю

Цитата:

FibrPlus VCL

не нашел

Smog

Цитата:

архитектуру чего?

как будет работать БД, т-е режим, скачивать с сервера в локальную базу, синхронизировать локальную и удаленную, и т.п.

Цитата:

а ссылочки?

http://firebird.sourceforge.net/

c0r0ner

Цитата:

скачивать с сервера в локальную базу, синхронизировать локальную и удаленную, и т.п.

база будет формироваться локально, локально и с ней будет происходить вся работа.

Добавлено
если с MySQL, то надо MySQL database server 4.0.20d - 20.7M качать?

Цитата:

Цитата:скачивать с сервера в локальную базу, синхронизировать локальную и удаленную, и т.п.

база будет формироваться локально, локально и с ней будет происходить вся работа.

несколько не понимаю: будет ли доступен конечному пользователю реальный контент?

На счёт как урезать MySQL: есть Дэнвер

Felix

Цитата:

несколько не понимаю: будет ли доступен конечному пользователю реальный контент?

клиент скачивает данные с сервера, которые ему выдает скрипт, и формирует на локальном компьютере бд для их хранения и проч

Felix

Цитата:

Дэнвер

а что-то я насчет его глюкавости слышал?

Smog
Денвер просто включает в себя урезанную версию mysql. Глюки денвера (лично не видел) не есть глюки mysql.
Дальше мое имхо:
Дело не столько в размере движка, сколько в самом факте его наличия в инсталляторе, необходимости его конфигурировать, запускать, возможности наличия последнего у пользователя и т.д. Я бы тоже посоветовал Firebird, но не сетевую версию а embeded - по сути 1-а dll-ка. Размер <2М. Компоненты для доступа - или IBExpress (есть в Делфи) или IBObjects или FIB+ - две последние платные. При необходимости перехода на сетевую версию проблем не возникнет - просто меняем embeded версию на сетевую.

кстати, в Firebird появилась т.н. "локальная редакция". Т.е. Ваша программа распространяется с dll файлом - сервером и работает с базой используя dll локально.

Соглашусь с народом, на данный момент оптимальнее FB, для хорошей базы данных нет.
Но есть одно большое но, с MySQL тебе всё равно прийдётся - с форумной частью....


Цитата:

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

а вот это, на мой взгляд, как раз не проблема - однократно настроил инсталлятор и в путь.

ADO и Access
Если хочешь быть мобильным, базу в 150-200 метров один хрен таскать с собой не будешь.

Felix

Цитата:

Но есть одно большое но, с MySQL тебе всё равно прийдётся - с форумной частью....

Это совсем не но, работа будет производится по запросоам через SQL и тип БД практически не имеет значения(конечно если не будет Oracle MS SQL и других гигантов)

Цитата:

Это совсем не но, работа будет производится по запросоам через SQL и тип БД практически не имеет значения(конечно если не будет Oracle MS SQL и других гигантов)

не о том разговор. Похоже я не совсем правильно понял ситуацию с файлами базы.
Я так понял, что пользователь формирует запрос на просмотр интересующих его тем, дальше клиентская часть остылает его на наш любимый форум и, соответственно, с MySQL сервака, который обслуживает IconBoard, данные заносятся в локальную базу и "делай с ним, что хошь..."

если это не так, а именно: у пользователя на компе лежит 200 метров форумного контента, то какой может быть разговор о том, что трудно качть 11 Мб MySQL?!?

Felix
Ты забываешь о времени. За год - 300 метров - это меньше метра в день.

Smog

Цитата:

хранение базы сообщений на компьютере пользователя

я не совсем понимаю, как это будет работать.
Плииз объясни, как будет идти наполнение базы.
Сразу все, или по ходу хождения по топикам?

Ибо сразу все, это около гига получится.
Правда если сжимать.. но все равно это очень много.
Нам трафика на сервере не хватит, раздавать такие объемы.

batva
Идея неплохая, но в реализации сложная. Вот если бы со стороны администрации поддержку оказать - например вывод данных в спец. формате для программы.
А обновлять надо топики выборочно конечно, иначе анрил, сервак заДОСим

Добавлено
Хотя кстати - можно высылать диски с содержимым форума (в формате БД программы), актуализация каждый месяц!

Мысли о синхронизации.

На самом деле, клиентом форума «только для чтения» является любой почтовик. Я подписан на огромное количество топиков. Мой почтовый клиент получает письма и автоматически раскидывает их по папкам в зависимости от заголовка. Таким образом, каждая папка у меня локально представляет собой контент одного топика. Причём топики для отслеживания выбрал я сам пользуясь штатными функциями форума. Хотя я подписан на много десятков тем (в том чиле, все самые «горячие» ветки из Варезника), суточный трафик терпим даже для моего модема. Таким образом, изобратать валосипед, на мой взгляд, не стОит — достаточно наделить клиента функциями приёма почты (загрузки с почтового серера только писем от руборда) + автоматической генерации страниц топиков из полученных писем.

Чего мне не хватает — возможности формировать посты. То есть хотелось бы, чтобы клиент мог временно хранить содержимое ответов в несколько топиков, каковые ответы я набиваю в оффлайне. При подключении к инету или по заданному расписанию (sic!) происходит синхронизация: клиент посылает серверу форума http-запрос, эмулирующий заход в топик и отправку ответа. Мне кажется, это вполне реализуемо, если отследить сниффером обычный трафик «браузер—форум» и проанализировать его. Для этого тоже не нужно ничего менять на стороне сервера.

По поводу базы — я бы предпочёл творение Miсrosoft. Как администратор и пользователь, далёкий от программирования, я считаю, что нужно всячески избегать решений от третьих фирм, если есть работающие программы от MS. Это моя личная точка зрения и я её никому не навязываю.

готов быть бета-тестером клиента

Felix

Цитата:

Я так понял, что пользователь формирует запрос на просмотр интересующих его тем,

так точно

Цитата:

дальше клиентская часть остылает его на наш любимый форум

именно

Цитата:

и, соответственно, с MySQL сервака, который обслуживает IconBoard, данные заносятся в локальную базу и "делай с ним, что хошь..."

вот это уже не совсем так. Не важно, какой тут сервак обслуживает IB, важно - что данные на выдачу формируют те же скрипты, что и генерят страницы для броузеров.


batva

Цитата:

я не совсем понимаю, как это будет работать.
Плииз объясни, как будет идти наполнение базы.
Сразу все, или по ходу хождения по топикам?

Наполнение локальной базы идет постепенно, в нее вносятся сообщения только тех тем, которые юзер запрашивает.

---

Вообще, есть темка в разделе по Ikonboard v.2:
http://forum.ru-board.com/topic.cgi?forum=21&bm=1&topic=2144&start=40#lt
в ней подробно обсуждается и разрабатывается сам клиент. Администрацию мы еще не думали ставить в известность, так как процент сделанного минимальный, но раз уж на то пошло, расскажу вкратце суть задумки (хоть и оффтоп, но полезно ):

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

Со стороны сервера нужно:
а) Сама база сообщений - чтоб её не дублировать, рационально использовать существующую базу
б) скрипты, выдающие эту базу по запросу в определенном формате. Эти скрипты уже написаны, вернее переписаны , Svarga подправил существующие
topic.cgi и forums.cgi, так, что с параметром client=1 в запросе (если параметр client=1 отсутствует, то они выдадут всё как обычно) данные выдаются в таком виде:


Цитата:

имя_юзера|аватар|статус|дом_страница мыло aim icq#|кол-во_постов|дата_регистрации|подпись
имя_юзера|... /* и т. д. со всеми остальными постившими */

№темы|название_темы|описание|состояние_темы|количество_постов|автор|дата_первого_поста|автор_последнего_поста|дата_последнего_поста

дата_редактирования_файла_с_постами

имя_юзера|текст_поста|дата_поста|показывать_подпись|показывать_смайлики
имя_юзера|.... /* и т. д. со всеми остальными постами */

лежит это все вот здесь: http://forall.ru-board.com/Svarga/ib/cl_scripts.rar и для первых нужд работает.

---

короче, можно говорить сколько угодно, скажу о том, что дает нам использование клиента:
1) экономия траффика. Сообщение из двух символов, выданное скриптом для браузера, будет весить 1504 байта, выданное же этим скриптом для клиента - порядка 20-30 байт.
2) Увеличение скорости. Пусть даже клиент будет генерить точно такуе же страницу, какую выдает скрипт браузер. Вся фишка в том, что эта страница будет создаваться локально.
3) Уменьшение нагрузки на сервер, тоже ясно почему
4) Удобство работы
5) Возможность работы в оффлайне (чтение, подготовка сообщений и проч.)


Вот и хочется спросить уважаемую администрацию (ну сил терпеть уже нету ), как она к этому делу относится?

---

А вообще речь-то о чем? О том, что надо выбрать БД, для хранения сообщений локально, которые туда пихает сам клиент то же локально ,которые он берет от скриптов.
Спасибо за внимание

Вот теперь ситуация более или менее ясна....

Поковырял тут интернет и нашёл информацию о встраиваемых СУБД, может кто из народа работал с такими зверьми.... и подскажет свои впечатления.

Гм..
Учитывая требования к приложению (без админ части) не рассматривалась ли возможность прикрутить стандартный клиент новостей для решения этой задачи? Решение для сервера остается приблизительно тем же (набор скриптов). Для клиента нужен локальный сервер который будет транслировать вызовы nntp протокола в вызовы скриптов на форуме.
База и клиент - любой из существующих. У такого решения достаточно много плюсов.
Вопрос подходит ли это для решения задачи?

выбор сделан:
mySQL + ZeosLib
Есть вопросик:
список сообщений данной темы
на каждую тему у меня отдельная таблица, это нормально, что таблиц в одной базе может быть 225086 (число тем на данный момент на форуме)? - ничего там не откажет? кто мускл знает?. Так вот структура таблицы следующая:
поле name - тип varchar длина 20 - имя юзера
поле mes - тип blob - само сообщение
поле dat - тиП int - дата в формате, передаваемом скриптом
и поле numb - тип int - это типа счетчик
что добавить/исправить надо?

Хорошо, что наконец-то определились...

Цитата:

на каждую тему у меня отдельная таблица, это нормально, что таблиц в одной базе может быть 225086

Это на самом деле не нормально, это неправильная организация БД. Если есть силы, то надо отталкиваться от структуры БД IconBoard, благо в установочных файлах она прозрачно описана.

Smog
Создавать под каждую тему свою таблицу - это неверный подход. Просто добавь поле - thread_id и выбирай сообщения данной темы. Дополнительно нужна еще таблица threads с форматом - thread_id thread_name.

Цитата:

выбор сделан:
mySQL + ZeosLib

а почему не Firebird(embedded) ?