Re: Question: Data Partioning between customers

From: Vince Germscheid <Vince_Germscheid_at_cscmail.csc.com>
Date: 1996/08/24
Message-ID: <01bb91bd$5d4b8f20$1f1e0814_at_vgermscheid.min.csc.com>#1/1


scruf <scruf_at_stlnet.com> wrote in article <01bb8e4a.79d13b20$490734ce_at_allen01>...
> Here is a quick design question I have about a new project:
>
> My client needs a database application that they plan to market to
 several
> customers. My client will run the application as a service where
> customers can network in and access _only_ their data. I've been
> requested to come up with a fail proof way to ensure that the my client's
> customers can only see the data they are authorized to see.
>
> At first blush, I designed the tables to support an unique key that
> included my client's customer identifier. This allows our team to always
> use a extra condition in the where clause for all operations to isolate
> the data. On the down side, this results in a painful denormalization
> that I am not happy about.
>
> I've been pondering about the use of different instances, yet I am not
> sure about licenses or performance.
>
> Do you have an alternative that I should explore?
>
> What are your experiences?
>

Separate instances would work, up to a point. If your customer base is large, than you would run out of server resources at some point.

I'd look into creating a separate schema (table owner) for each customer. Using the column to identify customer could create performance problems with the application, especially for any batch/reporting applications.

V. Received on Sat Aug 24 1996 - 00:00:00 CEST

Original text of this message