:: Архив конференции по VFP до 2005 года
Несколько экземпляров данных БД - кто как?
Glyba
Автор

Сообщений: 386
Откуда: Собинка
Дата регистрации: 23.09.2004
Начиная работать с VFP, я рассчитывал на то, что буду держать один экземпляр DBC и несколько наборов DBFов. Ведь контейнер всегда тот же самый, так что несколько экземпляров его держать как-то неконцептуально, а переключать расположение DBFов, видимо, будет легко. Как бы не так. Как оказалось, средства для программного изменения пути к DBFу из базы не существует. Правда, в хелпе описана структура заголовка DBFа, так что обратную ссылку на контейнер можно засунуть куда надо. А вот со ссылкой в контейнере не так просто. Хотя и идет в поставке фокса отчет 60dbcpro.frx, в котором описано содержимое поля Property, но как его формировать, там не сказано, а "метод упорного взгляда" не помог. Так и отложил я это до лучших времен, и до сих пор у меня в каждом каталоге с данными по клону DBC. И так можно жить, но все же - как это <i>следует</i> делать - у кого какие мысли?
Может быть, делать так, как это делалось бы в КС - ведь там наше будущее? И как это делается в КС?
Ratings: 0 negative/0 positive
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').''




------------------
С уважением Владимир.
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
Glyba
Автор

Сообщений: 386
Откуда: Собинка
Дата регистрации: 23.09.2004
Да у меня тоже работает такой вариант, как я и писал - по контейнеру в каждом каталоге. Так нехорошо ведь, когда он не один! Или хорошо? Вот в чем вопрос был.
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
Combat

Сообщений: 816
Откуда: Клайпеда
Дата регистрации: 26.10.2000
Vladimir Sklyar
- данные хранятся помесячно, вместе с контейнерами и полным набором баз в каждом каталоге
И как это добро сопровождать в случае постоянного развития системы?




------------------
Ratings: 0 negative/0 positive
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').''




------------------
С уважением Владимир.
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
Grin

Сообщений: 1083
Откуда: Kiev
Дата регистрации: 05.12.2000
У меня разделение идет таким образом
например есть три вида фондов с которыми работает пользователь
при входе в систему он выбирает с каким фондом он будет работать
а в формах идет банальный set filter to
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Hi, Glyba!

Структуру поля Property в DBC я уже расписывал:
forum.foxclub.ru
Вообще идею держать 50 баз одинаковой структуры я не поддерживаю - если уж
объёмы так велики, стоит задуматься о SQL-сервере, если же просто не нужны
"старые данные" - то раздели в рамках одной dbc (или 2-х это неважно) данные
на оперативные и архив. А вообще партиционирование это сложная и
неоднозначная тема - реализовывать можно по разному...




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
Combat

Сообщений: 816
Откуда: Клайпеда
Дата регистрации: 26.10.2000
Vladimir Sklyar
Скрипт с изменениями запускаеться в каждом каталоге.
Это понятно.
И если есть чёткий критерий разделения баз - по каждой из таблиц - это бывает не всегда.
В одной таблице - "от забора", в другой - "до обеда". И с точки зрения бизнес правил всё спроектировано правильно.
А справочники?
То есть в некоторых случаях это возможный вариант, но далеко не всегда.




------------------
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
Glyba
Автор

Сообщений: 386
Откуда: Собинка
Дата регистрации: 23.09.2004
Спасибо за ссылку.
Цитата:
Вообще идею держать 50 баз одинаковой структуры я не поддерживаю - если уж
объёмы так велики, стоит задуматься о SQL-сервере, если же просто не нужны
"старые данные" - то раздели в рамках одной dbc (или 2-х это неважно) данные
на оперативные и архив. А вообще партиционирование это сложная и
неоднозначная тема - реализовывать можно по разному...
Дело не в большом объеме - просто базы действительно разные, но обрабатываемые на одном экземпляре программы. Еще это может быть нужно, например, при отладке репликации. Реализовывать, конечно же, можно по разному, например, самый простой вариант - в каждом каталоге с данными по клону DBC, он же, чуть более продвинутый - существует "эталонный" экземпляр, который при переключении на данный каталог копируетсф в этот каталог (и тут какая-то верификация таблиц нужна), но мне все же больше нравится вариант, когда DBC физически единственный, с переключаемыми в нем путями к таблицам. Если структура проперти таблицы известна, можно это сделать.
Ratings: 0 negative/0 positive
Re: Несколько экземпляров данных БД - кто как?
matod

Сообщений: 3062
Откуда: Иркутск
Дата регистрации: 31.10.2001
В принципе, реализовать твою идею можно. Т.е. хранить один dbc и при запуске программы подцеплять-отцеплять необходимые таблицы. Есть например команды remove table, add table, free table, dbsetprop() и т.д., которые позволяют провернуть такой фокус штатными средствами. Но, полагаю, что это неправильное решение. База данных - это по идее целостный и замкнутый объект. И собственно сам контейнер DBC - его важная составляющая. При создании такого универсального контейнера недостатки очевидны, например, если структура таблиц в одной из БД поменяется, то возможны весьма неприятные ошибки при рассинхронизации. Кроме того, код для обслуживания получится достаточно сложный. Также такой контейнер нельзя будет использовать для совместного доступа к данным - один пользователь открыл БД и всем остальным придется работать с этой же бд, это не считая того, что для преобразований потребуется эксклюзивный доступ.
А вот преимуществ я не вижу ни одного - место на диске этим не сэкономишь. Чем не устраивает стандартный вариант - одна БД - один DBC? По-моему, не стоит заморачиваться. Да и нигле такие вещи не практикуются. Возьми, например, MS SQL - там каждая БД вещь в себе - имеет свои таблицы для хранения структуры таблиц и проч.
Ratings: 0 negative/0 positive


Извините, но у вас нет прав для того, чтобы оставлять сообщения в этом форуме.

On-line: 4 (Гостей: 4)

© 2000-2024 Fox Club 
Яндекс.Метрика