NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
First s/databases/software/ ... (Score:1)
Then pick any of the following:
Continuing this list is left as an exercise for the reader :-)
Models are not the real world. They're an abstraction chosen to make a particular problem domain easier to manipulate. Sometimes people pick the wrong model. Sometimes the problem domain changes.
There's nothing that's particularly relational about the issue about whether addresses are separate "things" from customers. I've seen exactly the same issue with OO code.
And I can't tell just by looking at a object class hierarchy whether a particularly odd looking arrangement of classes is a reflection of business knowledge or if it's a mistake.
Being normalised doesn't say anything about the fitness of a relational model for a particular problem domain any more than the Law of Demeter says anything about the fitness of an OO model for a particular problem domain.
Relational models that are normalised have nice properties that can be useful. OO models that follow the Law of Demeter have nice properties that can be useful. They're talking about how good the model is. I don't think it's really fair to ask them to say things about how well a model fits a problem domain too!
Which of course would be a wonderful thing to know.... wish I knew how to figure it out... :-)
I'm curious why you think heirarchies and relation models are contradictory (nested set tree model and all that...) ?
Reply to This