Re: Informix: Please buy Borland

Let me preface this posting by saying that I am *not* interested in converting anyone from Informix to Sybase. As a matter of fact, I'm planning on taking two Informix classes next week to learn about Informix. My posts regarding Sybase are more for educational purposes rather than flame bate. I have *no* interest in starting a flame war... In article <33156747.9679808@gate.idg.no>, Nils.Myklebust@idg.no writes: > > They tried (or intended to try) to parallelize thair database by > running multiple instances of the engine and have a front end that > split sql statements into parts that would be sent off to different > engines. This couldn't work and didn't. If parallell queries > aren't available yet, it's another indicator that Sybase is behind > and have to spend their effort in these areas. Parallel queries, to the best of my knowledge, are available in the 11.g release. I don't know about the specifics regarding implementation however I suspect that what you've heard is not necessarily correct. > How can they follow up on the now important issues such as creating > an object relational DBMS? This is being worked on as far as I know... just read in c.d.s yesterday... > :yes this is some what true... although the added overhead of row > :level locking vesus page level locking is rather argumentative... > > It is not. For some types of applications page level locking simply > doesn't work or at least requires extensive design effort to make > it work. I've yet to see such an application. How about an example? Below is a purr-fect example on "bad design"... Aditionally as far as I know the SAP/R3 system doesn't run on a database without row level locking. That may be their design error, but that's not particularly helpfull to Sybase. > :> Sybase simply doesn't have good enough designers. > : > :This sounds extremely subjective... > > Yes, but it's based on the technical problems they have had lately. Lately? On System 11? Care to cite the supposed technical problems? > System 10 was a disaster and they still have problems in that they are > behind in several areas. I wouldn't categorize System 10 as a disaster but it certainly wasn't a showboat. That's for sure. This is also subjective so you may say disaster and I may say problematic. > :I tend to believe that their named cache functionality is something > :that Informix/Oracle will be bolting on. It doesn't make sense to > :have a single buffer cache for VLDB with huge gobs of shared memory: > :> 2GIG > > May be. Sybase have done some nice things as well. Sybase has done quite a bit of nice things... let me explain some more on this named cache notion. It's really neat actually. The idea is to take your buffer cache (shared memory segment) and partition and name it. Each named cache can have one to two (in practice) I/O pools. An I/O pool can be 2K, 4K, 8K, 16K. Typically what folks do is create a named cache for the log with a either a 4K/8K pool size so that larger I/O's are used for the log. This *greatly* improves throughput as all write-intensive RDBMS's serially write to the log. Neat eh? -- Pablo Sanchez | Ph # (415) 933.3812 Fax # (415) 933.2821 pablo@sgi.com | Pg # (800) 930.5635 -or- pablo_p@pager.sgi.com =============================================================================== I am accountable for my actions. http://reality.sgi.com/pablo/Sybase_FAQ