Re: Indexing techniques for hierarchies

jraustin1_at_hotmail.com (James) wrote in message news:<a6e74506.0201031423.56b17c33_at_posting.google.com>...
> > After having reviewed a bit more of your site, I regret even making
> > the attempt to compare SQL Server to your XDb product. Comparing
> > performance is invalid for several reasons, the primary one being that
> > XDb is solely RAM-based and apparently doesn't interact with the disk
> > at all. It seems obvious to me that a single-user, RAM-only C++
> > library will sometimes be able to outperform a general-purpose,
> > commercial multi-user RDBMS with transaction control, concurrency
> > control and recovery features, particularly on benchmarks custom-built
> > to play to XDb's strengths, such as iterating over a linked list.
>
> Yes I agree it is an apple-to-orange comparision.
>
> > You have not convinced me that what you did cannot be represented as
> > an adjacency list.
>
> The following creates 1000 classes, each with properties of various
> data types. The properties of each class have are different name.
> An instance is made of each class.
> Each instance is the child of the previous.
> The time to traverse 1000 instances starting from the last child and
> copy the properties to local variables was approximately 4 ms (4176ms
> / 1000 Loops).
> See www.xdb1.com/Benchmark/8.asp for details.

You cut the following from my previous response, which applies perfectly to the code you provided.

• begin quote

>
> The benchmark provided is simlar to creating 10,000 tables each with
> the same fields. Why did I do it this way? Because the code to create
> the classes is simpler. If you ask I will recreate the benchmark with
> a different field name in each class to absolutely positively erase
> this doubt, but it won't affect the benchmark any.
>

Why not? Will it not affect the benchmark because you are effectively just getting "first boolean parameter", and "first double parameter", etc from your objects? If so, then the "field name" is nothing but a display convenience and can be factored out. I would add four label columns to my one table and be done with it.

• end quote

<snip your code>

What you provided is simply a disguised version of your original benchmark. Just because your classes have different names doesn't mean that there is now something magic about them that forces me to implement them as separate tables to duplicate what you have done. Your classes still all contain a boolean, double, date, and text field. You are still accessing them yourself by the equivalent of "give me the boolean field for this object". You ignore the names of the classes and fields; i.e. there is no special logic that discriminates between classes or fields on the basis of name, so effectively the names are just extra data that gets carried along. I would just add a column for "class name", and four more columns for "boolean name", "double name", "date name", and "text name", and do exactly what I did before.

I see what you are getting at, though. If your 1000 classes were truly different (i.e. they had different fields or were used in a different logical manner in your system) my single-table mapping would no longer work. Depending on domain analysis I might or might not be able to find some commonalities or use some tricks to avoid making 1000 tables, but certainly the iteration would not be as simple as my previous code. That type of benchmark, though, would have very little relationship to any real-world application I can think of.

I am not trying to attack XDb; you've obviously put a lot of effort into it and I'm sure it is very useful in certain problem domains. I object only to your using a contrived, limited benchmark and then trying to insist that competitors must use a crude, obviously unoptimized approach to implement the same logic under RDBMS. Received on Fri Jan 04 2002 - 04:17:08 CET