Re: Sorry, but...

From: Noons <>
Date: Sun, 8 Jan 2012 16:18:37 -0800 (PST)
Message-ID: <>

On Jan 7, 5:00 am, Eric <> wrote:

> Well no one had mentioned it, so I did. And consolidation is very
> difficult to achieve in that environment. Firstly there is patient
> confidentiality - there are laws about that sort of thing, and a need to
> prove that access is recorded and unauthorised access prohibited. "We
> want to move your data onto a shared server" is not going to be an easy
> thing to say to the customers.

This is one of the great fallacies of the shared vs dedicated db server nonsense.
Multiple application data in a shared db server is no more exposed to cross-schema peeking than it is in a dedicated server. Access to data in a dedicated server is controlled by a login and a pwd.
Access to data in a shared server is also (surprise surprise!) under control of a login and a pwd.
What exactly is the difference that makes it safer to have a dedicated server?
The complete inability of architects to create a safe application data separation in a single server?

Ah well, but that is a problem with the architect. Not the dba, not the server, not the software. High time some of these "architects" got their decisions scanned and audited for any validity...

> Secondly the sheer inertia of that customer base slows down major
> changes significantly.

True. But that is something that can be managed.

> And finally the application architecture imposes restrictions - I
> suspect you would find it quite weird.

I've long ceased to be amazed or surprised by moronic application design decisions...
:-) Received on Sun Jan 08 2012 - 18:18:37 CST

Original text of this message