[dba-SQLServer] SQL Server versus Oracle

I have worked with MS databases in excess of 1 Tb and that is not your
problem. To give Oracle its due, in this respect alone, in Oracle you can
create namespaces that correspond to physical drives and that can also
respect FKs that span databases (or more exactly, name spaces). MS-SQL
cannot do this, sadly.

More generally, I would approach the problem using an automobile analogy.
85%+ of what most users require is encompassed in SQL Server and several
other alternatives, for zero dollars to many more, depending on vagaries.
There is no doubt about it, if what you want is security plus multi-TB
capability plus plus plus, Oracle and DB2 are the only games in town. And I
say this as a big fan of MS-SQL. There are things that MS-SQL cannot even
pretend to do. If these things are on your necessary-list, then MS-SQL falls
off your list of contenders. Let's take just a few examples:

a) I want 8 databases to tie together, some of which are separated by
firewalls etc. I want foreign keys to work across said databases. MS-SQL
cannot enforce FKs across db boundaries. Big problem. Oracle can, so from
that perspective this is an unimportant issue. Given that our client is
wedded to MS-SQL, then what do we do? There are several alternatives, which
I won't detail here, but suffice to say that all of them (that I know of)
are less than beautiful.

b) my principal db of concern is several PB (petabytes).

c) my db of concern must install jobs that on schedule grab data from
several other databases (for illustration, let's say said databases include
one MySQL db, one PostGres db and one Oracle db). I need to grab the new
data added to each of these since my last visit. I am well aware that this
is not impossible, and in fact not particularly difficult. My point is that
inhaling all this foreign data on schedule and guaranteeing the RI of the
imports is non-trivial. It can be done, of course. I have done it. That is
not the issue that I am attempting to present. The issue is that this is
non-trivial.

Many hours and many days might be expended making this sort of thing work. I
am happy to bill for thousands of hours, but that is beside the point.

The customer wants a solution not a description of the problem. That is my
current mantra.

Back to your topic:

Oracle has some serious technology that might be important only in an
organization with multi-TB databases, and several of these linked together
in a WAN or whatever. But to take just one thing O can do that MS-SQL
cannot, look at RI across databases. Expand that to view numerous dbs
located who knows where, but which maintain RI. There is NO way to achieve
that in MS-SQL.

Oracle blazes the relational path, without doubt. Other implementations try
to catch up.

On the other hand, MS-SQL does 99% of what most customers want to do. Call
MS the GM of software. Yes, you can buy an Aston-Martin and if that's what
you want, then GM wishes you well, but if you're looking for an inexpensive
solution then MS-SQL may be your ticket. (Or not. There remain alternatives
such as MySQL and PostGres, which are freely downloadable and can be
addressed using ODBC.)

It is also true that the era of relational databases may be seeing its
sunset. Implementations such as Cache raise the bar, and challenge the
precepts that underly Codd's theory and subsequent implementations.

I have played with Cache only a little; basically ported a complex app to
Cache and run it and discovered dramatic performance improvements. But OTOH
there is a whole new suitcase of stuff to lean, and I'm old and I don't have
all that many available brain cells left. I'd hate to think of myself as
going down, clinging to his precepts. I'd like to pretend that I'm a better
person than that, and that presented with a superior alternative, I am
willing to junk what I've learned and take the new path. Obviously, there is
reluctance, not all of which is bad... I've been led down a few garden paths
before, to no avail.

Late in life, IMO, Dr. Codd made some statements that I would call
questionable. IMO, he didn't perceive the Object problem, nor the GIS
problem, in their gory details. That's ok by me. It doesn't mean that he's
right, and it doesn't diminish his stature if he's wrong. It happens that I
deem him incorrect on these particular two issues, and also one other, which
I won't bother to get into now).

It is certainly possible to implement an O-O database within a classic
relational paradigm, but that isn't really the question. The question, IMO,
is whether a db such as Cache can deliver superior performance (along with
the assumed reliability etc.) to a SQL-based implementation of same.

To test this, we need a complex object model and at least a few million rows
of the various objects. It happens that I have a very good model for this
test, but it will take me some time to port the data to the Cache db.

My particular model concerns the pulp and paper industry. I think I can
sketch this one in my sleep, but I am interested to hear from developers who
have devoted similar time to particular domains.

A.


On 5/31/07, Elizabeth.J.Doering at wellsfargo.com <
Elizabeth.J.Doering at wellsfargo.com> wrote:
>
>
> Come to find out, I am speaking in 30 minutes about the virtues of SQL
> Server 2005 versus those of Oracle.  Given that my knowledge of Oracle
> could still dance comfortably on the head of a pin, I am frantically
> googling up details for my 'speech', and I would love to have your
> opinions
>
> I can easily say that we have already SQL Server and that Oracle is
> going to cost us $$$$$ that we hadn't budgeted for.  The thing I am most
> up against is a contention that 650 users are going to generate more
> data in a year or two than SQL Server can possibly hold.  I'm of the
> opinion that with a normalized database in a call center environment,
> users generating 10 or 12 records per call can go for years without
> seeing much if any slowdown.  Is this accurate?
>
> Oracle isn't being suggested for the production environment however.
> Oracle is being pushed for the REPORTING side of this system, for the 3
> or 4 analysts who will be looking at the long term performance of the
> folks in the call center.
>
> Is this making sense?  The production staff can live with SQL Server,
> but 3 or 4 analysts need the big bucks spent on Oracle for running their
> reports.
>
> Opinions, please?
>
>
> Thanks,
>
>
> Liz
>
>
> Liz Doering
> elizabeth.j.doering at wellsfargo.com
> 612.667.2447
>
>
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based on
> this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>