Hack once, read many
The primary benefit (for the bad people) of consolidating all the enterprise databases into one is that it makes the job of a hacker easier. They only have to break in to one database to steal all your confidential data.
Welcome to The Register Debate in which we pitch our writers against each other on contentious topics in IT and enterprise tech, and you – the reader – decide the winning side. The format is simple: a motion is proposed, for and against arguments are published today, then another round of arguments on Wednesday, and a concluding …
This post has been deleted by its author
In a hypothetical situation and hear me out on this, having everything in one database makes queries a bitch especially when every person and their dog are doing it. It also leaves you wide open to user errors if you don't set the permissions right which I know can be an issue with multiple databases and yes I have heard of backups but it's just too risky. Divide and conquer I say. There is a reason we don't put our eggs in one basket. Best case is also local duplication for anything that doesn't require real time access. This is just my opinion on the matter.
I deal with a couple of legacy databases, Oracle RDB, and a hierarchical database that originated on UNIVACs.
Neither of those is going to be on the table for consolidation.
Funny story, a developer brought me a SQL-Server backup, and asked for a Linux recovery. I downloaded the RPMs, initialized it, and the developer loaded the backup.
My next surprise was a call from management on an emergency SQL-Server conversion to Linux - turns out my newly-installed database was 100x faster than the production VM farm.
There are a few reasons for consolidation, but there are many reasons to refrain. Packing your favorite bowl or cup in your attic chest of porcelain means that you will constantly dis/reassemble the contents, and things will likely get broken. Certain architectural aspects become brittle and very difficult to change.
Why, that would be SAP, wouldn't it? That always works out well.
In seriousness though I'd be picking apart the question rather than trying to answer it. Merging databases into a single one is likely to fall on its arse at the first piece of software you come across that can only interact with its existing DBMS. Normalising individual databases and nominating the "source of truth" for any shared/copied data would likely be far more efficient for getting data integrity sorted. Either of these actions could be considered to be "consolidation".
Returning to my first point though, I've only worked at one place that claimed to run everything from one database (yes, SAP) and I know for a fact that they had at least three (yes, SAP plus other software for all the things SAP couldn't do which was anything and everything to do with the internet retail side) — and likely hundreds more, because those were just the ones I came to know about and I didn't work in an IT capacity there. It's a cute idea, but most places choose the right tool for the job rather than dictating the tool in advance.
I misread the intent of the title as basically stick all your data in one monolithic databse. This is madness and should not be done as it just creates a single point of failure for the company and becomes a nightmare to mange and maintain.
What you are intending is to single instance your data, ie only have one copy of your data in your environment. This is a very good thing as long as it is managed and distributed across several DBs, as it can make updating and maintaining a lot simpler. Just don't put it all in one DB because it won't end well.
It's consolidating databases rather than data, although the latter is a side-effect:
that’s not a patch on the sin of failing to consolidate databases that are inherently different but whose contents overlap. Although some of your databases will have no data in common (the HR database tends to be pretty exclusive, for instance) you’ll often have pockets of the same data in different systems – customer data, product data, pricing data, the list goes on
On the argument that improving tech results in poor, lazy coding: Not quite.
In current development cycles, delivering something on time (aka AGILE) is important. What is delivered is less so, but to hit these targets, developers take short cuts, write lazy code and rely on the tech to cover for them - who has time to optimise the code when you have to deliver in three days?
So what's written is 'good enough' in that it works thanks to the faster CPU, and it doesn't matter that it takes more space 'cause disk is cheap, right?
And when does the optimisation happen? When do we get to go back to make sure it's efficient? When something breaks and we have no choice.
"And when does the optimisation happen? When do we get to go back to make sure it's efficient? When something breaks and we have no choice."
if the bang-to-buck ratio is too low, it'll never be looked at again.
That being said, some inefficiencies can be avoided entirely by avoiding the platforms and programming lingos that tend to CREATE them. Yes, I'm talking about YOU TWO, C-Pound, JavaScript. Mostly JavaScript.
And sometimes, just doing things the old-school "shell script and POSIX utilities" way, gets things done the fastest, so you can focus on those few inefficiencies that make sense to focus on, deliver on time, stay under budget, etc.
.. is (for my employer, at least) we buy packaged software, usually with little to no customization. Hence, We do have multiple copies of, say, a list of all employees, because most of the apps don't talk to anything but their own little database. For that reason, we use shared servers to reduce licensing costs, administration headaches (fewer servers to backup and maintain), and we keep tight control over who has server admin rights.
the few apps that we do have major customization on (mainly because they are sold to us that way) are generally their own silos, so if their app decides to start eating database processor time like a fat man at a pasta bar, it doesn't bring down half the apps in the company.
Granted, odds are the database servers are living on the same storage appliance, possibly even the same volume....