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

← →
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.
К сожалению, вижу, что время доступа к БД значительно больше, чем к текстовым файлам.

← →
Sergey13 © (2005-05-20 12:25) [29]

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

← →
Sergey13 © (2005-05-20 12:32) [30]

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

← →
Bronco © (2005-05-20 12:33) [31]

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

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

← →
Anatoly Podgoretsky © (2005-05-20 12:34) [32]

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

← →
Alexander Panov © (2005-05-20 13:30) [33]

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

← →
VMcL © (2005-05-20 14:25) [34]

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

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

← →
Alexander Panov © (2005-05-20 14:26) [35]

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

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

← →
Danilka © (2005-05-20 14:35) [36]

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

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

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

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

← →
Anatoly Podgoretsky © (2005-05-20 14:44) [37]

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

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

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

← →
Romkin © (2005-05-20 15:10) [38]

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

← →
Alexander Panov © (2005-05-20 15:18) [39]

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

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

← →
Romkin © (2005-05-20 16:07) [40]

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

← →
Alexander Panov © (2005-05-20 16:25) [41]

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

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

← →
Zacho © (2005-05-22 19:59) [42]

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

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

← →
Zacho © (2005-05-22 20:01) [43]

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

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

← →
Alexander Panov © (2005-05-22 20:23) [44]

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

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

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

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

← →
Zacho © (2005-05-22 20:29) [45]

Небльшое дополнение к посту [45]

Ты говорил, что, в частности, в Magic Forum тебя не устраивает скорость.
Но, имхо, если сделать клиент, способный работать с любыми хранилищами данных (или даже только с приведёнными тобой), то его быстродействие будет ещё ниже, чем у MF. Даже при самом грамотном проектировании.
Вот мне и стало интересно, зачем "универсальность" для такой узкой задачи, как клиент форума.

>[46] Zacho © (22.05.05 20:42)
Вот мне и стало интересно, зачем "универсальность" для такой узкой задачи, как клиент форума.

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

Еще про скорость.

Время доступа к данным(по увеличению):
1. Текстовые файлы.
2. Файловые базы данных(файл - одна таблица, мало записей).
3. Полноценные СУБД.

Alexander Panov © (23.05.05 9:55) [47]
я хочу открыть код и предоставить всем желающим переселиться на ту БД, которая им нравится.

Хорошая идея. Делай скорее :)

> Еще про скорость.

На самом деле, пункт 1 следовало бы перенести в конец списка :) Потому что обычно критично время доступа к конкретным данным, а здесь без индексов никак :) Конечно, можно написать свой движок для работы с текстовыми файлами, но зачем, если всё что надо, уже сделано в СУБД.

/offtop
P.S. Напомните, пожалуйста, как расшифровывается HAL. Почему-то самостоятельно не смог найти :( Наверное, совсем поглупел :( Подозреваю, что Hardware Abstract Level, но так же подозреваю, что ошибаюсь :)

Подход требует создания виртуального Dataset, например ClientDataset и наверно своего интерпритатора, аналогичного тому, который используется в BDE.

Alexander Panov © (23.05.05 09:55) [47] Вот уж не факт :)
Где ты такое сравнение видел? Может, просто чтение одной таблицы или файла - так и есть, но вот что посложнее - ой!
И, кстати, написать приложение, которое работает хотя бы с двумя БД и делает это быстро - очень нетривиально. Скажем так, приемлемых вариантов я просто не видел :)))
И не вижу я надобности в возможности присоединения к разным БД, достаточно экспорта.

[50] Romkin © (23.05.05 10:41)
> И, кстати, написать приложение, которое работает хотя бы
> с двумя БД и делает это быстро - очень нетривиально.

Думаю, для данной задачи - вполне. Например, использовать DBExpress или ADO, и разный набор запросов (для каждой СУБД - свой, оптимальный для нее) на запись веток/постов, извлечение данных и т.д.

2[47] Alexander Panov © (23.05.05 09:55)
>Время доступа к данным(по увеличению):
Если бы это было так, то "полноценные" БД таковыми бы (полноценными) не считались. 8-)
А скорость доступа к локальным данным вообще критична в такого рода прогах? ИМХО, тут узким местом должна являться собственно закачка.

> [47] Alexander Panov © (23.05.05 09:55)
Идея хороша, но... все-таки лучшее враг хорошего. Нужна ли такая универсальность для данной задачи?
Самое простое : придется отказываться от ряда преимуществ - тех же самых ХП, как минимум. Те же генераторы и идентити, разные виды блокировок у разных серверов?
Следует полагаться на средства используемого сервера все-таки. Раз код открываете для программистов, а не для домохозяек, то сервер ими используемый им же можно и подучить.

SQlite
dll - 200 кб

[53] Val © (23.05.05 11:07)
> тех же самых ХП, как минимум

Почему?

> Те же генераторы и идентити, разные виды блокировок у разных
> серверов?

Разные блокировки для клиента? Зачем? Запись в базу только одной процедурой - когда закачиваем из инета ветку или список веток. Все остальное - только чтение, можно даже однонаправленный курсор в случае с веб-интерфейсом.
Генераторы/идентити тоже никто не запрещает использовать. Не забывай про специфику - ид веток должны быть такие-же какие их отдает клиентский скрипт, ид постов - бога ради, делай хоть идентитей, хоть генератором, хоть сиквенсом, ежели сделать так как я в [51] написал.

>[55] Danilka © (23.05.05 15:25)

> Почему?

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

> Разные блокировки для клиента?

При однопользовательском доступе на них, естественно можно наплевать, поскольку их не будет, но...суть в том, что, опять же - сервера используют РАЗНЫЕ виды блокировок.

> Генераторы/идентити тоже никто не запрещает использовать.

Никто не говорил, что их запрещают использовать - ОНИ РАБОТАЮТ ПО-РАЗНОМУ.
Суть моего поста сводилась к тому что нельзя писать хорошую программу для работы с БД не опираясь на конкретную СУБД. Привел лишь первые попавшиеся примеры явных различий.
Зачем мне ЧУЖОЙ код, который мне придется разбирать, а затем лопатить как на клиенте так и на сервере? Врядли кто-то от этого удовольствие получает.

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

[56] Val © (23.05.05 15:50)
Просто ты меня не понял. Общее - только средство доступа, например АДО или ДБЭкспресс. Но разными серверами и будет работать по-разному, если для каждого использовать свой набор запросов. А там - используй на здоровье что угодно: ХП, сиквенсы и т.д.
Управлять блокировками - а зачем это надо для клиента форума?
Специфика работы здесь такая: Зашел на форум, при этом из инета забираются информация по веткам форума, далее она пишется в базу - генературы не нужны, т.к. ключевое поле ИД ветки передается клиентским скриптом.
После записи в базу выполняется запрос (можно однонаправленный), который всегда один и тот-же: вернуть энное кол-во веток данного форума, для выбраной страницы.
Далее, заходим в какую-нибудь ветку - опять из инета вытагиваем последние посты этой ветки и пишем их в базу. При этом, если не хочется в качестве ПК составной ключ из номера ветки и номера поста, бога ради, пущщай будет генератор, или сиквенс, или автоинкремент, ибо это не грид какой-нибудь и получать при вставке новый ИД нет необходимости.
После будет запрос к базе на выборку всех постов данной ветки.

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

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

Из обсуждения я понял, что можно использовать неплохо любую настольную БД, поддерживающую SQL.
Кроме этого, для тех, у кого уже есть предустановленные СУБД, предпочтительнее зачастую их использовать, хотя они согласны и установить новый движок.

Спасибо всем.

ADO/BDE - Access/dBase IV
Другие из настольных использовать не стоит.

Anatoly Podgoretsky © (24.05.05 10:51) [60]

А как насчет FB Embedded?

DBase - это вряд ли.

Access - никогда не работал. Но когда-то надо начинать?-)

А из полноценных СУБД буду ориентироваться на IB, MSSQL, Oracle(если руки дойдут).

Пока же - текст-)

По поводу FB Embedded.

Ну как-то не могу я пока доверть этому движку.

Кто-нибудь работал с большими объемами записей - порядка 1-2 миллионов в режиме интенсивного обмена(удаление/вставка/обновление) достаточно проджолжительное время?

Alexander Panov © (24.05.05 10:57) [61]
А как насчет FB Embedded?

А это уже не является десктопной базой.

Для клиент серверной технологии, я бы ограничился
FB/IB любые, MSSQL любые, Oracle

По поводу Акцесс, Микрософт вместо него продвигает MSSQL (MSDE), сам Акцесс предлагается искользовать как фронт-энд, тоже относится и к ФоксПро, нас этот случай не интересует.

Если уйти от прямой работы с таблицами в сторону интерфейсов (набор функций класса GetForums, GetMessageList, GetMessage, GetMessageList, etc), то без разницы где и как хранятся данные, интерфейс общения единый, абстрагированый.

Alexander Panov © (24.05.05 10:58) [62]
Ну как-то не могу я пока доверть этому движку.

А зря. Он ничем не отличается от полноценного FB.

Кто-нибудь работал с большими объемами записей - порядка 1-2 миллионов в режиме интенсивного

Работал. БД около 2-х Гб, есть таблицы с миллионами записей, всё работает довольно шустро.

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