Re: Best database for web backend on Linux?

From: Thor <thor_at_echidna.net>
Date: 1998/10/20
Message-ID: <70ijo9$r3i$1@news.bctel.net>

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
Evan Carew wrote in message <362CC8F2.58860981_at_yahoo.com>...

    Christopher Browne wrote:
    On Mon, 19 Oct 1998 21:40:02 +0000, Evan Carew <ecarew_at_yahoo.com> wrote:

>In response to your functionality requirements, watch out for
>row-level-locking. This feature was resisted for years in
Sybase for

>good reason, it sucks. Row-level-locking has been known to cut
the

>performance of an otherwise zipy Oracle server down to glacial
speeds.

>Generaly speaking, row-level-locking is regarded to be a design
flaw

>anyway, so you probably don't want to rate that feature too
highly.

        And, on the other hand, trying to have large numbers of processes update

        DBs in the *absence* of row-level-locking can also 'suck badly.'

        
        There doesn't seem to be any "free lunch" here:
        
        Not shure what you mean, generally, you let the database do what 

it normally does best (be the traffic cop) by using triggers

    to manage your relational integrity or arranging your object model so you don't need locking.

      
      
        - Page locking mandates rather less bookkeeping, and thus is 
definitely 
        quicker, but locks more records, which is injurious to "other 
users."
        
        True, but by doing row level locking you need to remember you 

have left the

    relational database playing field and must be happy with the consequences.

      
      
        - Row level locking is more costly, but minimizes the amount of 
"locked 
        data." 
        
        Interestingly, Sybase is just about the only vendor that has 
resisted 
        locking rows...
        
          
    -- 
----==--                       / /  \
---==---( )                   / / /\ \
--==---/ /   \/ // /\ \/ /   / / /\ \ \
-=====/ / // /\ , / / /\ \  /      \ \ \
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