Мастера 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(в текстовых файлах), но количество файлов уменьшить до минимума.

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

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

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

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

Anatoly Podgoretsky (2005-05-24 11:06:00) [2]
Alexander Panov © (24.05.05 10:57) [61]
А как насчет FB Embedded?

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

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

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

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

Alexander Panov (2005-05-24 10:58:00) [3]
По поводу FB Embedded.

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

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

Alexander Panov (2005-05-24 10:57:00) [4]
Anatoly Podgoretsky © (24.05.05 10:51) [60]

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

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

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

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

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

Anatoly Podgoretsky (2005-05-24 10:51:00) [5]
ADO/BDE - Access/dBase IV
Другие из настольных использовать не стоит.

Alexander Panov (2005-05-24 10:27:00) [6]
Все-таки буду интерфейс работы с базой отделять.
Пользователь должен иметь возможность выбрать - какую СУБД использовать.

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

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

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

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

Val (2005-05-23 15:54:00) [8]
Иначе, блин, увидите такое чудо без пк. Это БД по вашему - можно о скоростях каких-то говорить? Сервер не для того же используется чтоб весь мусор в одном файле хранить.

Val (2005-05-23 15:50:00) [9]
>[55] Danilka © (23.05.05 15:25)

> Почему?

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

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

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

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

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

Danilka (2005-05-23 15:25:00) [10]
[53] Val © (23.05.05 11:07)
> тех же самых ХП, как минимум

Почему?

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

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

Андрей Жук (2005-05-23 15:11:00) [11]
SQlite
dll - 200 кб

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

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

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

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

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

Anatoly Podgoretsky (2005-05-23 10:34:00) [16]
Подход требует создания виртуального Dataset, например ClientDataset и наверно своего интерпритатора, аналогичного тому, который используется в BDE.

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

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

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

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

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

Alexander Panov (2005-05-23 09:55:00) [18]
>[46] Zacho © (22.05.05 20:42)
Вот мне и стало интересно, зачем "универсальность" для такой узкой задачи, как клиент форума.

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

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

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

Zacho (2005-05-22 20:42:00) [19]
Небльшое дополнение к посту [45]

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

Zacho (2005-05-22 20:29:00) [20]
Alexander Panov © (22.05.05 20:23) [44]

Конечно, согласен.

Мне было интересно, зачем в этом конкретном случае ?

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

Наверх

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