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
>> 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
>> >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
> My thoughts:
> Database development questions? Check the forum!
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 ?