Re: More pain and sufferring with Tropashko's materialized path...

From: Robin Tucker <r.tucker_at_thermoteknix.com>
Date: Thu, 18 Sep 2003 11:42:40 +0100
Message-ID: <bkc25b$6td$1$8302bc10_at_news.demon.co.uk>


I will post just out of interest on an MS group, but further research leads me to believe this isn't such a good idea anyway, because apparently, with MS-SQL at least, applying a UDF per row tends to screw up query optimisation on large trees (something to do with serialization). I noted when I was testing my implementation, that returning the ordered tree with around 1000 nodes took over a second. My adjacency list with path strings returns almost immediately. In theory, this kind of numbering system is interesting, but in practice with todays DB engines (or rather, with MS-SQL!), I'm not sure it is worth the trouble.

"Vadim Tropashko" <vadimtro_at_yahoo.com> wrote in message news:22d2e427.0309171245.534732eb_at_posting.google.com...
> "Robin Tucker" <r.tucker_at_thermoteknix.com> wrote in message
news:<bk6os9$hrt$1$8302bc10_at_news.demon.co.uk>...
> > The error is "Arithmetic overflow error converting expression to data
type
> > float". This, I assume, is for the POWER function. So even when I use
> > BIGINT or DECIMAL(12,0), the problem is still there.
>
> I suggest posting the function and invocation context at microsoft
> forum, as there must be definitely a simple solution to your overflow
> problem.
>
> Otherwise, I'm inclined to add the following paragraph into my next
> article
> <quote>
> An immediate property of the above labeling schema is density: we have
> all integer positive numbers utilized. Since some database
> implementations have integers of limited range only, density might
> become an attractive feature, because one would be able to store and
> manipulate bigger trees before hitting arithmetic overflow exception.
> Today, the problem of 16-bit overflow is ridiculous, of course, but
> that is nevertheless the practical limitation that database developer
> have to live with in some RDBMS implementations.
> </quote>
>
> I'm suspecting once again, however, that the blank statement at the
> very end that I had drawn from your experience is wrong. I would be
> happy to learn that the overflow is a non-issue and remove the last
> statement.
Received on Thu Sep 18 2003 - 12:42:40 CEST

Original text of this message