List:General Discussion« Previous MessageNext Message »
From:metastable Date:November 16 2008 10:14am
Subject:Re: normalised designs: customer database
View as plain text  
Jujitsu Lizard wrote:
> On Sat, Nov 15, 2008 at 3:54 AM, metastable <listpit@stripped
>   
>> wrote:
>>     
>
>
>   
>> 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 ?
>>
>>     
> I think you just made my point.
>
> You now recognize that designing it "right" introduces other complexities.
>
> With the problem you presented, it is just a matter of where you want to get
> tasered.  There isn't a solution that optimizes all parameters.
>
>   
Hey,

I have to disagree.
Any application is and always will be complex.
Having the database refuse to screw itself up whenever the programmer
makes a mistake, and he/she always will, is a great step towards the
goal of simplification and robustness.

Moreover, apart from the sorting problem in this design, I think the set
of queries in general is much more simple than it would have been had I
used one of the options from my previous line of thinking.
I think you can never go wrong with normalized databases.


Anyway, I think my question has been answered. Always nice to answer
your own questions :)
Thanks for all the  comments.


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