On Fri, 2006-09-29 at 09:39 -0500, Erik Jones wrote:
> What we've done is to use table inheritance. So,
> we have a group of base account data tables and whenever a new account
> is added they get a set of tables that inherit from these base tables.
> This works well in that whenever we need a gl
On 9/29/06, Just Someone <[EMAIL PROTECTED]> wrote:
I am using a similar solution, and I tested it with a test containing
20K+ different schemas. Postgres didn't show slowness at all even
after the 20K (over 2 million total tables) were created. So I have
feeling it can grow even more.
That's g
snacktime wrote:
I'm re evaluating a few design choices I made a while back, and one
that keeps coming to the forefront is data separation. We store
sensitive information for clients. A database for each client isn't
really workable, or at least I've never though of a way to make it
workable, a
I am using a similar solution, and I tested it with a test containing
20K+ different schemas. Postgres didn't show slowness at all even
after the 20K (over 2 million total tables) were created. So I have
feeling it can grow even more.
Guy.
On 9/28/06, snacktime <[EMAIL PROTECTED]> wrote:
I'm r
Shane Ambler <[EMAIL PROTECTED]> writes:
> Thinking about it - it should only be a small source change to the sql
> parser to stop it from running a statement that didn't include clientID in
> the where clause.
> A small change that is easy to add again to new versions as they are
> released.
I'd
On 29/9/2006 15:29, "snacktime" <[EMAIL PROTECTED]> wrote:
> This has worked well so far but it's a real pain to manage and as we
> ramp up I'm not sure it's going to scale that well. So anyways my
> questions is this. Am I being too paranoid about putting all the data
> into one set of tables i
snacktime wrote:
This has worked well so far but it's a real pain to manage and as we
ramp up I'm not sure it's going to scale that well. So anyways my
questions is this. Am I being too paranoid about putting all the data
into one set of tables in a common schema? For thousands of clients
what
I'm re evaluating a few design choices I made a while back, and one
that keeps coming to the forefront is data separation. We store
sensitive information for clients. A database for each client isn't
really workable, or at least I've never though of a way to make it
workable, as we have several
