I'm looking for some brief summaries or comparisons that support an IT
management decision to implement a new system with SQL Server as the
database and not an alternative db (oracle, informix, whatever).
Specifically looking for things like return on investment (ROI) and total
cost of ownership (TCO) in addition to development costs, productivity
comparisons, and runtime performance.

Any links or suggestions for specific other reference material are
appreciated.

Ah - you're looking for marketing propaganda!  Well, there's plenty to
be found on the Microsoft SQL Server website:
http://www.microsoft.com/sql/prodinfo/compare/default.mspx

But you do realise, don't you, that it's going to be biased?  I'm sure
Oracle, IBM & Sybase all have their own propaganda pages convincingly
describing why SQL Server was designed & written by Satan and their own
product is the bee's knees.

Also, don't get me wrong, I love SQL Server and have worked exclusively
with it for years, but it sounds like you're fitting your requirements
to your product rather than the other way around.  Shouldn't you start
with your business requirements (like cost, functionality,
infrastructure, integration with dev products, support, current
expertise, training, documentation, etc.) and then ask "now, which RDBMS
product fits our requirements best"?  Of course, the answer will
probably be "SQL Server 2005" (tongue in cheek) but you should at least
pretend to be doing a fair assessment of the products on the market
(don't worry, SQL Server can hold its own).

Also, if you want performance & cost comparisons, the TPC benchmarks
(http://www.tpc.org) are a fairly commonly accepted, industry standard
benchmark for RDBMS manufacturers; both OLTP (TPC-C) & OLAP (TPC-H). 
Again, finding appropriate TPC benchmarks to compare (Oracle vs. SQL vs.
DB2 performance) depends on your requirements.  Currently IBM holds the
worlds fastest super-dooper throughput record (actually, it's about
twice as fast as it's nearest competitor), but 99% of people out there
are not interested in spending US$16 million on the infrastructure
required to host their single DB app.  More people would be looking at
$1,000 - $50,000 for their 2-way or 4-way DB box & storage that will
host their 100 in-house DB apps.  Again, it comes down to business
requirements.  (But in the lower-end of the market (single proc or dual
proc Dell servers for example) SQL Server is pretty hard to beat on
value for money (price/performance), mostly because the SQL licensing is
significantly cheaper than its competitors and they throw all their
features in under the 1 license rather than sell them separately.  And
the high-end results (up to 1.2 million tpm) shows SQL Server is up to
the task in terms of scalability and handling load.)

Good luck with your management sales pitch.

Show quoteHide quote

RE:
<< mostly because the SQL licensing is significantly cheaper than its
competitors >>

Now we're talking!

I understand and appreciate your [high-minded] recommendation to start with
requirements, then proceed with a completely Unbiased evaluation of the
available products and find the best match based on technical merits. That
can realistically happen when (1) time constraints are not present and (2)
budget is unlimited.

But I'm dealing with time constraints, a limited budget, and of course the
usual IT politics. The shop is actually an Oracle joint and they blindly
want to go with Oracle. I just want to offer an alternative AND back up my
recommendation with more than just my opinion. Hopefully there will be more
than just cheaper licensing. I must make my pitch to non-technical business
managers. So I'd like to come up with more financial and HR-related
arguments in favor of SQL Server (cheaper training, shorter learning curve
{on the product, not relational design fundamentals of course}, better
out-of-the-box tools, lower setup costs etc) which may be "common
knowledge". I'd like to find some external (outside of my head) resources I
could point them to.

Thanks!










Ah - you're looking for marketing propaganda!  Well, there's plenty to be
found on the Microsoft SQL Server website:
http://www.microsoft.com/sql/prodinfo/compare/default.mspx

But you do realise, don't you, that it's going to be biased?  I'm sure
Oracle, IBM & Sybase all have their own propaganda pages convincingly
describing why SQL Server was designed & written by Satan and their own
product is the bee's knees.

Also, don't get me wrong, I love SQL Server and have worked exclusively with
it for years, but it sounds like you're fitting your requirements to your
product rather than the other way around.  Shouldn't you start with your
business requirements (like cost, functionality, infrastructure, integration
with dev products, support, current expertise, training, documentation,
etc.) and then ask "now, which RDBMS product fits our requirements best"?
Of course, the answer will probably be "SQL Server 2005" (tongue in cheek)
but you should at least pretend to be doing a fair assessment of the
products on the market (don't worry, SQL Server can hold its own).

Also, if you want performance & cost comparisons, the TPC benchmarks
(http://www.tpc.org) are a fairly commonly accepted, industry standard
benchmark for RDBMS manufacturers; both OLTP (TPC-C) & OLAP (TPC-H).  Again,
finding appropriate TPC benchmarks to compare (Oracle vs. SQL vs. DB2
performance) depends on your requirements.  Currently IBM holds the worlds
fastest super-dooper throughput record (actually, it's about twice as fast
as it's nearest competitor), but 99% of people out there are not interested
in spending US$16 million on the infrastructure required to host their
single DB app.  More people would be looking at $1,000 - $50,000 for their
2-way or 4-way DB box & storage that will host their 100 in-house DB apps.
Again, it comes down to business requirements.  (But in the lower-end of the
market (single proc or dual proc Dell servers for example) SQL Server is
pretty hard to beat on value for money (price/performance), mostly because
the SQL licensing is significantly cheaper than its competitors and they
throw all their features in under the 1 license rather than sell them
separately.  And the high-end results (up to 1.2 million tpm) shows SQL
Server is up to the task in terms of scalability and handling load.)

Good luck with your management sales pitch.

Jeff wrote:
Why would the training and/or hiring requirements for SQL Server be
cheaper if you already have skilled people who can support and develop
on Oracle? Frequently, the value of the human capital invested in the
software is one of the most significant arguments AGAINST switching
products.

RE:
<< Why would the training and/or hiring requirements for SQL Server be
cheaper if you already have skilled people who can support and develop on
Oracle? >>

Good question with an equally good answer: It's a big company and their
central IT group is "the Oracle joint". The department I'm looking to help
is migrating their own app [developed in-house without the assistance of the
central IT group] from MS Access to SQL Server (or Oracle) *without* the
assistance of the central IT group. So the particular department I'm working
with is looking at some training on the enterprise class db product of their
choice. So basically the "cultural mindset" of the company as a whole is
Oracle with practically no advocates of any other product.... The management
of the department I'm working with wants to start with a clean slate and
make decisions based on the merits of the products (including non technical
merits). They are suspicious of the "good 'ole boys club" they perceive is
the case in central IT.

-Jeff



Show quoteHide quote

ooooohhhh, black ops :)  Bad mojo all around.

Seriously, I've been on both sides of the equation, and in hindsight,
nobody wins.  It's sounds like your organization has some deeper issues
than just choosing a database platform.

If I were you, I'd get my resume ready.  There are better companies out
there.

Stu

Jeff wrote:
Show quoteHide quoteJeff wrote:
Show quoteHide quoteYou consider that a "good answer"? Oh boy! Far be it from me to get
involved in your corporate politics but I'd say that if your business
units have so little confidence in your IT operation then you have far
bigger problems than just choosing a new DB. This isn't the way I'd
want to solve them.

Show quote Hide quote Thread lightly here. Centralized IT don't usually care about your small
Access app. But as soon as a 'real' DB server goes up, they'll notice and
sparks will fly. Is that department ready to assume /all/ IT support???

Likely scenario: The app goes down. Somebody calls central IT for
support, after they finish laughing, they inform the department that they
will not support that DB config. Some heads will roll, likely yours for
recomending a non-Oracle solution. Get central IT's help, support and
blessing. Or back away slowly.


Show quoteHide quote

Jeff,

In my opinion, this is the number one reason to continue using Oracle;
if you've got the skill set in place already, then it would be very
expensive to change.

That being said, if your company has a requirement to do any sort of
cross-platform data integration, I think DTS in SQL Server is a tough
option to beat.  Oracle's philosophy about other dtabase platforms has
been "what other database platform?" for a long time. 

Stu

Show quote Hide quote Have to agree with David here. If you already have Oracle, that's a pretty
low, if not no, cost implementation. You have the server, you have the DB,
and presumably you have staff on site who are trained to support Oracle.
Introducing SQL Server means new hardware, software, and training.

Just my 2 cents worth.

Our application must support running on Sql Server and Oracle for over 12
years on multiple versions.
We find that Oracle gets about half the performance on twice the hardware as
SqlServer on average - mileage differs depending on how you access it -
queries verses inserts, updates, and deletes. We find Oracle's insert
performance lacking.
..
We also find that we typically have more development issues with Oracle than
we do with Sql Server.
Sql Servers has better tools out of the box than does Oracle.

Our developers prefer to work with Sql Server hands down over Oracle due to
Sql Server being less painful, better tools,  and faster so they spend more
time coding and less time waiting and fighting issues.

Moving databases between servers is easer with Oracle than with Sql Server.

Sql Server handles integrated security (if you need that) very well, but
Oracle can be spoofed and is not really secure and you have to fall back to
normal database security with Oracle to be on the safe side

In order to get good query performance on Oracle you have to hand craft your
SQL much more carefully as it's query optimizer is not on par with that of
Sql Server. This is argued to be a good thing and bad depending on if your a
DBA or a programmer. On Sql Server, many web application access it via store
procedures because the optimizer is very good but expensive and using a
stored procedure is only optimized once. On Oracle, the optimizer is pretty
dumb but much cheaper so you normally don't resort to the stored procedure
track as often but like I stated before, the queries must be finely hand
tuned as just ordering a join clause differently can make a 4 min query run
over 5 hours (we see this a LOT on Oracle, but never have the issue on Sql
Server).

In a production environment, Oracle costs much more and must have much
heafter hardware to achieve the same performance on 1-4 processor boxes than
does SQL Server.

Both seem to be extremely solid and reliable once in production and we don't
typically have issues with either database platforms in a production
environment.

Tony



Show quoteHide quote

Tony wrote:
Are you really qualified to make this judgement? The ridiculous passage
about join ordering and stored procedures makes me think you are not.
In particular, can you support your assertion and tell what exact
features SQL Server optimizer has and Oracle doesn't have?

It should be noted that Oracle has two different optimizers, cost based and
rule based.  I'm not certain if Rule Based is still supported in versions
later than 9, as they have been threatening to discontinue it ffor years.

The rule based optimizer (RBO) in Oracle operates on a very simple ruleset
and a very simple algorithm to determine how to join tables and process
records most efficiently.  This ruleset results in extremly fast decisons on
the database side as to how best execute a statement.  It also requires that
the developer/DBA have a good understanding of the optimizer ruleset and the
datastructures that are being accessed.  When you are using the RBO the
order of tables in your where clause makes a big difference, exactly how
Tony describes it below.

The cost based optimizer (CBO) is an entirely different story.

When you are using the CBO Oracle has some extremely complex logic that is
used to determine the best execution plan for your SQL.  There are database
configurations which set how many different execution paths oracle will look
at before making a decision.  The DBA controls how often Oracle gathers
statistics on your data, and these statistics are used to determine where
and when to use indexes.  On Oracle 7 the CBO was considered a POS by most
DBAs, very good on version 8, and I can only assume even more improvements
were made for versions 9 and 10.

A fair amount of tuning is possible with either optimizer and the wrong set
up can have disasterous results, but I would assume this is true of SQL
server as well.  In the end, if your Oracle database is using the CBO and
configured correctly, then the programmer shouldnt need any knowledge of the
optimizer to make queries run efficiently.  True benchmarks are difficult to
come by, since they require you have your experts do the best possible
configuration on both systems.  Since it is difficult to remove the SQL
developer's skills and biases from the equation, most performance benchmarks
are useless.

The ideal benchmark would have the best experts from each company (oracle,
SQL server, Sybase, etc) set up the hardware, OS, and database as they see
fit, based on a common database model, and see who comes out on top.  I dont
know of a benchmark test that was done this way, I have only seen those that
are run by a company for their own marketing propaganda, usually on their
newest product against their competitors outdated product.


Show quoteHide quote

Jim Underwood wrote:
So, he judges the quality of the product on basis of particular feature
(RBO), the codebase haven't been touched for 10 years already? Next,
what is this wrapping SQL into stored procedures stuff? Is it SQL
Server specific technique? It has nothing to do with quality of
optimization.

What exact changes in CBO suddenly changed it from being POS to
marvelos? I haven't been around versions 7 and 8, and assume that they
just fixed some obvious bugs.

This is true. Although it is still possible to go through the list of
features like
* SQLServer has multicolumn stats while oracle doesn't
* SQLServer has cost based "group by" placement while oracle doesn't
* SQLServer does magic optimization while oracle doesn't
This list is not without it problems, as having a certain feature
doesn't really mean that this feature may have a performance impact
significant enough to justify additional work in the optimizer search
space. Yet, this is a basis for intelligent discussion and quality
comparison. Blabbing how wrapping SQL into stored procedures could
amortize SQL planner time among multiple executions is not.

Jim Underwood wrote:
[snip]
Isn't that exactly what the TCP-C benchmarks does for OLTP applications?

<URL: http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp >

But of course these numbers do not and cannot take into account the
knowledge and experience your organisation has with product X or Y...

Gert-Jan

Absolutely (except it's TPC, not TCP).

Show quoteHide quote

At least I got the URL right :-)

Gert-Jan


Show quoteHide quote

Date Only Data Type
Time Calculation - NEED HELP PLEASE!
Array?
10 seconds for MoveFirst on a rowset?
SQL Statement guru required please!