Re: Best database for web backend on Linux?

Posted in 1998

Evan Carew — Wed, 21 Oct 1998 13:30:08 +0000 — source: Informix-list mailing list archive (1991-1998)

--------------1BB4FF73D723362E83EAD2C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, Read my earlier posting on this topic for an example of how to get arround this problem ans save your self a boatload of performance. I've noticed there seems to be resistence to the notion that row level locking is not as usefull the marketing people would have us think. To put it in perspective, The last three organizations I have been contracted to where I was called in to fix performance problems associated with row level locking issues, at least the manager and usually one or two of the top developers were "transferred" off the project when it was shown how much faster their product could have been running had they never pushed for row level locking. I'm not saying that row level locking is a bad idea for all projects, especially if you want to put together some kind of brain dead demo, or need to get something to work TODAY and have every intention of cleaning it up later. Just remember that if one of these projects ends up mission critical you better sell it as an interum product to CYA. All it takes is one well trained DBA/App Developer to come by and make it go 20x faster to really embaras someone. 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.' > -- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: http://home.msen.com/~carew --------------1BB4FF73D723362E83EAD2C5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> Chris, Read my earlier posting on this topic for an example of how to get arround this problem ans save your self a boatload of performance. I've noticed there seems to be resistence to the notion that row level locking is not as usefull the marketing people would have us think. To put it in perspective, The last three organizations I have been contracted to where I was called in to fix performance problems associated with row level locking issues, at least the manager and usually one or two of the top developers were "transferred" off the project when it was shown how much faster their product could have been running had they never pushed for row level locking. I'm not saying that row level locking is a bad idea for all projects, especially if you want to put together some kind of brain dead demo, or need to get something to work TODAY and have every intention of cleaning it up later. Just remember that if one of these projects ends up mission critical you better sell it as an interum product to CYA. All it takes is one well trained DBA/App Developer to come by and make it go 20x faster to really embaras someone. Christopher Browne wrote: <BLOCKQUOTE TYPE=CITE>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.'  </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> --------------1BB4FF73D723362E83EAD2C5--