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
