9.8.1 Why separate data?This is NOT the latest copy of this book; click here for the latest version.
Novice database designers tend to put all their information into one table on the grounds that "it makes things easier" or something similar. To illustrate the problem with this approach, I created a table of people in companies, where each row contains one person, their home address, the company they work for, and the company address.
Looking at the above table, what happens if, say BloggsCo (the company Joe Bloggs and Anna Carter work for, as well as potentially thousands of other people), moves address? We'd have to go through each record, and adjust the data. Or, worse, what happens if an operator mistypes the company name and enters "BlogsCo"?
By having everything in one table, we experience large amounts of data duplication because the company address is duplicated for each worker, and we're also leaving ourselves wide open to human error - if an office worker has to type in the same address a hundred (thousand?) times over, the chances of them making a mistake is quite high.
Furthermore, we experience what is called a "deletion anomalies" when we delete the last person from a company - that is, if we delete Laura Bond, we not only lose her record, but we also lose the last copy of Microsoft's address.
|
Want to see this stuff in print? PHP in a Nutshell takes the core topics covered here, adds in thousands of edits from the editorial team and myself, and combines them to make an unbeatable reference for PHP programmers at all levels.
My latest book has hundreds more tips on how to use PHP, Apache, and MySQL, plus Perl, Python, shell scripts, performance tuning, and more!
|
