Re: Oracle versus MS Sql Server

 I agree that you don't need to know about optimizing tablespace layout etc. But Oracle and SQL server are two very different beasts and application optimization in one is not the same in the other. Common mistakes most application developers make is not using bind variables in Oracle (e.g. ODBC doesn't, the parameterized queries are string substitution, not host variable bindings.), they don't reuse the cursor and just rebind, instead they build the cursor each time etc. The difference is huge in terms of performance.(repeated use of the cursor) This especially shows up in scalability tests (usually when the client uses the application.). Also the sql is different and the optimizers act differently - in SQL you can usually do something more than one way. Additionally, the most common mistake is retrieving the same data multiple times - which is non-database dependent.

Also given both databases I would write the application differently for each. Certainly I would attempt to hide the differences in an db access class, but sometimes you just can't.

Jim

"Michael G. Schneider" <mgs_at_mgs-software.de> wrote in message news:9qr6e6$54o$04$1_at_news.t-online.com...
> Hi Jim,
>
> I do understand your point, although I do not quite agree with it. Of
course
> I do know anything (not really anything) about SQL and OLE/DB. And I think
> this is enough for creating a great application. For example, I do not
know
> anything about optimizing the tablespace layout or about caching in the
> database. And I think this knowledge is absolutely not necessary for me.
For
> an application database subjects as "normalized tables", "foreign key
> relationsships", "constraints", "indexes" are more important.
>
> "Poorly designed applications" as you call them, will always have
problems.
> But in my opinion an application can be perfectly designed on the basis of
> SQL (either MS or Oracle) and the application code.
>
> About 40% of my applications have been targeted at both databases, Oracle
> and SQL Server. Certainly the SQL is different, but I did not need any
> specific DBA know-how for developing these application. That knowledge may
> be with one or the other DBA.
>
> Michael G. Schneider
>
>
> "Jim Kennedy" <kennedy-family_at_home.com> schrieb im Newsbeitrag
> news:lG5A7.30443$Zb.13770728_at_news1.sttln1.wa.home.com...
> > Michael,
> > If all you want to do is set Oracle up so you can write an application
> etc.
> > Then certainly the 8i series and later is basically run setup.exe.
> > (Assuming you haven't installed it a bunch of times before hand.). On
the
> > other hand if you want to use all the administrative bells and whistles
> etc.
> > then that really is not in the application developer domain. Yes,
Oracle
> > could make those things easier and constantly strives to do so (and
does),
> > but at some level if you want to muck with administrative stuff you are
> > going to have to either learn it, get assistance from someone, or get
> > someone else to do it.
> >
> > It is rather naive though to developed an application and not really
have
> > someone with DBA skills available. (It is possible to be both, but we
are
> > talking quite a lot of experience which most people don't have in both
> > domains.) Being someone who has extensive experience in both "camps" I
> have
> > seen time and time again application developers make the same mistakes
> over
> > and over again out of ignorance (not stupidity or laziness, just lack of
> > database experience). Poorly designed applications that use a database,
> and
> > there are a lot out there often cannot be fixed by the DBA no matter how
> > competent they are. Performance and scalability are part of everyone's
> job
> > at every step and not something to try to tack on later.
> > Jim
>
>
>
Received on Sat Oct 20 2001 - 11:22:36 CDT