It wasn't me. You can't prove anything.


2013-03-12

Too many databases


At my work, a huge company, we have several asset tracking databases. We have a couple for the desktops. We have several for parts of things that go to customers. There are more than one database for every computer in every lab and everyone who has access and who is their boss.

It all boils down to too many databases. If you sit there and think about the trail of the needs of different departments. Some of these database have the exact same data with different relationships to other data. Some have the same data and pretty much the same relationships. The latter come about when a group of people who already have a database will not share the data, or control over the data with another group of people who need pretty much the same data and relationships.

From the company point of view this kind of thing is a nightmare. The idea is to know what you have, what it is used for, where it is and who has control of it. When you have fifteen databases all with basically the same repeating data, but none compatible with the next, the company loses continuity.

The employees who have to deal with the fifteen databases waste time dealing with redundant information entry. The idea of entering the same, but slightly different data into several databases also causes loss of data. Stuff starts falling through the cracks. People want to enter into their favorite database and blow off the databases that do not make sense to them.

The solution is to consolidate and organize databases. Get your data in the place where it will do you some good. That is much easier said than done.

No comments: