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]
