Re: Best database for web backend on Linux?

Interesting. I've done lots of Sybase work, and found I could tune Oracle to be faster than Sybase in everything except for loading a clustered index in reverse order where the data was already pre-sorted. If left to a random distribution it was faster than Sybase. Also if you push sybase for extended periods of time, their delayed mechanism really starts to hurt you.

For accounting applications I found the dirty read to be a great problem when doing trial balances.

I also found the math module in Sybase to SUCK! I mean we got different answers when running the exact same stored procedure on DEC VMS, UNIX, etc. It uses the host mathlibs, which on VMS aren't all that hot.

Now if you take the benchmark that "Corporate Computing" does, you'll see that Oracle still kicks ass. But you can always slow down anything, if you try hard enough.

    Corporate computing takes an application from a real business, loads it onto any rdbms with guts to enter the contest, and then runs typical queries, indexing, loading, inserts, etc, that the business does in a regular work year.
Now that's a real bench mark. Sun has a cool benchmark, as does Qualcomm, and Oracle always does well in those environments.

REGARDLESS, having to write 40% less code, because the rdbms does row-level locking for you is worth it to me.

Thor HW
Evan Carew wrote in message <362CE8BE.53F4CDB0_at_yahoo.com>...

    Good question Thor. It is important to read those benchmarks very carefully. When Sybase and Oracle came to my job site to do a bake off, we noticed they were utilizing a special setting for their server designed for the benchmarks. This setting of course disables row level locking. When we forced both vendors to do "out of box" installs the picture changed substantially. When we also did feature by feature comparison, it was interesting to note just how badly you could make Oracle perform. As a programmer somewhat familliar with the history of the two products this didn't suprise me overly much. Sybase's history includes being the first fully client server database whereas Oracle's includes being a reasonable mainframe based database that converted to the client server model (some would say not very well).

    Should you ever have the chance, you want to force a vendor to do thourough stored proceeduretesting while someone runs a large query where the result set is guaranteed to be larger than the memory pool alloted to the data server. You also want to be shure you review all the database performance settings so they don't manage to pull the wool over your eyes (you would hope this would go without saying). The last time I did this, it managed to crash the INFORMIX box (a bug in their implementation of stored procedures) and really sloooow down the oracle box. The sybase server by comparison didn't sag too much. You also want to get a feeling for what feature aren't shared by all the servers, for instance, Sybase has the ability to partition its memory pool so the neat trick mentioned above will have no effect on performance. Another issue is that there are certain SQL dvanced optimizations that are impossible with ORACLE . For refrences to this, see Optimizing Transact-SQL Programming Techniques by Dr. David Rozeshtein & Anatoly Abramovich .     

    Thor wrote:     

     I like row-level locking. Everyone is trying to get it into their dbms. It sure saves a tonne of coding (grab the sybase docs and read the timestamp work they suggest for high availability and avoid blocking, yuck).If row-level locking is implemented well, it doesn't need to grind the database to a standstill, maybe if it's an afterthought/option to add, you might see that.If that were the case, then why is Oracle able to post such fast benchmarks? Thor HW           

    --
----==-- / / \
---==---( ) / / /\ \
--==---/ / \/ // /\ \/ / / / /\ \ \

-=====/ / // /\ , / / /\ \  /      \ \ \
A proud member of TeamLinux \         \/
email: carew@home.msen.com web: http://home.msen.com/~carew
      

--
Received on Tue Oct 20 1998 - 00:00:00 CDT