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
