Re: Oracle vs. Microsoft

Southside Schmitty <schmittt5892_at_my-deja.com> wrote in message news:824qf6$g63$1_at_nnrp1.deja.com...

> SNIP<

> Have anyone used this architecture in any of your experience? Do you
> see many people doing MS/Oracle? If so, how are other people
> communicating between MS front ends and Oracle back ends? Are people
> using ODBC, OLE DB, or Oracle Objects for OLE?

Hi Tom,

I come from an environment where we have most of the elements you have described. We run THE mission critical system for a nationwide 24 x 7 x 52 policing organisation with an Oracle (8.1.5 as of 48 hours ago) backend and various Microsoft Tiers. We have DCOM, VB, ASP's, Terminal Server, IIS - the works. We run Oracle on DEC Alpha boxes running DEC Unix. We have 2500 or so users (across the country and in overseas posts) and a single Oracle database is used as the Corporate repository for almost every piece of information that the organisation develops. The system has won some awards because we are able to develop it quickly and cheaply and it works very well.

We have been using Oracle Object for OLE, but are moving some components to ADO (mainly where we want to be able to perform asynchronous operations).

>
> We have a development team testing some of these architectures and
> they are having some issues with their prototypes...speed (ODBC) and
> object issues (OLE DB) in the middle layer. With OLE DB they were
> having problems with "seeing" contents of an Oracle package.
>

I'm not surprised that they are having some issues, there are always some issues with any significant development so it becomes a matter of measuring which ones you can overcome and which ones you can't. It also becomes a matter of selecting an architecture that appears likely to contain the least number of insurmountable issues in the future. ODBC just isn't meant for enterprise strength applications and at the various times we have tried it for various tasks it has let us down greatly. Give OO4OLE a go and ADO seems to be very good if you set things up correctly.

> Because of "issues" they are attempting to push us into using SQL
> Server as a backend because it is too complex and cumbersome to do the
> MS/Oracle thing. And, I don't think that it's a good idea to have
> different database types for mission-critical, type 3 applications.
> I'm trying to gather some ammo to support my arguments.

It depends to a great extent on the size of the development, but if it is too complex and cumbersome to do the MS/Oracle thing, then I would have to question the class and or commitment of the developers. Both Oracle and MS have what can basically be described as best of breed products (no I'm not looking for a fight with that one, just making a generalisation!) that work very well, if you have the skills to use them to their potential. I agree, it is generally not a good idea to have different database types for mission critical applications. In fact, if at all possible, I would recommend the single database corporate repository type approach. Before too long you start to find that enhancements to your system become significantly easier because everything is in the one place. Eventually it gives you a certain kind of leverage on your data. Obviously, there are also certain efficiencies to be attained when only having to look after the one type of database as well.

>
> Is SQL Server robust enough? As robust as Oracle? How does it scale?
> For Oracle, the number of users that an NT box can support is miniscule
> when compared to Oracle on a UNIX box.
>

I am no expert on SQL Server, but from everything I have heard it is reasonably robust, it is just the servers that it runs on that tend to require rebooting more often than most UNIX box's. As you can imagine in a 24 x 7 environment, this isn't very acceptable. As for scalability, I don't believe that SQL server compares very well with Oracle once you start talking about significant numbers of users.

> In theory, by putting the middle tier in there, one could argue that it
> doesn't matter to an enterprise what the backend is because you are
> always shielded by the middle tier. What happens when people want to
> do data warehousing? If people are using a homogeneous database, do
> they usually grab data directly out of the database? Or do they use
> the business objects? Or do they crank data into text files and run it
> into the warehouse?
>

Data warehousing is a more complex issue - there are many ways to do this and it is a whole separate discussion. I don't believe that you can argue that it doesn't matter what is at the back end of your data warehouse as the data has to come from somewhere and some products just aren't going to do the job! The middle tier generally does not as such usually 'contain' the data and it still needs to be served from somewhere.

> And, lastly (for now), how do things like this affect a data center?
> DBA support, licensing, servers, database utilities like a defragger,
> etc.?

All these things are must simpler (and generally cheaper) with a homogenous DB environment.

Well, that has gotten rid of most of my opinionated bastard urges for the day. Hope it is of some use to you.

Rod J . Stewart Received on Thu Dec 02 1999 - 16:30:16 CST