Форум: "Базы";
Текущий архив: 2002.07.08;
Скачать: [xml.tar.bz2];
ВнизБД со статической информацией Найти похожие ветки
← →
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 в разные наборы данных.
В общем, для сохранения целостности этого обычно достаточно...
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.07.08;
Скачать: [xml.tar.bz2];
Память: 0.53 MB
Время: 0.007 c