List:General Discussion« Previous MessageNext Message »
From:metastable Date:November 15 2008 8:54am
Subject:Re: normalised designs: customer database
View as plain text  
Martijn Tonies 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" :-)
>
> Martijn Tonies
> Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Sybase
> SQL Anywhere, Oracle & MS SQL Server
> Upscene Productions
> http://www.upscene.com
> My thoughts:
> http://blog.upscene.com/martijn/
> Database development questions? Check the forum!
> http://www.databasedevelopmentforum.com
>
>
>   
I may just have had an insight over my morning coffee.
How about turning things around and adding a FK -to the customers table-
on each of the customer type tables (companies, people, charities, etc) ?

The customers table would have no idea if a customer is corporate or
private, it just has a customer number that can be used in processing
invoices and performing account maintenance.
The companies, people, charities, etc. tables would each have a FK to
the customers table.

This  does off course mean that creating and sorting  a list of all
customers is more complex, but the database would at least be normalised.
What do you think ?


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