Re: DB Design Dilemma!! One DB or Many DBs??

From: Robert Dean <noemail_at_hatespam.spam>
Date: Tue, 12 Feb 2002 13:58:32 -0600
Message-ID: <3C6973E8.79FCCE6C_at_hatespam.spam>


Doug Miller wrote:
> > "Camp C" (one database, multiple table owners) - want to use a single
> > database,
> > but copy the "accounts_recievable" and "accounts_payable" tables and
> > give privileges only to the applicable group, I.E.,
> > "group_i.accounts_recievable".
>
> Stored procedures with authentication? Stored procedures with some
> security stuff built in might be easier then maintaining all the views
> in the long run. Pass the Sproc a secret code that authenticates the
> fact that a connection is for a specific division, and the one Sproc
> will return the data for all divisions. Yes, this doesn't follow most
> OEM's security implementation, but 350 separate views gets old also
> when you discover that someone wants to add a field to a table, and
> you get to go "fix" all the views, test them, and verify security.

The stored procedures approach gets around having the issue of having to maintain the views, but then you've got a chunk of proprietary code out there that has to be maintained and the code to call the stored procedure has to be woven into the application design. IMNSHO, you have to have a compelling reason before introducing this kind of application design overhead.

Views utilize the standard security model of the RDBMS, not one that has had to be developed from scratch. As long as a rule against "special" versions of views is enforced, changes to the views can be largely, if not totally, automated.

-Robert Received on Tue Feb 12 2002 - 20:58:32 CET

Original text of this message