Rudy Lippan wrote:
How about complex data requirements? Depending on the resolution of
your data set, I could see a "simple" person-type object that contained
name, address, SSN, mother, and birth_info starting to approach the limit.
Cities change, address changes, names change, and even mothers can
change. The simple-looking street part of an address can have (at least)
number, direction, name, suffix, any of which can change.
Okay, so you want to link a person to an address table. I can justify
that in the case of multiple addresses with a single person. But then
you build a 'city' table to normalize that. Or no, better make a zip
code table, link that to the 'city' table.
Wait, streets can change names; a 'street' table too to link. Oh no!
sometimes streets are split. So an address is a 'property' (a piece of
ground), linked to a street, street linked to zip code, zip code linked
to city. Damn (sorry), a 'property' can be divided... Oh my...
Ever thought about updating a table by renaming a street? Or by
selecting a group of street-number combinations and rename them?
The real art is trying to balance the need of simplicity and ease of
understanding with the need for flexibility, and that has nothing to do
with relational theory.
In real life the balance tends to go to unnecessary flexibility
resulting in systems which are simply too heavy for the actual needs.
> Complex datasets are, by their nature, complex,
and can only be simplified so much. You try to hide the complexity, you
shift it, you move-it, you send it to its room, you pretend it is not
there. And yet it still pops up at the most inopportune times and has to
be dealt with.
And still, in a lot of cases the complex datasets are even made more
complex by normalization, trying to be ultimately flexible and creating
a solution for problems which simply don't exist.
In almost all cases a simple solution will be the best.
Regards,
Jigal van Hemert.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
