There are certain types of redundancy that are good in the IT world: Backups, failover servers, recovery plans and the like. Most redundancy however, is bad. In the programming world, bad redundancy comes in the form of repeated code instead of reusable functions. Much of this is either leftover code that is ported from upgrade to upgrade, persisted from a time before subroutines were the norm. Sometimes the code is new, but from programmers who started in languages like COBOL that didn’t allow for reusable code. When you come upon such code, you should endeavor to consolidate. When you have multiple instances of code that is supposed to do the same thing, you run into the chance that it won’t do the same thing. The more copies there are, the more chances there are for it to differ or to fail.
The same holds true with data. When you store data in multiple tables and multiple columns, you have a greater chance for it not to match up. One of the last things you want in your database is to join two tables and have the data not match up properly. If for example, you have the employee name in 2 places, say FirstName, LastName in the Employee table and then FullName in the department table and you do a join, what do you do when you end up with
FirstName = Lawrence
LastName = Simmons
FullName = Jane Tauscher
If you run into this, you’d better have a way to find out which is the correct entry. Depending on how and when the data is updated, you can’t just assume the Employee information is the correct data. If nothing else, you’ll have to figure out how the Department record came to be wrong. Whenever possible, hold that data in only one place. If you have a secondary database as a data warehouse for reporting that is only updated from the primary database, you can have it in multiple places to make your reports run faster. If you only have the primary database, find some other way to speed up your reports.