Несколько экземпляров данных БД - кто как? | |
---|---|
Glyba Автор Сообщений: 386 Откуда: Собинка Дата регистрации: 23.09.2004 |
Начиная работать с VFP, я рассчитывал на то, что буду держать один экземпляр DBC и несколько наборов DBFов. Ведь контейнер всегда тот же самый, так что несколько экземпляров его держать как-то неконцептуально, а переключать расположение DBFов, видимо, будет легко. Как бы не так. Как оказалось, средства для программного изменения пути к DBFу из базы не существует. Правда, в хелпе описана структура заголовка DBFа, так что обратную ссылку на контейнер можно засунуть куда надо. А вот со ссылкой в контейнере не так просто. Хотя и идет в поставке фокса отчет 60dbcpro.frx, в котором описано содержимое поля Property, но как его формировать, там не сказано, а "метод упорного взгляда" не помог. Так и отложил я это до лучших времен, и до сих пор у меня в каждом каталоге с данными по клону DBC. И так можно жить, но все же - как это <i>следует</i> делать - у кого какие мысли?
Может быть, делать так, как это делалось бы в КС - ведь там наше будущее? И как это делается в КС? |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Vladimir Sklyar Сообщений: 1397 Дата регистрации: 13.06.2002 |
Hello, Glyba!
You wrote on Fri, 25 Feb 2005 08:09:05 +0300 (MSK): Расскажу как у меня сделано: - данные хранятся помесячно, вместе с контейнерами и полным набором баз в каждом каталоге 2004 + - 01 + - 02 .... + - 12 и т.д. по годам - в форме в DataEnveronment -> BeforeOpenTables есть такой вот код LOCAL lcDataBase IF DBUSED("db") SET DATABASE TO db CLOSE DATABASES ENDIF * открываем контейнер из нужного каталога в зависимости от рабочего период OPEN DATABASE (SSh.GetDataBase()) lcDataBase=DBC() WITH this STORE lcDataBase TO .cFaces.Database, .cPlat.Database ENDWITH вот и все, все работает на протяженни 6 лет А что такое "КС" - Клиент-Сервер ? Ну это совсем другая история. With best regards, Vladimir M Sklyar. E-mail: ''.phorum_html_encode('cservice@konotop.net').'' ------------------ С уважением Владимир. |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Glyba Автор Сообщений: 386 Откуда: Собинка Дата регистрации: 23.09.2004 |
Да у меня тоже работает такой вариант, как я и писал - по контейнеру в каждом каталоге. Так нехорошо ведь, когда он не один! Или хорошо? Вот в чем вопрос был.
|
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Combat Сообщений: 816 Откуда: Клайпеда Дата регистрации: 26.10.2000 |
И как это добро сопровождать в случае постоянного развития системы? ------------------ |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Vladimir Sklyar Сообщений: 1397 Дата регистрации: 13.06.2002 |
Hello, Combat!
You wrote on Fri, 25 Feb 2005 09:33:00 +0300 (MSK): C> И как это добро сопровождать в случае постоянного развития C> системы? Скрипт с изменениями запускаеться в каждом каталоге. PS С удовольствием выслушаю другие способы хранения данных (файл-сервер) With best regards, Vladimir M Sklyar. E-mail: ''.phorum_html_encode('cservice@konotop.net').'' ------------------ С уважением Владимир. |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Grin Сообщений: 1083 Откуда: Kiev Дата регистрации: 05.12.2000 |
У меня разделение идет таким образом
например есть три вида фондов с которыми работает пользователь при входе в систему он выбирает с каким фондом он будет работать а в формах идет банальный set filter to |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi, Glyba!
Структуру поля Property в DBC я уже расписывал: forum.foxclub.ru Вообще идею держать 50 баз одинаковой структуры я не поддерживаю - если уж объёмы так велики, стоит задуматься о SQL-сервере, если же просто не нужны "старые данные" - то раздели в рамках одной dbc (или 2-х это неважно) данные на оперативные и архив. А вообще партиционирование это сложная и неоднозначная тема - реализовывать можно по разному... ------------------ WBR, Igor |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Combat Сообщений: 816 Откуда: Клайпеда Дата регистрации: 26.10.2000 |
Это понятно. И если есть чёткий критерий разделения баз - по каждой из таблиц - это бывает не всегда. В одной таблице - "от забора", в другой - "до обеда". И с точки зрения бизнес правил всё спроектировано правильно. А справочники? То есть в некоторых случаях это возможный вариант, но далеко не всегда. ------------------ |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
Glyba Автор Сообщений: 386 Откуда: Собинка Дата регистрации: 23.09.2004 |
Спасибо за ссылку.
Цитата:Дело не в большом объеме - просто базы действительно разные, но обрабатываемые на одном экземпляре программы. Еще это может быть нужно, например, при отладке репликации. Реализовывать, конечно же, можно по разному, например, самый простой вариант - в каждом каталоге с данными по клону DBC, он же, чуть более продвинутый - существует "эталонный" экземпляр, который при переключении на данный каталог копируетсф в этот каталог (и тут какая-то верификация таблиц нужна), но мне все же больше нравится вариант, когда DBC физически единственный, с переключаемыми в нем путями к таблицам. Если структура проперти таблицы известна, можно это сделать. |
Re: Несколько экземпляров данных БД - кто как? | |
---|---|
matod Сообщений: 3062 Откуда: Иркутск Дата регистрации: 31.10.2001 |
В принципе, реализовать твою идею можно. Т.е. хранить один dbc и при запуске программы подцеплять-отцеплять необходимые таблицы. Есть например команды remove table, add table, free table, dbsetprop() и т.д., которые позволяют провернуть такой фокус штатными средствами. Но, полагаю, что это неправильное решение. База данных - это по идее целостный и замкнутый объект. И собственно сам контейнер DBC - его важная составляющая. При создании такого универсального контейнера недостатки очевидны, например, если структура таблиц в одной из БД поменяется, то возможны весьма неприятные ошибки при рассинхронизации. Кроме того, код для обслуживания получится достаточно сложный. Также такой контейнер нельзя будет использовать для совместного доступа к данным - один пользователь открыл БД и всем остальным придется работать с этой же бд, это не считая того, что для преобразований потребуется эксклюзивный доступ.
А вот преимуществ я не вижу ни одного - место на диске этим не сэкономишь. Чем не устраивает стандартный вариант - одна БД - один DBC? По-моему, не стоит заморачиваться. Да и нигле такие вещи не практикуются. Возьми, например, MS SQL - там каждая БД вещь в себе - имеет свои таблицы для хранения структуры таблиц и проч. |
© 2000-2024 Fox Club  |