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
>>>
>> database
>>
>>> >table.
>>> >http://en.wikipedia.org/wiki/Variant_record
>>>
>>> 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
>>>
>> you
>>
>>> >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,
>> there's
>> 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
> different.
>
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
> fluff.
>
> 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
> agree.
>
> 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 !
Best regards,
Stijn
