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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
