On Sun, 21 Jan 2001, you wrote:
Emlyn wrote:
> James Rogers wrote:
> > Oracle has a great core engine surrounded by tools and development toys
> > that are totally ass.
>
> You mean shitty here, yes? Having a slight cultural problem interpreting
> "ass".
More or less. "totally ass" is roughly equivalent to FUBAR or just
"criminally deficient". A left-over bit of vernacular from my college
years.
> SQL*Plus... urk. Hideous! There's no substitute, because that's what Oracle
> ships, and that's that. It's a damned awful tool, though, a disgusting
> kludge. Look at the way you have to generate scripts that generate scripts
> which do the work; how hard would it be to provide real programming language
> contructs like loops and conditionals and stuff (yes, I've seen people
> simulate these with bizzarre application of comments and environment
> variables in code generation)?
Errrr....I take it that you don't really know how to use SQL*Plus? Things
like conditionals, loops, etc are all supported natively inside SQL*Plus
without doing any of the stuff you are talking about. In fact, the
SQL*Plus shell is actually quite powerful. However, most people I know
who work on Oracle haven't figured out how to do all but the most
primitive things with SQL*Plus (usually limited to running queries,
compiling stored procedures, and spooling data). Heck it took me quite a
number of years of working with SQL*Plus to really start exploiting its
capabilities. There really isn't a whole lot you can do programmatically
that can't reasonably be done from SQL*Plus if you know what you are
doing, and the design is reasonable and consistent with CLI type
environments. It is a very deep tool.
The caveat being that it works better under Unix than Windows. The
Windows version looks like a straight port where they didn't bother to
fork the code to accommodate differences in behavior between Windows and
Unix. The Unix version is great because it integrates very well with the
normal unix command line (and all the normal unix utilities that go with
it), which makes sense because that is a large part of its heritage.
Sun's systems have been the reference platform for development for many
years at Oracle.
> I bet there are great tools, of course, to substitute for this crud, offered
> by third parties. Must find myself one, preferably with a gui.
Or you could learn to use the capabilities of the software you already
have. :^)
> It's not easy from Oracle, either; you need in depth arcane knowledge of all
> these 70's style crypto command line tools, which keeps skilled dbas on the
> gravy train. Sorry, that's not fair, but I am a developer... I'm expected to
> undervalue a DBA's role, it's a professional obligation :-)
DBAs exist to keep developers from getting bored. I could probably serve
as an Oracle DBA, but I wouldn't want to -- it is a very uninteresting
job. In truth, the Oracle DBA command line is actually very consistent,
to the point that I can correctly guess the syntax and parameter formats
for commands that I don't know.
> Now you're talking! I find that delphi is so good, that it's quicker for me
> to throw together a nice gui app to do something against Oracle, for
> instance, than it is to try to write cryptic SQL*Plus scripts.
Whatever works for you, though a good working knowledge of PL/SQL is
extraordinarily useful if you want to push the runtime performance
envelope. My work revolves a lot around application scalability.
> For instance,
> I've had to do some pretty tight multithreading work myself lately, writing
> free threaded COM objects. Fire up Delphi, yet again, and use the
> TMultiReadExclusiveWrite object; it's stupidly simple to take care of the
> most common cases, without doing something dumb like using a mutex.
But what do you do when you are faced with an uncommon case? Sometimes a
simple reader-writer lock is a pretty inefficient way to go. In truth, I
often prefer to work with locking primitives because it allows me to
strictly control the behaviors of locks. I don't re-invent locks
everytime a need a complicated one; I have well-worn libraries that have
all manners of unusual locks in them built on POSIX primitives. Windows
threads are odd enough behavior-wise that they aren't really portable when
performance is a consideration. One size fits all locking solutions (like
Java monitors <shudder>), can give poor performance for some applications
where desired thread behavior is more complicated (common when dealing with
scalability issues).
But these are my issues; most developers do just fine using off-the-shelf
bits without worrying about the internals.
-James Rogers
jamesr@best.com
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:21 MDT