I have an application backed by a database with thousands of tables,  
the majority of which are inherited from a small set of parent  
tables. The way this is structured is that new user accounts get  
their own cluster of tables during the account creation process of  
the application.

I'm looking into setting up Slony for this database, partly as an  
upgrade path and partly as a way of introducing replication to the  
database environment.

In looking at the setup materials, it almost seems like the best  
approach would be to put each user table set in its own replication  
set. The only drawback would seem to be that these child tables often  
have foreign key relationships to tables that are not in the  
inheritance hierarchy.

I was thinking that I would put all parent tables and tables not in  
the inheritance hierarchy in their own replication set. Then I could  
just create new replication sets during account creation and then run  
EXECUTE SCRIPT as part of that process in the application.

Otherwise, there does not seem to be a convenient way of breaking  
down the overall data model into smaller replication sets, and I  
don't think the subscribers will be able to afford the locks from an  
EXECUTE SCRIPT each time a new account is created at the origin.

Is there an elegant Slony solution to this architecture? Will the  
multiple replication set approach be too fraught with peril from  
foreign keys and ordering issues affecting parent and child tables?

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i?

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20050524/543b3e8b/attachment.html