Re: Best database for web backend on Linux?
This is a multi-part message in MIME format. ------=_NextPart_000_1711_01BDFC19.0D7C3DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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@yahoo.com>... Christopher Browne wrote:=20 On Mon, 19 Oct 1998 21:40:02 +0000, Evan Carew <ecarew@yahoo.com> = wrote:=20 >In response to your functionality requirements, watch out for=20 >row-level-locking. This feature was resisted for years in = Sybase for=20 >good reason, it sucks. Row-level-locking has been known to cut = the=20 >performance of an otherwise zipy Oracle server down to glacial = speeds.=20 >Generaly speaking, row-level-locking is regarded to be a design = flaw=20 >anyway, so you probably don't want to rate that feature too = highly.=20 And, on the other hand, trying to have large numbers of = processes update=20 DBs in the *absence* of row-level-locking can also 'suck badly.' = =20 There doesn't seem to be any "free lunch" here: =20 Not shure what you mean, generally, you let the database do what = it normally does best (be the traffic cop) by using triggers=20 to manage your relational integrity or arranging your object model = so you don't need locking.=20 =20 =20 - Page locking mandates rather less bookkeeping, and thus is = definitely=20 quicker, but locks more records, which is injurious to "other = users." =20 True, but by doing row level locking you need to remember you = have left the=20 relational database playing field and must be happy with the = consequences.=20 =20 =20 - Row level locking is more costly, but minimizes the amount of = "locked=20 data."=20 =20 Interestingly, Sybase is just about the only vendor that has = resisted=20 locking rows... =20 =20 --=20 ----=3D=3D-- _ / / \\ ---=3D=3D---(_)__ __ ____ __ / / /\\ \\ --=3D=3D---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=3D=3D=3D=3D=3D/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: http://home.msen.com/~carew =20 ------=_NextPart_000_1711_01BDFC19.0D7C3DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>I like row-level locking. = Everyone is=20 trying to get it into their dbms. It sure saves a tonne of coding = (grab=20 the sybase docs and read the timestamp work they suggest for high = availability=20 and avoid blocking, yuck).</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>If row-level = locking is=20 implemented well, it doesn't need to grind the database to a standstill, = maybe=20 if it's an afterthought/option to add, you might see that.</FONT></DIV> <DIV><FONT size=3D2>If that were the case, then why is Oracle able to = post such=20 fast benchmarks?</FONT> </DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Thor HW</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: = 5px"> <DIV>Evan Carew<ECAREW@YAHOO.COM> wrote in message <<A=20 = href=3D"mailto:362CC8F2.58860981@yahoo.com">362CC8F2.58860981@yahoo.com</= A>>...</DIV>Christopher=20 Browne wrote:=20 <BLOCKQUOTE TYPE =3D CITE>On Mon, 19 Oct 1998 21:40:02 +0000, Evan = Carew=20 <ecarew@yahoo.com> wrote: <BR>>In response to your=20 functionality requirements, watch out for = <BR>>row-level-locking.=20 This feature was resisted for years in Sybase for <BR>>good = reason,=20 it sucks. Row-level-locking has been known to cut the=20 <BR>>performance of an otherwise zipy Oracle server down to = glacial=20 speeds. <BR>>Generaly speaking, row-level-locking is regarded = to be a=20 design flaw <BR>>anyway, so you probably don't want to rate = that=20 feature too highly.=20 <P>And, on the other hand, trying to have large numbers of = processes=20 update <BR>DBs in the *absence* of row-level-locking can also = 'suck=20 badly.'=20 <P>There doesn't seem to be any "free lunch"=20 here:</P></BLOCKQUOTE>Not shure what you mean, generally, you let = the=20 database do what it normally does best (be the traffic cop) by using = triggers <BR>to manage your relational integrity or arranging your = object=20 model so you don't need locking. <BR> =20 <BLOCKQUOTE TYPE =3D CITE> =20 <P>- Page locking mandates rather less bookkeeping, and thus is=20 definitely <BR>quicker, but locks more records, which is = injurious to=20 "other users."</P></BLOCKQUOTE>True, but by doing row = level=20 locking you need to remember you have left the <BR>relational = database=20 playing field and must be happy with the consequences. <BR> =20 <BLOCKQUOTE TYPE =3D CITE> =20 <P>- Row level locking is more costly, but minimizes the amount = of=20 "locked <BR>data."=20 <P>Interestingly, Sybase is just about the only vendor that has = resisted=20 <BR>locking rows...</P></BLOCKQUOTE> <PRE>-- ----=3D=3D-- = _ = / / \\ ---=3D=3D---(_)__ __ ____ __ / / /\\ \\ --=3D=3D---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=3D=3D=3D=3D=3D/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: <A = href=3D"http://home.msen.com/~carew">http://home.msen.com/~carew</A></PRE= > =20 </BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_1711_01BDFC19.0D7C3DF0--