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

Hi Jerry,

you are right...!! I did NOT consider that two databases could get out of sync because of backup-restore scenarios... Your point is well taken, and will figure heavily in the final design... Also, additional requirements have been identified (sharing of account info), which contradicts the requirement for data isolation. Thus our design remains in the analysis and prototype phase.

And I also agree with your comments about keeping the design simple, and that data isolation does not need to be solved by using separate databases (horizontal partitioning).

Thanks for your comments, Jerry!
-Rob.

> Rob,
>
> I think you're making it too complicated. You're splitting it into
> multiple databases to handle security issues - when one database can
> easily handle the security issues for you.
>
> You're creating a maintenance nightmare - what happens if one database
> gets backed up but not the other, for instance.
>
> Performance always suffers when you're accessing multiple databases
> instead of just one database.
>
> Application code to handle your design will be much more complex,
> allowing for more potential errors (and potentially *decreased
> security*, for instance).
>
> Future changes will be much harder to implement (and there will always
> be future changes needed).
>
> The simpler the design, the more flexibility you will have.
>
> I could go on. But the bottom line is your design is awkward and
> needlessly complicated. DB2 already has security features built in
> (i.e. GRAND and REVOKE on views) which will give you the necessary
> security but keep your design much simpler.
>
>
> Rob Hindman wrote:
> <other stuff snipped>
> > Dirk and Jerry, I respect your opinions and I thank you for your
> > warnings.
> > Where, exactly, do you problems with my logic, approach, or
> > assumptions?
> >
> > Many Thanks...
> > -Rob.
> >
Received on Fri Feb 15 2002 - 01:48:29 CET