Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 >
Alexander Panov © (2005-05-19 17:32:00)
Может ли кто предложить вариант хранения информации для форумов сайта "Мастера Delphi".
Все реализованные решения клиентских программ на сегодняшний день не лишены недостатков.

1. DMClient.

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

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

2. Dolphin

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

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

3. Magic Forum

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

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

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

Alexander Panov (2005-05-22 20:23:00) [21]

> [43] Zacho © (22.05.05 20:01)
>
> А зачем ? Имхо, если хочешь получить максимальную скорость,
> то логику работы программы надо довольно жестко привязывать
> к конкретной БД.

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

Как пример, можно привести ОС Windows.

Для работы с устройствами применяется унифицированный интерфейс.
Как пример - HAL.
При грамотном проектировании все будет работать быстро.

Zacho (2005-05-22 20:01:00) [22]
Alexander Panov © (20.05.05 16:25) [41]
Я имею ввиду, что логика работы с БД будет отделена от обработки и представления данных в программе.

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

Zacho (2005-05-22 19:59:00) [23]

>Romkin © (20.05.05 15:10) [38][Ответить]
> Скорость - действительно, это зависит от того, как
> сделано. MagicForum не видел, так что ничего насчет
> производительности сказать не могу... Могу сказать,
> что все очень зависит от структуры БД

Я видел, и могу сказать, что структура, мягко говоря, не из лучших. Даже первичных ключей нет вообще :(
При всём моём уважении к Piter'у и этому весьма достойному клиенту :)
Так что думаю, скорость можно сильно повысить перепроектированием структуры.
Впрочем, меня и текущая устраивает.

Alexander Panov (2005-05-20 16:25:00) [24]

> [40] Romkin © (20.05.05 16:07)
> Хм... Я бы наоборот, взял бы как хранилище FB, и уже к нему
> цеплял бы интерфейсы, в том числе и экспорта/импорта. НА
> мой взгляд, и проще, и легче :)

Я имею ввиду, что логика работы с БД будет отделена от обработки и представления данных в программе.

Romkin (2005-05-20 16:07:00) [25]
Хм... Я бы наоборот, взял бы как хранилище FB, и уже к нему цеплял бы интерфейсы, в том числе и экспорта/импорта. НА мой взгляд, и проще, и легче :)

Alexander Panov (2005-05-20 15:18:00) [26]
И, кстати, в этом случае я бы делал покомпонентно - один компонент качает данные, второй - обеспечивает интерфейс.

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

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

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

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

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

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

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

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

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

Alexander Panov (2005-05-20 14:26:00) [30]
Могу ошибаться, но у MSDE, вроде, есть ограничение на суммарный размер данных строки при INSERT/UPDATE.

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

VMcL (2005-05-20 14:25:00) [31]
>> Alexander Panov © (20.05.05 13:30) [33]

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

Alexander Panov (2005-05-20 13:30:00) [32]
Спасибо всем.
Пока для удобства и скорости разработки ограничусь реализацией интерфеса к текстовым файлам.
После отладки перейду к реализации доступа к имеющимся БД - MSSQL, FB, Fb Embedded, MS Access.
MSDE пока не устанавливал, но думаю, что надо попробовать будет.

Anatoly Podgoretsky (2005-05-20 12:34:00) [33]
Alexander Panov © (20.05.05 12:08) [25]
Тогда ограничиться FB/MSDE
Десктопные базы не для таких размеров.

Bronco (2005-05-20 12:33:00) [34]

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

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

Sergey13 (2005-05-20 12:32:00) [35]
В догонку. Никто ведь не настаивает именно на Emdedded. Если прога работает постоянно (а таких не мало 8-), то почему не использовать нормальный сервер?

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

Alexander Panov (2005-05-20 12:22:00) [37]
Тогда мое предложение ФБ.

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

Sergey13 (2005-05-20 12:18:00) [38]
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:11:00) [39]
А объемы - текущее состояние форума ~7000 файлов только с ветками форума ~19Мб размером.
А если экспортировать данные из моих архивов, то объем вырастет в десяток раз.

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

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

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »