Jujitsu Lizard wrote:
> On Sat, Nov 15, 2008 at 3:54 AM, metastable <[EMAIL PROTECTED]
>   
>> 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

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to