Jujitsu Lizard wrote:
> On Fri, Nov 14, 2008 at 1:39 PM, Martijn Tonies <m.tonies@stripped>wrote:
>>> >The notion of a "variant record" exists in many programming languages.
>>> >Typically you have a selector to indicate which variant it is. There is
>>> >nothing at all wrong with using the same sort of construct in a
>>> In O-O databases. I think the concept is not defined in relational
>>> database theory. Are you aware of the rel db rule regarding domains?
>>> >The only constraint you _really_ need to meet in a database is that
>>> you let
>>> >the database product do the things it needs to do so that the queries
>>> >make are O(log N) when possible. The rest is pure fluff. Beyond that,
>>> >there is no "should".
>>> Relational theory says otherwise.
>> I'm with Peter on this one, in relational theory and data modelling,
>> a lot of very well documented "should" :-)
> You guys have been reading too many books. Books are bad.
> The key question is when something is so much different from another thing
> that it is a qualitative difference rather than a quantitative difference.
> I go to the vet's office from time to time, and they keep their records in a
> computer. Is a rabbit different enough from a dog that you need different
> types of records in the database? Probably not. They are both pets. There
> may be some information about dogs that doesn't apply to rabbits or
> vice-versa, but people make do. You leave the "rabies vaccination" fields
> blank for a rabbit, presumably.
> The "variant record" notion applies--whether it is called that or not--in
> nearly every practical database in the world.
> A customer that is a person vs. a customer that is a company ... not that
It is once you consider creating automated invoices for that customer
(e.g. for an online webhosting service or monthly support service fees).
You can't deliver this unless a clear distinction is made between a
private customer and a corporate customer (and possibly other types of
institutions, with other tax rates).
> I do understand the points that are being made ... but once you get beyond
> the database product being able to make queries efficiently ... it is all
> I don't debate that for the problem as stated there are "better" or "more
> correct" designs involving more tables. I also don't debate that these
> designs are probably more resilient to change and have other advantages. I
> But you can take your licks in a more complex database design or more
> complex code to modify and insert rows and deal with query results. Being
> lazy, I'd take my licks in the second way.
I have the feeling you're a programmer who has learned how to keep his
feet on the ground while implementing. Respect !