Jeff Davis <pgsql at j-davis.com> writes:
> Now, you just replicate the one set of tables. It seems much more
> maintainable also.

I think I like that idea.  It also has the merit of requiring rather
fewer sequences :-).

Ah, yes.  Another thought...

Even if it turns out that having a lot of schemas and tables seems
best, it would surely be nice if those tables pointed to some shared
sequence in a central schema.  That would get rid of the "5000
sequences" problem.  And it would also mean that transaction IDs and
such (the things being populated using sequences) would be pretty
disjoint even across the 5000-odd users.

A third thought [having too many of these today ;-)]...

This seems a lot like a case for stored procedures.  If there are a
limited number of kinds of actions that can be performed, then setting
up a small list of stored functions as an API would make the names of
the tables totally irrelevant.

I'm working on an application that takes that approach: the
application code (in C++, as it happens) never issues an INSERT,
DELETE, UPDATE.  It instead calls stored functions which can hide a
fair amount of the intelligence and business logic on the DB side.
That does simplify the application a fair bit.
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)