Re: Best database for web backend on Linux?

In article <362F73BF.D80F5F14_at_yahoo.com>, Evan Carew <ecarew_at_yahoo.com> writes
>Jed,
>
>Jed S. Baer wrote:
>
>> In article <362DE1DF.CEFF3539_at_yahoo.com>, ecarew_at_yahoo.com says...
>> > 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,
>>
>> Indeed! As an Oracle DBA/Developer, I can tell you that none of my
>> projects fit this category, neither did they suffer from performance
>> problems.
>
>Glad to hear it! I'll bet you tho if it were not dependant on RLL (sorry but
>I'm getting tired of typing row level locking all the time) one if not both of
>the following would happen:
>1. The cost of hardware for supporting the application would go down due to
>lower resource usage

   What you mean 1Mb of memory to hold lock info costs a vast amout of    money (Inofmrix lock =43 bytes, just how many locks do you need?)

>2. The capacity and performance of your already zipy application would increace
>noticably.
>

   What with people wait for locks on data rows they are not even    touching?? How can that be faster??    

   You assume no contention for the same page which not not valid...    Usert typically access the 'current' data a lot in a database and    the 'historic data' only when running big end of month/end of period    reports. 80/20 rule 80% of users access 20% of the data!

   SQL was deisgned to be set based, hence my updating my set A should    not affect your ability to update your set B. With page level locking    this occurs.

   Also SQL is suppose to handle the logicla data model and not worry    about the physical data structures. Page level locking means that the    physical structure 'bleeds-through' into the logical data model...    Nasty! The whole idea of SQL is to hide the physical representation    of data, not show it again within the locking strategy!

>>
>>
>> > All it
>> > takes is one well
>> > trained DBA/App Developer to come by and make it go 20x faster to really
>> > embaras someone.
>>
>> Now, you've got it. The question of database design and development can't
>> be answered by focusing on only lock strategies. Yes, they're important,
>> but only part of the picture. And database tuning is a multi-faceted
>> discipline.
>
>Good point. If I could add to that with some of my own anecdotal experiance,
>The presence of RLL often suggests to me that the project is being managed by
>VB programmers. Not that I have anything against VB, but it is all too often
>used as a development tool by the inexperienced programmer. While cleaning up
>the RLL in this case might cure some of the performance bottleknecks, there are
>bound to be scads of other problems in the design that weigh it down.
>
>>
>>
>> >
>> > Christopher Browne wrote:
>> >
>> > > >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.
>>
>> I'm curious, by whom? Certainly not Oracle corp.
>>
>
>Duh! [sais the Oracle marketing department]
>
>--
>----==-- _ / / \
>---==---(_)__ __ ____ __ / / /\ \
>--==---/ / _ \/ // /\ \/ / / /_/\ \ \
>-=====/_/_//_/\_,_/ /_/\_\ /______\ \ \
>A proud member of TeamLinux \_________\/
>email: carew@home.msen.com web: http://home.msen.com/~carew
>
>
 

-- 
David Williams

Maintainer of the Informix FAQ
 Primary site (Beta Version)  http://www.smooth1.demon.co.uk
 Official site                http://www.iiug.org/techinfo/faq/faq_top.html

I see you standin', Standin' on your own, It's such a lonely place for you, For 
you to be If you need a shoulder, Or if you need a friend, I'll be here 
standing, Until the bitter end...
So don't chastise me Or think I, I mean you harm...
All I ever wanted Was for you To know that I care