БД со статической информацией

← →
Kombat (2002-06-11 15:04) [0]

HI All! Помогите с советом! Есть БД с информацией которая пишется один раз и потом не меняется (каждый месяц, неделю записываем данные о счетах, накладных клиента, его телефонных переговорах) эта база создается на год (большой объем). И есть БД где хранятся справочники, данные о клиентах и прочая динамическая инфо. Разделение БД обусловлено тем что не хочется каждый день бекапить новые данные вместе со статикой. Кто может подсказать как быть со ссылочной целостностью (иметь копии справочников в БД статики?, синхронизировать их?). Как вообще в таких случаях поступают?

← →
Johnmen (2002-06-11 15:14) [1]

Традиционно - все в одной базе.
И почему вдруг не хочется каждый день бекапить новые данные вместе со статикой ?
А если в разных - то это, на мой взгляд, чуднО, и про ссылочную целостность можно забыть...:)

← →
Kombat (2002-06-11 18:29) [2]

Просто каждый месяц прибавляется по ~150~200 Мб, и каждый день архивировать данные которые не меняются (за два года набежало ~2 Гб - это планируется перенос фоксовкой задачи на нормальные рельсы) не сыльно рационально с точки зрения дискового пространства и времени. Я уже сам пришол к тому что нужна одна база, тогда и ссылки и все нормально, но бекап 2-3 Гб каждый день ? (((

← →
TSV (2002-06-11 19:01) [3]

> Johnmen © (11.06.02 15:14)

Про ссылочную целостность можно не забывать... Просто делается это не "в лоб"...

Удачи. ;-)

← →
Fareader (2002-06-12 14:52) [4]

2TSV © (11.06.02 19:01) а подробнее? Умничать любой может, а предложить дельный вариант - не каждый :(

← →
TSV (2002-06-12 15:57) [5]

> Fareader © (12.06.02 14:52)

Я и не умничаю...
Если кому-то сильно надо, то напишу.

С уважением.

← →
Kombat (2002-06-12 16:46) [6]

2TSV © Если можно, то по подробнее о решении "не влоб".
Я пришел к выводу, что наиболее оптимальное решение - это ведение всех данных в одной БД (тогда и целостность решается и синхронизации никакой ненадо), потом делаем прогу (или берем готовое) которая будет ночью вытягивать из БД НЕ статические таблицы (справочники, таблицы с меняющимися данными) и уже эту БД (вытяжку) архивируем, т.е. решается проблема излишних данных в архиве. Кроме того, 01.01 каждого года делаем КОПИЮ текущей БД, и это будет НЕ изменяемая БД прошлого года (для справок). А из текущей удаляем статику за прошедший год и живем дальше.
Может кто предложит что получше?

← →
TSV (2002-06-12 18:21) [7]

Значится так.
Существует так называемая модель баз-сателитов. То есть есть база с какими-то общими данными. Назовем ее xMaster. И есть базы, которые могут ссылаться на данные в xMaster. Назовем их xSatelite1, xSatelite2, ... , xSateliteN. Допустим, что у нас есть в главной базе таблица Persons (ID, Name, Age, ...), на которую могут ссылаться из других баз. Как обеспечить ссылочную целостность? В каждой базе-саттелите мы создадим таблицу, например tPersons, которая будет содержать лишь первичный ключ, такой же, как и в Persons. Далее для Persons мы пишем триггеры на вставку и удаление, в которых распространяем (вставляем или удаляем) данные (ключи) в таблицы баз-сателлитов. Для того, чтобы жестко не завязываться на имена баз-сателлитов, в главной базе создается табличка с именами баз-сателлитов. А в триггере формируется курсор на ее основе и строятся динамические операторы на INSERT и DELETE. Вот собственно и все. ;-)

ЗЫ
Идея эта не моя и авторство я себе не приписываю...

← →
fool (2002-06-12 18:37) [8]

>TSV
Молдец, порадовал старика! :0)

← →
Johnmen (2002-06-13 10:01) [9]

>TSV © (12.06.02 18:21)

Я что-то не уловил, где тут поддержание ссылочной целостности, да к тому же и терминах IB ???

← →
TSV (2002-06-13 10:42) [10]

Прочитай внимательно еще раз... ;-)

Внешние ключи в базах-сателлитах строятся на таблицу tPersons (см. выше). А изменения в этой таблице инициируются из базы-мастера.
В терминах IB не знаю (нюансы языка), работаю с MS SQL Server.

Удачи.

← →
Johnmen (2002-06-13 10:58) [11]

>TSV © (13.06.02 10:42) : Вот именно - IB, а не MSSQL...

← →
Fareader (2002-06-13 11:04) [12]

2TSV © (12.06.02 18:21) Если я не ошибаюсь, то чтобы создать такую ссылочную целостность - прийдется писать UDF, чтобы заносить данные в базы-сателиты, но как тогда откатить изменения в этих сателитах, если откатывается транзакция в мастере?
Поправьте, если я не прав.

← →
TSV (2002-06-13 11:11) [13]

Я же написал, что нужен триггер... В триггере все операции протекают в разрезе одной транзакции. Если что-то произойдет не так, то нужно просто сделать ROLLBACK.

> Johnmen © (13.06.02 10:58)
А что, такое в IB реализовать нельзя??? А еще потом говорят, что он круче... ;-)

← →
Johnmen (2002-06-13 11:11) [14]

>Fareader © (13.06.02 11:04) : И по поводу транзакций ты совершенно прав !
И не только откат, но и механизм принятия непонятен !

← →
TSV (2002-06-13 11:23) [15]

Вот кусок из триггера:

CREATE TRIGGER tI_ctOrgAccounts ON ctOrgAccounts FOR INSERT AS .................. .................. -- Распространение изменений по рабочим базам declare @oaID int, @DBName varchar(30), @StrExec varchar(250) declare Cr cursor for select DBName from usBases select @oaID = oaID from inserted open Cr fetch next from Cr into @DBName while @@FETCH_STATUS = 0 begin select @StrExec = "insert into " + @DBName + ".dbo.tOrgAccounts (oaID) values (" + str(@oaID) + ")" exec (@StrExec) if @@ERROR <> 0 begin close Cr deallocate Cr goto ERR end fetch next from Cr into @DBName end close Cr deallocate Cr return ERR: rollback tran

Как это сделать в IB, я не знаю. Но думаю, что можно...

← →
TSV (2002-06-13 11:24) [16]

И еще. Надо следить за тем, чтобы вставлялась (удалялась) одна запись за транзакцию в главной базе.

← →
Fareader (2002-06-13 11:30) [17]

2TSV © Видишь ли в IB вот так посто из тригера нельзя обратиться на другую базу - для этого надо писать UDF, а она уже не зависит от той транзакции, в которой была вызвана. Т.е. если в мастере транзакция откатилась, то изменения, внесенные в сателиты через UDF, просто так не откатяться...

← →
Johnmen (2002-06-13 11:30) [18]

А в какой момент и где для дочерних БД делается COMMIT ?
И если для одних доч.БД все прошло, а для др. - нет, то что ?

← →
Lusha (2002-06-13 11:43) [19]

Господа, мне кажется, Вас понесло!
Способ предложенный TSV в принципе рабочий... Если даже IB не позволяет реализовать ссылочную целостность для такой структуры БД непосредственно на сервере, то кто Вам мешает воплотить сие на клиенте... Я подобное воял на OnUpdateRecord... :)

← →
TSV (2002-06-13 11:46) [20]

Ну, просто COMMIT в триггере неявный ;-). Его можно написать перед RETURN.

> И если для одних доч.БД все прошло, а для др. - нет, то что ?
То ROLLBACK для всех (см. код).

← →
TSV (2002-06-13 11:50) [21]

> Lusha © (13.06.02 11:43)
Он не в принципе рабочий, он рабочий на 100%.

И дело не в ссылочной целостности, а в возможности выполнения одной транзакции в разрезе нескольких баз + динамические запросы.

> All
Если в IB этого нельзя сделать, это не значит, что способ плохой... Просто IB менее функционален... ;-)

← →
Alexandr (2002-06-13 12:00) [22]

все криво.
Вы пытаетесь применить решение этой проблемы на MSSQL к IB.

А на IB надо вообще не так делать.

А хранить нужно все в одной базе и мозги себе не забивать всякой херней.

А частичный бакуп можно свой написать, если уж прижало, а лучше одностороннюю репликацию.

Проверять ссылочную целостность вручную это всегда глюкаво, и решения тут нет при многопользовательской работе.

Давойте так.
На конкретную проблему есть конкретное решение, а вы тут развели демагогию, смешав и MSSQL и IB и подмешав сюда клиентские программы. Смешав частичный бакуп с просеркой целостности в масштабах нескольких баз данных.

← →
TSV (2002-06-13 12:13) [23]

Я лишь предложил идею и ее конкретное воплощение на MSSQL.
Если такой вариант для IB не подходит, то... такова селява... ;-)

С уважением.

← →
Alexandr (2002-06-13 12:17) [24]

человеку для IB надо.
ну давайте ему предложим еще по Oracle, DB/2, SYBASE, Paradox...
кто там еще чего знает?

← →
Johnny Smith (2002-06-13 12:49) [25]

2Alexandr © (13.06.02 12:17)
человеку для IB надо.
Ну, можно было бы предложить следующее:
1) в каждой таблице создать столбец TimeStamp, в котором хранить время последнего изменения
2) написать самостоятельно прогу, которая бы с некоторой периодичностью бэкапила (как и куда - решит сам автор) только те строки из таблиц, в которых значение TimeStamp"а превышает время последнего бэкапа.

← →
TSV (2002-06-13 12:56) [26]

Я не знал, что IB такой ограниченный...

← →
Alexandr (2002-06-13 12:59) [27]

2Johnny Smith: согласен
2TSV: Не знал, но говорил. Все серверы разные, в каждом есть достоинства и недостатки и это не IB ограниченный, а твои познания ограничены только MSSQL

← →
Johnmen (2002-06-13 13:04) [28]

>TSV © (13.06.02 12:56)

MS Word тоже сильно ограниченный - он не умеет вышеприведенного и много чего еще :)))))))))))))))

← →
TSV (2002-06-13 13:38) [29]

По-моему, начался флейм...
Вам не нравится идея, потому что ее нельзя реализовать в IB...

Все верно. IB - это СУБД для рабочих групп и этим все сказано...
А если у вас - холдинг или корпорация, где у каждой юридической единицы своя база (несколько гиг, иногда - десятки), то такая модель - очень даже то. Да и IB тут не потянет в принципе... Каждому свое...

← →
Alexandr (2002-06-13 13:47) [30]

холдинг, говоришь...
ну-ну.

← →
Romkin (2002-06-13 14:00) [31]

Ничего не понимаю. Есть же в IB транзакции на несколько БД одновременно, просто давать обновление одновлеменно на две БД, и синхронизация будет.

← →
TSV (2002-06-13 17:00) [32]

Так все-таки можно или нельзя в IB???

← →
Johnny Smith (2002-06-13 18:20) [33]

2TSV © (13.06.02 17:00)
Так все-таки можно или нельзя в IB???
Да можно, можно... Решение будет халявным и вполне надежным. Но только в рамках, вами и указанных: "IB - это СУБД для рабочих групп и этим все сказано"

← →
Romkin (2002-06-13 18:29) [34]

В IB гетерогенных запросов по базам нет, есть транзакция на несколько баз, это если нужно обновлять одновременно несколько таблиц в разных базах. Просто открываешь транзакцию, делаешь изменения и далее commit|rollback. При желании можно делать таким образом синхронизацию, например, в одной базе - справочник, в другой таблицы со ссылками на него... В этом случае обновление ссылочных полей делают в транзакции на две базы.
Но, ессно, запрос на выборку одновременно из двух баз сделать нельзя, только разными query в разные наборы данных.
В общем, для сохранения целостности этого обычно достаточно...

БД со статической информацией Найти похожие ветки