Re: Best database for web backend on Linux?
--------------89F32CDFAEAB512DCAA83651 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Browne wrote: > On Mon, 19 Oct 1998 21:40:02 +0000, Evan Carew <ecarew@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 --------------89F32CDFAEAB512DCAA83651 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> Christopher Browne wrote: <BLOCKQUOTE TYPE=CITE>On Mon, 19 Oct 1998 21:40:02 +0000, Evan Carew <ecarew@yahoo.com> wrote: <BR>>In response to your functionality requirements, watch out for <BR>>row-level-locking. This feature was resisted for years in Sybase for <BR>>good reason, it sucks. Row-level-locking has been known to cut the <BR>>performance of an otherwise zipy Oracle server down to glacial speeds. <BR>>Generaly speaking, row-level-locking is regarded to be a design flaw <BR>>anyway, so you probably don't want to rate that feature too highly. <P>And, on the other hand, trying to have large numbers of processes update <BR>DBs in the *absence* of row-level-locking can also 'suck badly.' <P>There doesn't seem to be any "free lunch" here:</BLOCKQUOTE> Not shure what you mean, generally, you let the database do what it normally does best (be the traffic cop) by using triggers <BR>to manage your relational integrity or arranging your object model so you don't need locking. <BR> <BLOCKQUOTE TYPE=CITE> <P>- Page locking mandates rather less bookkeeping, and thus is definitely <BR>quicker, but locks more records, which is injurious to "other users."</BLOCKQUOTE> True, but by doing row level locking you need to remember you have left the <BR>relational database playing field and must be happy with the consequences. <BR> <BLOCKQUOTE TYPE=CITE> <P>- Row level locking is more costly, but minimizes the amount of "locked <BR>data." <P>Interestingly, Sybase is just about the only vendor that has resisted <BR>locking rows...</BLOCKQUOTE> <PRE>-- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: <A HREF="http://home.msen.com/~carew">http://home.msen.com/~carew</A></PRE>; </HTML> --------------89F32CDFAEAB512DCAA83651--