Помогите с выбором БД, способа доступа и вообще с проектированием..

  • Автор темы vital
  • Дата начала
V

vital

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

Из-за, скажем так, причуд заказчика поставить бд на один сервер в нете(локалки нет и быть не может) и потом просто юзверей подключать как клиентов к этой бд - нельзя. Соответственно на каждую юзверевскую машину нужно ставить серверную часть бд. Вот отсюда требования=>проблемы

Инсталляция должна быть уровня "домохозяйка".
Как можно меньший размер дистрибутива.
Не большое сжирание траффика.

Должен быть простой способ синхронизации.(Пока все что придумал - это делать SQL дамп базы а потом просто этот файл рассылать юзверям по мылу, которые этот файл посредством чего-то уже мной написанного и выполнят)
Предполагается 2-3 таблицы. Записей будет тоже не много, я думаю не больше тысяч 20. Запросы к бд тоже сложными не будут. (Тут подходит все подряд..)

По поводу способа доступа. Очень хочется использовать BDE ибо просто и умею. Но опять же - нужно его каждому юзверю инсталлировать. ВЛОМ мне писать лишний код, да и хз как правильнее это сделать. С ADO я не общался, отправьте плиз на документ где написано как и с чем его едят. И еще момент.. Потом, на какой-то стадии нужно будет нек-ые данные из этой(этих??) бд экспортировать в другую базу на MySQL.

Проще всего, конечно, заставить всех себе поставить MySQl, но блин.. это извращенство. Может есть выход по-изящнее?
И последнее. С БД по жизни я общаюсь не часто, просьба ногами в голову не бить если что..
 
S

Silver Wind

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

А по сути если нужен будет экспорт в MySQL, то, имхо, на MySQL и делай. Компонент для работы с MySQL без BDE хватает. Инсталлируется тоже просто, размер инсталляшки для версии 3.23 ~9М, а больше тебе для подобной задачи и не надо.
 
O

onyx

Есть такая локальная база данных - VolgaDB. Отличное решение для мелких проектов, работает очень быстро, код на Дельфи, не требеут ADO, ODBC, BDE и т.п. Имеет свои компоненты, совместимые с TTable и т.д.

Официальный сайт здесь:

Ранее это был shareware продукт, а сейчас он под GPL и поставляется со всеми исходниками.

Кстати - это на сегодняшний день единственная локальная база для Kylix/Linux которая работает без всяких прыжков с бубном в ввиде настроек драйверов, да и вообще под Linux нет толком локальных баз данных).

Были сравнения на производительность данной базы данных со стандартными типа BDE+Paradox, BDE+DBase, ADO+MS Access. На небольших таблицах (до сотни тысяч записей) Volga DB существенно обгоняет все остальные системы.
 
O

onyx

Сам юзал. Если нужен код могу поомочь...
 
E

European

<!--QuoteBegin-Silver Wind+28:10:2007, 15:41 -->
<span class="vbquote">(Silver Wind @ 28:10:2007, 15:41 )</span><!--QuoteEBegin-->Какие извращенцы такие задания дают.
[snapback]83323" rel="nofollow" target="_blank[/snapback]​
[/quote]
Не такое уж и ненормальное задание. Думаешь клиенты очень заботятся о красоте архитектуры?<!--QuoteBegin-Silver Wind+28:10:2007, 15:41 -->
<span class="vbquote">(Silver Wind @ 28:10:2007, 15:41 )</span><!--QuoteEBegin-->Может всетаки убедить клиента что он неправ?
[snapback]83323" rel="nofollow" target="_blank[/snapback]​
[/quote]
Клиент всегда прав...<!--QuoteBegin-vital+28:10:2007, 00:48 -->
<span class="vbquote">(vital @ 28:10:2007, 00:48 )</span><!--QuoteEBegin-->Должен быть простой способ синхронизации.
[snapback]83304" rel="nofollow" target="_blank[/snapback]​
[/quote]
Основная проблема при такой синхронизации - изменение пользователями одной записи. Конфликты можно решать 2 способами: автоматическим, при этом каждому пользователю может быть назначен некоторый приоритет, и ручным, при этом желательно написать дополнительную утилитку, которая будет показывать данные до изменения и изменения каждого пользователя.
Далее... После того как все пользователи прислали свои изменения, кто-то, назовем его оператор, должен все данные принять в свою базу, а только после разослать клиентам изменения. Следовательно, с момента отправки пользователем изменения до получения данных от оператора, пользователь не может вносить изменения. При этом клиенты очень часто такие рас...дяи, один может обещать прислать данные неделю, а все остальные будут ждать.
<!--QuoteBegin-vital+28:10:2007, 00:48 -->
<span class="vbquote">(vital @ 28:10:2007, 00:48 )</span><!--QuoteEBegin-->Пока все что придумал - это делать SQL дамп базы а потом просто этот файл рассылать юзверям по мылу, которые этот файл посредством чего-то уже мной написанного и выполнят
[snapback]83304" rel="nofollow" target="_blank[/snapback]​
[/quote]
SQL дамп всей базы это лишнее. Делаешь в таблице дополнительное поле с датой изменения, поле заполняет триггер на добавление или изменение. По этому полю и находишь данные, измененные после последней синхронизации.
<!--QuoteBegin-vital+28:10:2007, 00:48 -->
<span class="vbquote">(vital @ 28:10:2007, 00:48 )</span><!--QuoteEBegin-->Проще всего, конечно, заставить всех себе поставить MySQl, но блин.. это извращенство
[snapback]83304" rel="nofollow" target="_blank[/snapback]​
[/quote]
Почему, что-то я не понял?

Короче, будут вопросы - пиши в Асю, поделюсь опытом <_<
 

Kmet

Well-known member
25.05.2006
904
8
BIT
0
имхо, не стоит изобретать велосипед. написать достойный механизм асинхронной репликации не так легко.
 
V

vital

2onyx
Посмотрю обязательно. Код нужен, чуть позже уже скасажу конкретно.
European
Ещё вот поговорю с "клиентом" там посмотрим.. Вопросов будет много)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!