Re: Oracle versus MS Sql Server

I would just point out that performance tuning starts with the application designers, then involves the application developers, and THEN the DBA gets involved. DBAs can't tune what has been written poorly, or that which has been written oblivious to the quirks and features available from a *particular* rdbms.

You've freely admitted here that you know sod-all about Oracle. So do you know about the locking issues associated with foreign key constraints? Do you know about the advantages/disadvantages of deferrable constraints? Do you know the various partitioning options, and the syntax associated with them? Do you know about bind variables, shared cursors, cursor_sharing=similar? What about histograms?

How in God's name can you ever even *hope* to develop applications for Oracle without knowing that stuff and more? And guess who already knows it (or ought to, if they're any good)?... yup, the DBA!

Yet you state you'd resign if any of that was pointed out to you?!

Whatever happened to team work?

I've got to say that your approach is doomed, and you'd be better off writing applications for Access. I certainly wouldn't want to tune the mess you, with your somewhat idiosyncratic approach, are almost inevitably going to leave your DBAs.

HJR

--

Oracle Resources : http://www.geocities.com/howardjr2000
========================================


"Michael G. Schneider" <mgs_at_mgs-software.de> wrote in message
news:9r9r2k$6v9$02$1_at_news.t-online.com...


> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> schrieb im Newsbeitrag

> news:ttgqjg87pg2412_at_corp.supernews.com...

> >

> > That is definitely stupid. Very often my customers have bought software

> > developed by firms who don't know a damn thing about Oracle database

> > administration. This invariably results in programs following principles

> and

> > practices completely  unacceptable to any Oracle DBA who is worth a

grain


> of

> > salt. No primary keys, no constraints, every user has DBA privilege, end

> > user objects in the system tablespace, frequent ora-1555 errors because

> the

> > developer thinks he need to commit every individual record, people

> > installing the database on a PDC, I could write a book about it.

>


> Sorry, I do not know you. I certainly don't want to offend you. But have

you


> ever developed software? Do you have a formal education in developing

> software?

>


> I do not know a typical DBA's thoughts, but for example...

>


>  - defining the primary key

>  - defining constraints

>  - security concept

>  - commit strategy

>


> are tasks which a good software developer will know how to handle. And it

is


> HIS task to do such things. I would NEVER allow a DBA to modify the SQL

that


> creates the objects in the database (tables, triggers, views, stored

> procedures, ...).  For example primary keys and constraints are a direct

> result of my discussion with the future users of my software. These items

> are specified in the Requirement Specification, and they are part of the

> Data Model for the future database. No DBA is involved in this area.

>


> I have been educated how to do this. I have years of experience in this

> subject. I do not need a DBA's help for writing SQL.

>


> If a DBA should ever remind me that I have forgotten a constraint, I will

> quit my job. Then he, who is only looking at the finished software, has

done


> a better job than me, who has been discussing the requirements with the

> users for many weeks or months.

>


> Michael G. Schneider

>
>