On Mon, Dec 03, 2001 at 08:03:44PM +0100, Emiliano wrote:
> I explicitly said it'd be an add-on, strengthening facility.
OK.
> > this will make tree management much more easier for all components, but it
> > is hard to put it into refint way for in-table relations between objects
> > which we have almost everywhere and which are in great interest because
> > orphaned branches harder to find than orphaned links to different kind of
> > objects.
>
> And this is better, because? You win some performance, you loose the
> ability to use the refint checking. Where refint checking would shift
> some of the burden to the database engine, which will have the data
> local and is highly optimized for these kind of things.
>
> I know about the nested sets vs adjecency. All that does is prove your
> point that SQL databases are not ideal for storing graphs.
We still have problems with current tree routines. Unfortunately, two or
more times it was rewritten didn't get it better and it sometimes still
works not as supposed to be. See user reports for past two months related
to Repligard's fails with some object trees -- this is exactly connected
with underlying mgd_tree(). While refints are ghosts for us in dark future of
MySQL 4.0, this problem is what we have for past year or more. Nested sets
will help to eliminate it.
--
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
`Senior software developer and analyst for SaM-Solutions Ltd.`
---
Nov 21 20:58:58 alconost kernel: VFS: Busy inodes after unmount.
Self-destruct in 5 seconds. Have a nice day...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
