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.
