|
The first of these questions or
comments usually come out as
"Can you teach me Oracle?" My
polite answer is generally
"Sure, I'm actually just about
to do a class on that; I'll call
you when it's ready." This is a
way of being nice without
committing to what the
questioner doesn't realize could
be weeks of effort on my part,
not to mention theirs. (Of
course, I'm not so much
concerned with theirs because
their efforts don't generally
keep me at the office later than
I need to be.) Sometimes I'll
take the extra step of telling
them where they can download a
full version of Oracle to
install and play with. But
sometimes that would be a bad
thing for me to do because it
might only invite a plethora of
follow-ups. The second type of
question I get is something like
this: "We're having this issue
with SQL Server, and I want to
see how Oracle handles it."
Okay, now we're getting
somewhere. I can offer some
assistance, but this won't be a
request for hours upon hours of
my time. It will be a
well-thought-out description of
a specific problem, the Oracle
answer to which will guide the
questioner down a road that
might lead them to a solution to
their SQL Server problem. The
questioner continues: "Our SQL
Server databases are getting too
big—how does Oracle handle
this?" Sigh...I stand corrected.
I'd Like to Help, But...
Maybe my approach has been
wrong all along. Maybe I should
just write down a summary of
what the likely concerns might
be. Then I could hand this list
to each person who comes calling
for advice. If the individual is
on a crusade for general Oracle
enlightenment, this list will be
a somewhat comprehensive—albeit
technically light—spiritual
guidebook of sorts. If, on the
other hand, the inquisitor is
seeking resolution of a specific
and quantifiable concern, this
paper will serve to guide them
in the right direction so they
can find the answers they're
looking for from their own desk.
But no, that would all take
too much time. And as much as I
want to help these sojourners, I
don't really care to go too far
out of my way for them. That
would set a bad precedent. That
would encourage them to come
back to me yet another time with
yet another vexation. So let me
instead just take a few minutes
to ramble about what I shall
call design flaws in SQL Server.
Architectural concerns that
cannot be worked around.
Axiomatic principles, if you
will, that often do not get
raised when diving deep in the
technical details of a database
platform decision. Rather, they
must be lived with if your
decision has been to use
Microsoft's database platform.
Features, or lack thereof, can
often be worked around, but a
product's basic machinations
cannot be altered
easily—certainly not by an end
user of closed source software.
Oh sure, there are ways to make
the pains not hurt as bad as
they might, but they cannot be
overcome. Therein lie many of
the differences between the two
platforms, not to mention the
source of many ills.
Bear in mind, I'm not working
on a system for the florist down
the street. No, Microsoft is
making its best attempts to push
itself into the Enterprise. Into
Oracle's neighborhood. So that
is what I am about to discuss:
issues of concern to enterprise
systems managers.
Home
Next
|
Home