List:General Discussion« Previous MessageNext Message »
From:Martijn Tonies Date:November 17 2008 9:08am
Subject:Re: normalised designs: customer database
View as plain text  
>>>  >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 notion of a "rabies vaccination" -column- is a bad thing, if this is
your design,
you've gone the wrong path. Any decent database design book will tell you
that,
perhaps books aren't that bad?

>The "variant record" notion applies--whether it is called that or not--in
nearly
>every practical database in the world.

It still doesn't apply.

>A customer that is a person vs. a customer that is a company ... not that
different.

Right...

>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.

Fix the product, keep the design proper.

Yet, it's not just about the database product itself, it's the idiocracies
you'll be
introducing when your design goes haywire...


Martijn Tonies
Database Workbench Lite for MySQL - FREE developer tool for MySQL!
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

Thread
normalised designs: customer databasemetastable14 Nov
  • Re: normalised designs: customer databaseMark Goodge14 Nov
    • Re: normalised designs: customer databaseMr. Shawn H. Corey14 Nov
      • Re: normalised designs: customer databasemetastable14 Nov
  • RE: normalised designs: customer databaseJerry Schwartz14 Nov
  • Re: normalised designs: customer databaseJujitsu Lizard14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
    • RE: normalised designs: customer databaseUS Data Export14 Nov
      • Re: normalised designs: customer databasemetastable14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
    • Re: normalised designs: customer databaseJujitsu Lizard14 Nov
      • Re: normalised designs: customer databasePeter Brawley14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies14 Nov
    • Re: normalised designs: customer databaseJujitsu Lizard14 Nov
      • Re: normalised designs: customer databasemetastable14 Nov
    • Re: normalised designs: customer databasemetastable15 Nov
      • Re: normalised designs: customer databaseJujitsu Lizard15 Nov
        • Re: normalised designs: customer databasemetastable16 Nov
          • RE: normalised designs: customer databaseJerry Schwartz17 Nov
            • Re: normalised designs: customer databasemetastable17 Nov
  • Re: normalised designs: customer databaseBill newton14 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov
    • RE: normalised designs: customer databaseUS Data Export17 Nov
  • Re: normalised designs: customer databaseMartijn Tonies17 Nov