List:General Discussion« Previous MessageNext Message »
From:metastable Date:November 14 2008 7:34pm
Subject:Re: normalised designs: customer database
View as plain text  
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
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