|
|
Posted by Erland Sommarskog on 05/27/05 23:56
Hugo Kornelis (hugo@pe_NO_rFact.in_SPAM_fo) writes:
> I stick to my advice: remove the derived column, and use a user-defined
> function to calculate the depth when you retrieve data.
Permit me to bump in and say that this is a trade-off on where you want
to take the performance penalty. However, a computed column would have
to traverse the tree from to bottom each time, whereas the trigger only
needs to access the parent level.
SELECT * FROM tbl
with a UDF call for tree-traversal for each row is likely to perform
poorly.
So my vote goes for the column. I think I would go for it, if would
have reasons to move around things in the tree, although it would be
bit hairly to maintain this column,
> it will work fone, even for multi-row inserts, as long as you never
> insert both a parent and a child in the same statement
Hey, the primary key is an IDENTITY column, so he can't do that!
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
Navigation:
[Reply to this message]
|