Re: Sorry, but...
Date: Sun, 8 Jan 2012 16:18:37 -0800 (PST)
Message-ID: <8de87a5c-5538-4e42-8296-acf0037233c5_at_z19g2000vbe.googlegroups.com>
On Jan 7, 5:00 am, Eric <e..._at_deptj.eu> 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