Re: Unknown SQL
Date: Sat, 21 Jul 2001 23:28:56 GMT
Message-ID: <ohWR6.776$_J2.188816413_at_radon.golden.net>
>> >All the relational equivalents that you posted are
>> >- unnecessary extra concepts to learn
>>
>> Not true.
>
>Usage of object databases is possible without knowing SQL or tables.
The usage of relational databases is possible without knowing Java, C++, Smalltalk, Tcl, Perl, Basic, Swahili or Arrays, Bags, Collections, Pointers, OID's, Containers, Callbacks, Constructors, Destructors, Inheritance, Delegation, Parent, Child, Aunt, Uncle, Cousin or Evil Step-Mother.
What's your point?
>> >- unnecessary extra code
>>
>> Not true.
>
>Please have a look at the example code further down this page.
>www.db4o.com/db4o/benchmarks.html
>We store complex objects with one single line of code.
>The relational equivalent took 2 hours to write.
It took you 2 hours to write:
"Insert Contract"
?!? Holy shit you're slow!
>> >- bad for performance
>>
>> Not true.
>
>Have a look at our benchmarks.
>www.db4o.com/db4o/benchmarks.html
>What is the reason for the drastic insert advantages?
There are no drastic insert advantages.
>Our program is still young and will be subject to further optimization.
>The others vendors can't be that stupid.
You overestimate vendors.
>Our performance advantages result out of the points I have mentioned.
You don't have performance advantages; you only have logical disadvantages.
>> I am still having trouble discerning. Is the untruth intentional or just
the
>> result of ignorance?
>
>I do usually back up my arguments.
>Your "Not true" is a little thin.
Well, when confronted with a salesman who obstinately refuses to confine himself to the truth, one must eventually take shortcuts. I don't mind being frank when the situation calls for it.
>> >> >Every concept, additional or renamed:
>> >> >- introduces standardization problems between vendors
>> >>
>> >> It introduces much more than standardization problems. Aho et al.
mention
>> >> that one of the most effective optimization techniques is algorithmic
>> >> replacement. How many object oriented languages or OODBMSs do you know
>> >> capable of algorithmic replacement? Every SQL product on the market
performs
>> >> this extremely potent optimization technique. Even small-footprint
products
>> >> like Lee's!
>> >
>> >I am sorry but I don't understand what you mean with "algorithmic
>> >replacement".
>>
>> It's simple enough as the name implies: replace one algorithm with
another.
>> For instance, replace a bubble-sort with a quick-sort. Or replace an
>> order-n-cubed algorithm with an order-n algorithm.
>>
>> In their famous compiler book (the Dragon Book), Aho et al. mention it as
>> one of the most effective optimizations and the one least likely for
>> compilers to actually achieve. SQL databases the world over achieve this
>> kind of optimization on a daily basis.
>>
>> Does your product support algorithmic replacement?
>
>I am still not sure what you mean.
When the answer is "no", just say "no". You don't need to feign confusion.
>Reading the above I would understand that either
>- hints can be added to queries for evaluation
Nope.
>or
>- code may be added to the database engine core
Nope.
>Could you please post a practical example and usecase what a user of a
>relational database would do?
Well, assuming an SQL-like syntax (yuck!), a user might execute the following query against the database:
SELECT region, AVG(salary) AS avg_sal, AVG(commission) AS avg_comm
FROM (
SELECT region, state, salary, commission, emp_id
FROM employee ee1 JOIN sales s1
HAVING SUM(price-cost) = (
SELECT MAX(profits)
FROM (
SELECT emp_id, SUM(price-cost) AS profits
FROM employee ee2 JOIN sales s2
WHERE ee1.state = ee2.state
GROUP BY emp_id
)
)
GROUP BY region, state, salary, commission, emp_id )
GROUP BY region
and the DBMS might choose an access path consisting only of table-scans today because the database has only one employee and only three sales. Two years from now, it might use a completely different algorithm because the table scans would involve many thousands of pages of file accesses where using available indexes would use only three or four accesses to pages that are likely cached.
Algorithmic replacement. No code changes. Sounds like a bargain to me! Yeah, baby! YEAH! Received on Sun Jul 22 2001 - 01:28:56 CEST