|
|
Posted by Robert Klemme on 03/29/06 11:21
Erland Sommarskog wrote:
> Robert Klemme (bob.news@gmx.net) writes:
>> Erland Sommarskog wrote:
>>>> * Different data from the same row needs to be inserted into multiple
>>>> tables. "Common sense" (maybe "gut instinct" is better) says to handle
>>>> each row as a "unit". Seems weird to process the entire set for one
>>>> table, then to process the entire set AGAIN for another table, and then
>>>> YET AGAIN for a third table, and so on.
>>> I'm not sure that I understand this point. As I mentioned, I usually
>>> have my input to my set-based procedures in a table, so I don't really
>>> see the problem.
>> I think what Jay is up to here is mapping of an OO model to a relational
>> model. There is one "master" table which represents the root class of
>> his hierarchy and several tables for specific types. I've never worked
>> with user defined types but maybe these are an option here as well.
>
> I suppose you are thinking of the CLR UDTs added to SQL 2005. No, they are
> not an option here. CLR UDTs are for small values that always go together,
> and where you rarely would search for the individual values. Personally, I
> see CLR UDTs as a fairly marginal benefit.
Ah, good to know.
> As for the structure of Jay's tables, I have no problem to understand it,
> as I work with securities myself, and different classes of securities
> have different properties.
Then I probably misunderstood your posting. Sorry for the noise.
Kind regards
robert
Navigation:
[Reply to this message]
|