Re: Managing two sets of data in one database - Mailing list pgsql-general

From Jonathan Bartlett
Subject Re: Managing two sets of data in one database
Date
Msg-id CAHRTq6SHuCWOo=U3-D77MgCseLH+VU15RBG83MOHa6Cu5SDQNQ@mail.gmail.com
Whole thread Raw
In response to Re: Managing two sets of data in one database  (John R Pierce <pierce@hogranch.com>)
Responses Re: Managing two sets of data in one database  (Tom Molesworth <tom@audioboundary.com>)
List pgsql-general

by 'dataset' do you mean table, aka relation ?'

It's a group of tables.  
 
by 'not using any referential integrity', do you mean, you're NOT using foreign keys ('REFERENCES table(field)' in your table declaration ?

Correct.

Also, many queries cross the datasets together.


by 'cross', do you mean JOIN  ?

There are joins, subselects, and similar queries which cross the datasets.
 
Now, my issue is that right now when we do updates to the dataset, we have to make them to the live database.  I would prefer to manage data releases the way we manage software releases - have a staging area, test the data, and then deploy it to the users.  However, I am not sure the best approach for this.  If there weren't lots of crossover queries, I could just shove them in separate databases, and then swap out dataset #1 when we have a new release.


you can't JOIN data across relations(tables) in different databases.


Right.  That's the reason I asked on the list.  I didn't know if there is a good way of managing this sort of data.  If I could just have two different databases, I would have done that a while ago.  I didn't know if someone had a similar situation and what kind of solution they used for it.  Right now, both datasets are in the same database.  But that means I can't do releases of the static dataset, and instead, when the company updates the database, we have to make the updates directly on the live database.  I'm trying to avoid that and do releases, and I am seeing if anyone knows of a good approach given the constraints.

Jon

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: Managing two sets of data in one database
Next
From: Tom Molesworth
Date:
Subject: Re: Managing two sets of data in one database