hi

I seach a benchmark comparing the performance of the pick system
with the SQL SGBD

thank you

An SQL SGBD and a MV SGBD are two different things. There is not any
comparation between different things. It's like compare a train with a
truck. Another thing is that both of them can make the same. It is not
a benchmark question.

"jra" <frelance (AT) sarenet (DOT) es> a écrit dans le message de
news:1145887429.221249.74850 (AT) e56g2000cwe (DOT) googlegroups.com...
but I need comparaer the performances of the two

"helios" <helios (AT) com02 (DOT) com> wrote:
<ramblin mode=on>

The same benchmark must be run on two systems in order to compare the
performance of each system, given that all else is supposedly equal.
Unfortunately standard benchmarks specifically define how databases
are to be built, and they define the test in terms that only a
relational database can satisfy. So MV environments cannot run a
current TPC test and therefore there is no apples-to-apples standard
benchmark.

It should be possible, given some time and funding, for the MV market
to define some apples-to-apples comparisons that are fair to both
relational and MV platforms. The mainstream database market has no
interest in doing this because of their technical and financial bias
toward the relational database model, and they probably would not
sanction this effort. The MV market doesn't seem to have interest in
doing this either due to its own smugness: Why generate numbers when
we all simply know that we have always had and will always have the
most efficient database model? And why rely on numbers when the only
things that are important are functionality and ease of use? And
since of course all MV apps are fully functional and easy to use and
develop, ipso facto, we don't need no stinkin benchmarks.

With alternative database models coming into vogue I'm hoping that the
people who define benchmarks will start to get away from specifying
implementation as part of the specs. (Easier said than done, because
if you don't tell someone how to implement the test they will get a
little too creative and do testing in such a way as to make the tests
worthless anyway.) We need generic benchmarks, defined for an
unknown, unspecified model, so that we can compare what databases do
and not how well specific databases do specific things. (Though those
tests are valid in their own right.) IBM works with companies to
define standards for all sorts of things. It would be nice if they
put similar effort into creating cross-DBMS benchmark specs that
everyone could follow, including MV tests for U2 and others,
relational tests for DB2 and others, and tests for XML datastores and
hierarchical models like Cache'/MUMPS. I'll bet Dawn would have a
comment on this.

Tony
TG@ removethisNebula-RnD.com

helios wrote:
I have done both research and brainstorming on this very question to
come up with a way to do such a test. I am not being excessively anal
when I suggest that In order to have a meaningful comparison, you would
need to start with the same problem domain, implement solutions that
result in at least roughly the same level of acceptance from end-users,
and then test a suite of queries and updates on the same (type of)
machine (with the same other processes running other than the dbms).

If you were to use benchmarks on the same number of rows as records,
the same number of tables as files, the same number of attributes, the
same number of active users, and similar Pick query statements as SQL
statements, or possibly the same size (in disk) database, you would
fail to have an adequate comparison (at least not one that would
convince many people who know both environments).

I have a project on the back burner that would include such a test. I
have the start of a specification for a "generic" application. If you
do find some other way to figure out a meaningful performance
comparison, please let us know. Thanks. --dawn

Tony Gravagno wrote:
This is similar to what I think I want to do when I grow up. I have a
significant plan that is not specific to MV, SQL or anything else, but
would provide a means for comparisons. It is not specific to
performance, focussing at least as much on the time it takes to develop
the software, time/cost of maintaining software over time, user
satisfaction, etc. I have some of the strategy designed in detail, but
have the project on the back burner. I'll pull it off that burner at
some point in order to decide whether to pursue funding or not.
Someday, sometime.

Agreed.

Yup.

<self-indulgent rambling>
Hey, yes, as a matter of fact, I'll add that in March I was in a
downtown Chicago penthouse for a few days overlooking the lake and the
city discussing how to get and fund "software development comparisons"
with a lawyer (OK, she is my cousin) who was asking me hard questions.
She was starting to make me believe in it. Then I returned to the
biggest pork producing county in the US where the best prepared salads
in town come from McDonalds and you don't need to use your blinker
because everyone knows where you are headed, and I went back to doing
same old, same old. Somehow I think bigger or have more optimism when
in the city. But if anyone is interested in funding these efforts...
</s-i r>

Cheers! --dawn

Why not compare the speed of the SQL database using MV Queries?

On the whoile, I be;lieve that whilst most mv system "have" SQL, they
are not going to be the most performant implementations, but by & large
this isn't an issue as the mvDBMS in in place to run a specific
vertical application, and then SQL "window" is simply an afterthought,
or requirement to interface with a 3rd party system

Ross Ferris wrote:
There will need to be benchmarks for XQuery, I would think (maybe there
are already?). I would also guess that there will be benchmarks
comparing XQuery queries to SQL queries. It seems like we ought to be
able to be able to play in the sandbox once that is in place.

It would be better if IBM would help define the benchmark with both
their new database that supports xml queries and their MV products.
But the fact that they started with their SQL dbms's when doing an XML
implementation shows that they still think in terms of the relation
model.

Cheers! --dawn