If there was any possibility you may want to do joins across more than
one client's database, then I would say make it one database. But if the
data is truely separate and no application wants to read more than one
database at once, then make them separate. Upgrades should be automated
anyway.
Robert wrote:
>
> Hallo,
>
> would some experienced person care to comment on the following
> problem?
>
> I have, say, an accounting application using Postgres and I'm using it
> for several (potentialy hundred) clients. Basically, I have two
> possibilities:
>
> - each client gets separate database
> - one common database for all clients, each table has client_id field
> added
>
> First possibility is a maintenance nighmare (upgrading etc. hundred
> databases instead of one) while the second possibility makes possible
> (and quite likely) one client will see or modify other's data due some
> programmer's errors (I'm sure there will be bugs in the application all
> the time no matter what we do). Now, the idea I like best is to create
> set of views for each client and let the application see just that - I
> would never have to worry about application bugs (well, hardly ever).
> However, this "virtual" database is read-only because in Postgres views
> are read-only. Tom L. said in private email that I can create my own set
> of rules for inserting/deleting/updating views, which could be a good
> compromis I guess. What do you think? Thanks for your comments.
>
> - Robert
