1

Topic: Primary and foreign key in different databases

It is necessary, what the table with primary key
There was in one DB, and a table with the exterior
Key - in another. Also that it would be provided
Referential integrity.

2

Re: Primary and foreign key in different databases

Study http://firebirdsql.su/doku.php?id=execute_statement, it is is specific ON EXTERNAL DATA SOURCE.
Basically the task solved, but what for it is not clear.

3

Re: Primary and foreign key in different databases

> Gallemar
Thanks!
What for it?
The main DB has the size of 1.5 Gb, with it intensively
Work and every night becomes . Now
The help information prepares and it occupies to
100 Gb. It will change time in some years.
If it to place in the main DB that  quickly
Hammer in the server. Therefore the different are considered
Layout variants in a separate file.

4

Re: Primary and foreign key in different databases

kudatsky wrote:

It is necessary, what the table with primary key
There was in one DB, and a table with the exterior
Key - in another. Also that it would be provided
Referential integrity.

Master table copy in all a DB

5

Re: Primary and foreign key in different databases

kudatsky wrote:

different variants of layout in a separate file Therefore are considered.

Here there is no answer "what for foreign keys in another " are necessary.

6

Re: Primary and foreign key in different databases

Gallemar wrote:

Basically the task solved, but what for it is not clear.

Not solved. You will not provide integrity control with any triggers as it do FK

7

Re: Primary and foreign key in different databases

Denis wrote:

it is passed...
Not solved. You will not provide integrity control with any triggers as it do FK

You think? It is necessary to try to make. Generally a principal problem I see implementation .

8

Re: Primary and foreign key in different databases

Gallemar;
To begin with invent as it in one DB triggers to make. And then about the different you will think. It is assured that you will break off at the first stage

9

Re: Primary and foreign key in different databases

kudatsky wrote:

the Main DB has the size of 1.5 Gb, with it intensively
Work and every night becomes . Now
The help information prepares and it occupies to
100 Gb. It will change time in some years.
If it to place in the main DB that  quickly
Hammer in the server. Therefore the different are considered
Layout variants in a separate file.

The problem  such uniform basis can be solved partially application nbackup.
The first  will be in size with a DB, but the subsequent increments will not include any more the invariable data.
Since FB3 how much I in course, was essentially accelerated nbackup since he reads only those pages which have been changed.
On FB2.5 such optimization was not and for incremental  it was necessary to read all pages.

10

Re: Primary and foreign key in different databases

Denis wrote:

to begin with invent as it in one DB triggers to make.

Yes do not beat around the bush, at once a problem designate.
And that after all now checks up in the test basis, and does not think at all that it only exclusively works.

11

Re: Primary and foreign key in different databases

kudatsky;
Problem with reference manuals the known. At a present situation integrity between two DB does not dare in any way. For this purpose it would be possible to use tablespace, but it in  while is not present. Partial  is, but it not official, and will be hemorrhoids at recovery of a DB from .
p.s. Too it is not pleasant to me, for example, that at 1 8  always in basis. Earlier though separate files were, and now all in one...

12

Re: Primary and foreign key in different databases

kudatsky;
1. Whether the variant with an exception of tables from  approaches?
In triple like as such key is and for early versions there are assembly.
Recovery to do with disconnected , to pour in a DB with already ready structure and the reference manual.
2.  replication instead of

13

Re: Primary and foreign key in different databases

Denis wrote:

you will not provide integrity control with any triggers as it do FK

If to provide absence of removals and changes PK  it is quite enough triggers.
To ess th, it will work completely not quickly...
PS Referential integrity between tables of different DB is not provided with any DBMS, on how many I know.
Think at least that different DB have the right to be recovered of  independently from each other -
About what referential integrity here there can be a speech?

14

Re: Primary and foreign key in different databases

pastor;
This key is and in the final version. Here only about it it is a lot of restrictions. Completely not clearly how to merge two different  in one DB: one in which this table has been eliminated and the second in which it is present

15

Re: Primary and foreign key in different databases

Denis wrote:

pastor;
This key is and in the final version. Here only about it it is a lot of restrictions. Completely not clearly how to merge two different  in one DB: one in which this table has been eliminated and the second in which it is present

per anus ad astrum
In three stages
1. Recovery of a reference DB only with the reference manual
2. Recovery  a DB of a DB without the reference manual and
3. Data migration from  in the reference
Reference it is possible to prepare in good time. Preventively .

16

Re: Primary and foreign key in different databases

pastor;
Basically if full  to do once a month, and partial every day can also anything.
But if that eliminated table is present at one HP/TRIGGER, an ass

17

Re: Primary and foreign key in different databases

kudatsky wrote:

the Main DB has the size of 1.5 Gb, with it intensively
Work and every night becomes . Now
The help information prepares and it occupies to
100 Gb. It will change time in some years.
If it to place in the main DB that  quickly
Hammer in the server.

At first, , becoming on the same server, can not become at all for it is useless.
Secondly, para-triple  screws in the bekap-server solves this problem.
Thirdly, as already told, nothing hinders to place the main DB in reference, which not
generally.

18

Re: Primary and foreign key in different databases

What variant is possible still here:
. A DB not to do. All to allocate in one DB.
All to make in four passes.
1. Backup.
2. Restore in a temporary FDB-file
3. In a temporal file superfluous to delete.
4. Bacup from a temporal file.
Should work, but it is somehow bulky.

19

Re: Primary and foreign key in different databases

kudatsky wrote:

3. In a temporal file superfluous to delete.
4. Bacup from a temporal file.

What for? Really really place saving on the carrier with ?.

20

Re: Primary and foreign key in different databases

kudatsky wrote:

3. In a temporal file superfluous to delete.

....And here at you foreign key with an option cascade after the reference manual take down all DB:-D

21

Re: Primary and foreign key in different databases

kudatsky wrote:

what variant Is possible still here:
. A DB not to do. All to allocate in one DB.
All to make in four passes.
1. Backup.
2. Restore in a temporary FDB-file
3. In a temporal file superfluous to delete.
4. Bacup from a temporal file.
Should work, but it is somehow bulky.

If the purpose is distinct from SPEED (read frequencies) bakapa/restoration creation to do it senselessly
There are also others m-e-e-dlennye, but working variants

22

Re: Primary and foreign key in different databases

Pastor>
For me it is a question not speeds, and safeties of the data.
The server normal, at night for for an hour or two packs.
Simply, ugly somehow...

23

Re: Primary and foreign key in different databases

kudatsky wrote:

Pastor>
For me it is a question not speeds, and safeties of the data.
The server normal, at night for for an hour or two packs.
Simply, ugly somehow...

an output gbak in gzip on the same server also drive result on ftp to storage. It is packed well.

24

Re: Primary and foreign key in different databases

kudatsky wrote:

Pastor>
For me it is a question not speeds, and safeties of the data.
The server normal, at night for for an hour or two packs.
Simply, ugly somehow...

If you are laid down in the requirements on  (taking into account N years of maintenance) - you leave as is. Is not present - you lead up to the declared parameters
[spoiler Approximately so] GOST 34.602-89 Technical project on creation of information systems
4.3.2.7. Security requirements of the data from corruptings at failures and failures in system power supplies
The information in a system database should be saved at origin of the alert conditions connected to failures of power supplies.
The system should have the uninterrupted power supplies providing it normal functioning within 15 minutes in case of absence of exterior power supply, and 5 minutes in addition for correct end of all processes.
Reserve copying of the data should be carried out on the regular basis, in volumes, sufficient for information recovery in a data storage subsystem.
[/spoiler]

25

Re: Primary and foreign key in different databases

Old teddy bear;
100  to pack? Yes well . nbackup here it is necessary. And normal  - pair-triple times a month, and that for database check on absence of defects.