Jujitsu Lizard 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.
PB
-----
Jujitsu Lizard wrote:
> On Fri, Nov 14, 2008 at 10:45 AM, Martijn Tonies <m.tonies@stripped>wrote:
>
>
>>>> This is where it gets nasty. A customer may be a human being or a
>>>> company. I see different approaches here:
>>>> 1) keep customer tables separate, based on which type of customer it is
>>>> 2) create the customer table with a column specifying if we're dealing
>>>> with a human being or a company
>>>> 3) create the customer table with a FK for people and a FK for
>>>> companies, and decide on the customer type in the application based on
>>>> the presence of that key
>>>>
>>>>
>>> You're making it more complicated than it needs to be.
>>>
>>> A customer may be either a person or a company.
>>>
>>> Your customers table may contain columns that are the union of what is
>>> required for a person and what is requried for a company, plus of course
>>>
>> an
>>
>>> enumerated value that indicates which the customer is and indirectly
>>>
>> which
>>
>>> columns are populated for a given row.
>>>
>>> Problem solved. Over time, several square millimeters on a disk wasted.
>>>
>> Back to "database design" class for you ;-)
>>
>> Store in a table what you need to store, storing "which columns are
>> populated
>> for a given row." is complete rubbish.
>>
>> By retrieving data you should -know- what data it is, not having to
>> retrieve
>> a value that indicates what the data actually means.
>>
>
>
> The use of "should" is a bit tricky. By whose standard?
>
> 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
>
> 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".
>
> The nature of the problem presented by the OP is that all possible solutions
> are awkward in one way or another. It is just a question of where you want
> to take the awkwardness. There is no right answer for this problem.
>
> You've chosen the gal who can cook but would crack a mirror. I choose the
> one who looks great but can't cook. Neither is the superior choice.
>
> "Should" in the sense you intended it only exists if there is a gal out
> there who looks great and can cook well ... I don't see it in this case.
>
> There are some problems where there is a "right" answer ... but I don't see
> it in this case because there is complexity introduced no matter which
> direction you go.
>
>
> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.9.0/1777 - Release Date: 11/9/2008 9:53 AM
>
>
