Re: Best database for web backend on Linux?

Posted in 1998

Evan Carew — Fri, 23 Oct 1998 15:54:23 +0000 — source: Informix-list mailing list archive (1991-1998)

--------------64639E82356A4ECC40A65905 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Williams wrote: > >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?? I'm not shure, but I think we have a language problem here. What I was suggesting was all that IO and ancellary CPU time spent managing RLL would go away and thus improve your performance/capacity. > > > 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! Hmm... Ok, no argument there. > > > 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. Obviously, if there is cross ownership of members in your two example sets mentioned above, naturally some form of locking will have to occur in order to enshure data integrity. Weather that's RLL or PLL is imaterial to your argument, its a phisical reality. > > > 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! Like I said earlier, no matter how you slice it there is going to be some locking in you life. The only question I am trying to raise in this discussion is how much are you willing to pay for it. If I understand your argument correctly, what you are saying is that you are willing to pay less for development now (presumably because your design simply isn't acceptable without RLL) and ignore the potiential cost of capacity/performance based upgrades later. -- ----==-- _ / / \\ ---==---(_)__ __ ____ __ / / /\\ \\ --==---/ / _ \\/ // /\\ \\/ / / /_/\\ \\ \\ -=====/_/_//_/\\_,_/ /_/\\_\\ /______\\ \\ \\ A proud member of TeamLinux \\_________\\/ email: carew@home.msen.com web: http://home.msen.com/~carew --------------64639E82356A4ECC40A65905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> David Williams wrote: <BLOCKQUOTE TYPE=CITE>>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??</BLOCKQUOTE> I'm not shure, but I think we have a language problem here. What I was suggesting was all that IO and ancellary CPU time spent managing RLL would go away and thus improve your performance/capacity.   <BLOCKQUOTE TYPE=CITE>     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!</BLOCKQUOTE> Hmm... Ok, no argument there.   <BLOCKQUOTE TYPE=CITE>     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.</BLOCKQUOTE> Obviously, if there is cross ownership of members in your two example sets mentioned above, naturally some form of locking will have to occur in order to enshure data integrity. Weather that's RLL or PLL is imaterial to your argument, its a phisical reality.   <BLOCKQUOTE TYPE=CITE>     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!</BLOCKQUOTE> Like I said earlier, no matter how you slice it there is going to be some locking in you life. The only question I am trying to raise in this discussion is how much are you willing to pay for it. If I understand your argument correctly, what you are saying is that you are willing to pay less for development now (presumably because your design simply isn't acceptable without RLL) and ignore the potiential cost of capacity/performance based upgrades later. <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> --------------64639E82356A4ECC40A65905--