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

← →
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]

Alexander Panov © (22.05.05 20:23) [44]

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

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

← →
Zacho © (2005-05-22 20:42) [46]

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

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

← →
Alexander Panov © (2005-05-23 09:55) [47]

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

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

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

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

← →
Zacho © (2005-05-23 10:21) [48]

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

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

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

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

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

← →
Anatoly Podgoretsky © (2005-05-23 10:34) [49]

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

← →
Romkin © (2005-05-23 10:41) [50]

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

← →
Danilka © (2005-05-23 10:47) [51]

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

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

← →
Sergey13 © (2005-05-23 10:52) [52]

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

← →
Val © (2005-05-23 11:07) [53]

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

← →
Андрей Жук © (2005-05-23 15:11) [54]

SQlite
dll - 200 кб

← →
Danilka © (2005-05-23 15:25) [55]

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

Почему?

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

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

← →
Val © (2005-05-23 15:50) [56]

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

> Почему?

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

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

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

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

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

← →
Val © (2005-05-23 15:54) [57]

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

[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-х Гб, есть таблицы с миллионами записей, всё работает довольно шустро.

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