Re: Oracle comparison

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 18 Jun 2002 22:31:01 -0500
Message-ID: <ubsa74vx9.fsf@hotpop.com>

On 18 Jun 2002, nospam_at_nospam.com wrote:
> Daniel Morgan wrote:

>>
>> Generic Poster wrote:

[...]

> Well.....it was more the case that we were avoiding the commercial SW
> option, or attempting to avoid it. That is why we recommended
> PostgreSQL. But we were curious about what the advantages of using
> the commercial stuff were, and wanted to broaden our knowledge of this
> area. The problem would have been that I do not have many employees
> who know much about the commercial db's. I have a few guys who have
> worked with MS SQL, and, in answer to your question, I do have one
> employee who says he has experience working on Oracle. :) So, that
> was why Oracle was in the game. If the client would have decided on
> Oracle, I would have had that worker build it. No, *I* don't know
> Oracle very well but I believe my worker knows it pretty
> well....anway, he lists it on his CV, and he has Oracle installed on
> his development box at home. :)

Whee! He has been Oracle certified as well? Yeah. Sign him up. He must be an expert! He installed it at home.

If this were the case then I would be a J2EE expert.

> You are correct, if we had no Oracle experience, we may have had to
> blow off the job if the client insisted on a solution. Thx for your
> comments, though. Some of my workers here tell me, "All these SQL
> db's are pretty much the same. If you know SQL, you can work with any
> of them."

This is true to some extent. You can code SQL that will run against just about any SQL database. But, this doesn't mean you have the expertise to build an enterprise solution with Oracle as the backbone, by any stretch of the imagination.

> Looks like this is not true.

Correct.

> How can you, in good

>> conscience, think you could possibly create a good product in Oracle?

>
> We weren't really considering it. We recommended PostgreSQL. We are
> *curious* about learning more about Oracle. That said, I do have a
> programmer who claims he can do Oracle programming. :) His experience
> is Oracle 8i. And he does have an Oracle dev box at home. :)

Come on. Curious? Your company is curious about Oracle?

> Do

>> you understand multiversioning? Do you understand Oracle's
>> transaction and locking models?

>
> You have to ask my programmer. These are the things that I would like
> to learn about myself. I basically am just a capitalist who does
> nothing more than funds and runs this company here; my IT knowledge is
> somewhat limited (not a programmer). My employees are the ones who
> know about this stuff. That said, considering it is my company, I do
> have to know a bit about that stuff.

Here is a _fundamental_ difference between Oracle and, I believe, all the other DBMS vendors.

Transaction1 starts at time1 updating RowA.

A user asks for RowA before transation1 is committed. That user gets the data of RowA before time1. Their query doesn't wait for the transaction to complete, or fail or ... They get the previous version of RowA. No dirty reads, no concurrency issues, ... Just show me the committed data, whenever I ask for it. My analogy is sort of like source control systems. Whatever is in the source control should always be able to be viewed. But, if the other database vendors architected source control systems, then, when someone checked out a file, no one else could see it until they checked it back in. Therefore, to build the latest version of the code, _all_ developers would have to checkin their code. With Oracle, anybody at anytime can build the latest version of the code no matter how many files are currently checked out... The other database vendors would actually go so far as to let you look at the hard-drive of the developer who has the file checked out so you can at least move on (dirty reads).

If you think about the extra management layers needed to manage all those developers checking in code for somebody's latest build, it is similar to the extra code you'll have lying around dealing with the fact that a particular row is locked for update and therefore can't be read.

>> Given that the likely outcome of this is that you will just make a
>> huge and expensive mess ... let me suggest Microsoft SQL Server to
>> you as an excellent choice.

>
> No, we are sticking with PostgreSQL. We know we can do a nice
> PostgreSQL database. We have done them before. :) And, no, they were
> not huge, expensive messes. :)
>
> You really don't know what kind of a company I run here. We blow off
> work all the time because we either don't have the skills, or don't
> have the skills at moment, or the present crop of employees has poor
> skills in that area, or whatever......I don't like to do crappy work,
> unlike so many of my competitors.

This is the best statement I've heard you make.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Received on Tue Jun 18 2002 - 22:31:01 CDT