Структура хранения данных для клинета форумов.

← →
Alexander Panov © (2005-05-19 17:32) [0]

Может ли кто предложить вариант хранения информации для форумов сайта "Мастера Delphi".
Все реализованные решения клиентских программ на сегодняшний день не лишены недостатков.

1. DMClient.

Вся информация хранится в текстовых файлах.

Плюсы:
+ Не привязан к какому-либо движку БД.
+ Информация доступна для просмотра обычными редакторами
+ Надежность сохранности данных.
Минусы:
- Огромное количество текстовых файлов
- Сложность реализации алгоритма индексирования и поиска.

2. Dolphin

Вся информация хранится в БД MSSQL или MSAccess.

Плюсы:
+ Высокая скорость доступа к данным и поиска.
+ Надежность сохранности данных(в случае MSSQL).
Минусы:
- Необходимо наличие движка СУБД.
- Нет возможности просмотра текстовых файлов

3. Magic Forum

Вся информация хранится в БД FireBird Embedded.

Плюсы:
+ Высокая скорость доступа к данным и поиска.
+ Нет необходимости предустановленной СУБД.
Минусы:
- Необходимо наличие дополнительных DLL с движком БД.
- БД не находится в состояни готовности по первому запросу.
- Нет возможности просмотра текстовых файлов
---------------------------------------------------------

Хотелось бы структурировать информацию подобно DMClient(в текстовых файлах), но количество файлов уменьшить до минимума.

← →
Ega23 © (2005-05-19 17:35) [1]

Одних плюсов без минусов не бывает.
ИМХО, 3-й вариант - наиболее удобный. Можно, кстати, совместить 1 и 3.

← →
Alexander Panov © (2005-05-19 17:45) [2]

Ega23 © (19.05.05 17:35) [1]
ИМХО, 3-й вариант - наиболее удобный.

Почему мне не нравится такой вариант:

1. Для постоянной готовности движка к работе необходимо периодически "поддергивать БД" - выполнять фиктивные запросы к базе, для того, чтобы библиотеки и данные не были вытеснены системой на диск.
2. при повреждении файла с БД информация будет потеряна вся.

← →
Alexander Panov © (2005-05-19 17:46) [3]

Ega23 © (19.05.05 17:35) [1]

А какие варианты совмещения?

← →
Ega23 © (2005-05-19 17:59) [4]

2 Alexander Panov © (19.05.05 17:46) [3]
А какие варианты совмещения?

Ну, к примеру, кольцевой буфер на N последних сообщений в текстовом файле.

Во, XML как вариант.
Кстати, насколько я понял, Кузнецов курирует наш Open Source проект Sedna (СУБД на основе XML). Вроде даже успешный проект.

← →
Alexander Panov © (2005-05-19 18:04) [5]

Ega23 © (19.05.05 17:59) [4]

Судя по тому, какова скорость работы с XML и объем дополнительной информации для хранения данных, для большгих объемов XML не подойдет.

← →
Ega23 © (2005-05-19 18:08) [6]

2 Alexander Panov © (19.05.05 18:04) [5]

Саш, тогда сформулируй требования.
Типа, объём базы - такой-то, производительность - такая-то.
Данные, в конце-концов, можно архивировать.

← →
Alexander Panov © (2005-05-19 18:15) [7]

Ega23 © (19.05.05 18:08) [6]

Объем - от 100Мб и выше.

← →
Polevi © (2005-05-19 18:17) [8]

MS Access

← →
Alexander Panov © (2005-05-19 18:19) [9]

Polevi © (19.05.05 18:17) [8]
MS Access

Опять же из опыта работы с одной из банковских программ, использующих Бд Access - падает она иногда... жестоко падает.

← →
Polevi © (2005-05-19 18:49) [10]

>Alexander Panov © (19.05.05 18:19) [9]
я тоже знаком с некоторыми "банковскими программами"
что там только не падает

← →
Alexander Panov © (2005-05-19 18:57) [11]

Polevi © (19.05.05 18:49) [10]

При сбоях(снятие процесса, отключение питания) иногда портится структура БД.

← →
Polevi © (2005-05-19 19:02) [12]

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

← →
Alexander Panov © (2005-05-19 19:06) [13]

Polevi © (19.05.05 19:02) [12]

А как MSAccess по скорости при больших объемах?

← →
Polevi © (2005-05-19 19:31) [14]

для данной задачи хватит, с учетом того что база локальная

← →
Petr V. Abramov © (2005-05-20 00:53) [15]

Alexander Panov © (19.05.05 17:32)
> Минусы:
> - Необходимо наличие дополнительных DLL с движком БД.
1-2 халявных DLL? Решается наличием инсталлятора :)
> - БД не находится в состояни готовности по первому запросу.
Растолкуй
> - Нет возможности просмотра текстовых файлов
Проблемы приложения, а не БД. Можно и на Oracle такой приложение создать. "А если сунешь четвертак, то он сыграет и не так" :)

← →
Anatoly Podgoretsky © (2005-05-20 08:57) [16]

2. Dolphin
Плюсы:
Минусы:
- Необходимо наличие движка СУБД.
Чем отличие от FB, в обеих случаях нужен движок. Инсталяция сводится к двойному щелчку по MDAC.EXE

3. Magic Forum
Плюсы:
+ Нет необходимости предустановленной СУБД.

Это как? Чем отличие от MSSQL?
Предустановленая СУБД нужна в обеих случаях. Инсталяция делает запуском простого BAT файла. Смотри примеры развертывания MSDE и баз данных Nortwith и Pubs. Все что поставляетя это дистрибутив MSDE и набор скриптов.

Минусы:
- Необходимо наличие дополнительных DLL с движком БД.
Это требование относится к обеим базам.
- БД не находится в состояни готовности по первому запросу.
Это не понятно
- Нет возможности просмотра текстовых файлов
Непонятно это еще зачем, аттачи в форуме отсутствуют. Разъясни этот пункт, но это относится к очень простым функциям на клиентской стороне, или ты про экспорт/импорт данных MSSQL это делает очень хорошо, думаю и FB не хуже.

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

Достоинство MSDE может являть то что фронт эндом может являться Акцесс и даже тестовые примеры из Дельфи.

← →
Danilka © (2005-05-20 09:56) [17]

- Нет возможности просмотра текстовых файлов
А шо это за зверь? :)
Еще один плюс забыл у последних двух:
+ Возможность залезть в базу и попросить на сиквеле все что захочецца: статистику, сложный поиск и т.д.

← →
Anatoly Podgoretsky © (2005-05-20 09:57) [18]

Danilka © (20.05.05 09:56) [17]
Full Tesxt Search

← →
Bronco © (2005-05-20 10:11) [19]

>
> Хотелось бы структурировать информацию подобно DMClient(в
> текстовых файлах), но количество файлов уменьшить до минимума.

ИМХО, если нужно кол-во файлов уменьшить до минимума, то либо FB EMBedded либо Yaffil Personal.
Всего два файла - gds32.dll + сам файл БД в той же директории.
По структуре таблиц сказать ничего не могу, но подозреваю что можно по большому счету обойтись двумя :-)

← →
Sergey13 © (2005-05-20 10:21) [20]

DBF+встроеный движок типа Хальциона.
+
Средств "просто просмотра" чуть меньше чем для текста.
Все таки Бд.
Никаких "лишних" файлов.

← →
Bronco © (2005-05-20 10:27) [21]

> Sergey13 © (20.05.05 10:21) [20]

Я тоже сначала хотел предложить DBF с компонентами прямого доступа. Но так вроде файлов больше получится, а Панову меньше надо :-) Да и SQL в Хальсионе отсутствует, что тоже неудобно.

← →
Sergey13 © (2005-05-20 10:30) [22]

2[21] Bronco © (20.05.05 10:27)
>Но так вроде файлов больше получится
Почему? Я предполагал, что все ТХТ-шники лягут в МЕМО поля одного файла.

← →
Alexander Panov © (2005-05-20 11:46) [23]

[16] Anatoly Podgoretsky © (20.05.05 08:57)
3. Magic Forum
Плюсы:
+ Нет необходимости предустановленной СУБД.

Это как? Чем отличие от MSSQL?

Для работы FB Embedded нет необходимости устанавливать отдельно СУБД, как с MSSQL.

Предустановленая СУБД нужна в обеих случаях. Инсталяция делает запуском простого BAT файла. Смотри примеры развертывания MSDE и баз данных Nortwith и Pubs. Все что поставляетя это дистрибутив MSDE и набор скриптов.

Многих(в том числе и для меня) установка дополнительных средств в систему не очень радует.

- БД не находится в состояни готовности по первому запросу.
Это не понятно

В случае FB Embedded время отклика от базы зависит от того, давно ли было последнее обращение к базе. В случае, если обращений давно не было, необходимые библиотеки, сама база вытесняются из памяти. Следовательно, для первого обращения после перерыва в использовании время отклика резко увеличивается.

- Нет возможности просмотра текстовых файлов
Это я неправильно сформулировал.
имелось ввиду - "Нельзя содержимое веток и постингов посмотреть обычным текстовым редактором"

Разъясни этот пункт, но это относится к очень простым функциям на клиентской стороне, или ты про экспорт/импорт данных MSSQL это делает очень хорошо, думаю и FB не хуже.
В случае с DMClient промежуточный этап экспорта отсутствует - информация доступна сразу.

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

Достоинство MSDE может являть то что фронт эндом может являться Акцесс и даже тестовые примеры из Дельфи.

Об этом уже выше упоминал, что не всегда приятно устанавливать дополнительные программы, кроме необходимого минимума.

[17] Danilka © (20.05.05 09:56)
Еще один плюс забыл у последних двух:
+ Возможность залезть в базу и попросить на сиквеле все что захочецца: статистику, сложный поиск и т.д.

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

[19] Bronco © (20.05.05 10:11)

ИМХО, если нужно кол-во файлов уменьшить до минимума, то либо FB EMBedded либо Yaffil Personal.
Всего два файла - gds32.dll + сам файл БД в той же директории.
По структуре таблиц сказать ничего не могу, но подозреваю что можно по большому счету обойтись двумя :-)

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

[20] Sergey13 © (20.05.05 10:21)
DBF+встроеный движок типа Хальциона.
+
Средств "просто просмотра" чуть меньше чем для текста.
Все таки Бд.
Никаких "лишних" файлов.

От DBF думаю отказаться сразу, так как работа с неродным движком(например, FoxPro 2.6) не вызывает удовольствия из-за скорости, да и объемы данных для DBF великоваты.
Кроме этого, пока не знаю движков для DBF с полноценным SQL.

← →
Sergey13 © (2005-05-20 11:58) [24]

2 [23] Alexander Panov © (20.05.05 11:46)
А зачем вообще все это? Пишется новый клиент или это "для внутреннего пользования"? Или еще чего?
Я к тому, что для локальной проги/БД с несложной структурой SQL вобщемто не ахти как и нужен. ИМХО.

← →
Alexander Panov © (2005-05-20 12:08) [25]

>[24] Sergey13 © (20.05.05 11:58)
А зачем вообще все это? Пишется новый клиент или это "для внутреннего пользования"? Или еще чего?
Я к тому, что для локальной проги/БД с несложной структурой SQL вобщемто не ахти как и нужен. ИМХО.

Пишу своего клиента-)

← →
Alexander Panov © (2005-05-20 12:11) [26]

А объемы - текущее состояние форума ~7000 файлов только с ветками форума ~19Мб размером.
А если экспортировать данные из моих архивов, то объем вырастет в десяток раз.

← →
Sergey13 © (2005-05-20 12:18) [27]

2[25] Alexander Panov © (20.05.05 12:08)
>Пишу своего клиента-)
Тогда, ИМХО, наличие пары ДЛЛ-к никого из потенциальных пользователей не смутит. Для непонятливых (в смысле сложности установки) сужествуют браузеры, для других проблем нет.
Тогда мое предложение ФБ.
Кстати, недавно видел ссылку на http://www.delphiplus.org/

Fikret Hasovic: Выложена юнита для встраивания в программу на Delphi embedded версии СУБД Firebird (source, demo).

Я не смотрел, но может и полезное что.

← →
Alexander Panov © (2005-05-20 12:22) [28]

Тогда мое предложение ФБ.

В MagicForum используется FB Emdedded.
К сожалению, вижу, что время доступа к БД значительно больше, чем к текстовым файлам.

2[28] Alexander Panov © (20.05.05 12:22)
Я ничего не имею против этой проги (не юзал), но смею предположить, что это трудности этой конкретной проги, а не FB Emdedded.
Я и Оракла на колени ставил. 8-)

В догонку. Никто ведь не настаивает именно на Emdedded. Если прога работает постоянно (а таких не мало 8-), то почему не использовать нормальный сервер?

> Sergey13 © (20.05.05 12:25) [29]

Полностью согласен.
Правда сам использую Yaffil Personal, но разница между ними небольшая. Скорость доступа при наличии необходимых индексов, а так же правильном размере страницы - очень высокая.
Скажу даже больше. Объем моей базы - 12 Гб, при этом настроил все так, что летает пулей.
Так что вопросы по низкой скорости нужно задать Piter-у.

Спасибо всем.
Пока для удобства и скорости разработки ограничусь реализацией интерфеса к текстовым файлам.
После отладки перейду к реализации доступа к имеющимся БД - MSSQL, FB, Fb Embedded, MS Access.
MSDE пока не устанавливал, но думаю, что надо попробовать будет.

>>Alexander Panov © (20.05.05 13:30) [33]

Могу ошибаться, но у MSDE, вроде, есть ограничение на суммарный размер данных строки при INSERT/UPDATE.

Могу ошибаться, но у MSDE, вроде, есть ограничение на суммарный размер данных строки при INSERT/UPDATE.

Ну с MSDE я буду в последнюю очередь разбираться-)

[33] Alexander Panov © (20.05.05 13:30)
> Пока для удобства и скорости разработки ограничусь реализацией
> интерфеса к текстовым файлам.

хм. А в чем именно будет ускорение? По-моему наоборот - придецца придумывать какой-то свой механизм индексирования.. Куда проще - при получении данных один раз распарсить их, а дальше все в базу разложить по своим полям: сюда ник, сюда дату/время, сюда текст сообщения и т.д.

[23] Alexander Panov © (20.05.05 11:46)
> Получение статистики можно реализовать и в самой программе,
> для этого необязательно иметь полноценную СУБД(прицины уже
> написал выше).

С базой я могу сделать что угодно, мало-ли что мне захочецца? :)
Например, сегодня я захочу посмотреть у кого больше постов в "базах", завтра - список всех, кто употребил слово "террористы" отсортированый по дате сообщения, затем, по кол-ву постов с этим словом, послезавтра еще чего-нибудь. :) С текстом или жестко прописанными правилами на клиенте такого уже не сделаешь.

VMcL © (20.05.05 14:25) [34]
Есть как на размер строки выдачи - 8060, так и на размер строкового поля 4000/8000

АДО позволяет работать с этим полем именно как со строкой, а не мемо полем.

Если говорить о клиенте форумов, то длина сообщения ограничена 5000 символов, тема и того меньше. В сумме в 8060 входит и еще остается. Если по какой то причине нужно больше, а такую причину я здесь вижу, то использовать поле типа Мемо, называется ntext, размер до 2 гб

Я бы делал на FB embedded. Тут все уже сказано: стандартный инструмент, не требующий установки. И есть все преимущества полноценного сервера. Насчет вытеснения - всегда можно поставить сервер, если скорость не устраивает, систему уж точно не корежит :)
Плюс - легче гораздо делать и поиск, и работать. Ну не приспособлена Delphi к работе с текстовыми файлами!
Скорость - действительно, это зависит от того, как сделано. MagicForum не видел, так что ничего насчет производительности сказать не могу... Могу сказать, что все очень зависит от структуры БД.
Плюс - возможность работать с БД напрямую, при желании. А закрытые форматы - да ну их!
И, кстати, в этом случае я бы делал покомпонентно - один компонент качает данные, второй - обеспечивает интерфейс.

И, кстати, в этом случае я бы делал покомпонентно - один компонент качает данные, второй - обеспечивает интерфейс.

Так и будет - для того, чтобы не привязываться к форматам хранения данных и к СУБД.-)

Хм... Я бы наоборот, взял бы как хранилище FB, и уже к нему цеплял бы интерфейсы, в том числе и экспорта/импорта. НА мой взгляд, и проще, и легче :)

Структура хранения данных для клинета форумов. Найти похожие ветки