James Rogers wrote:
> 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.
Damn, caught out; I really don't know it well at all, apparently. Do you
have some good links to resources on this? The ones I found were less than
good. Loops? Conditionals? Do I have to beg?
>
> 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. :^)
>
OK :-)
>
> > 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.
>
"DBAs exist to keep developers from getting bored." - can I have this as a
quote?
>
> > 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.
Probably I will need to do that some time. Currently, I need to get
acceptably performing code out on time, and that's not going to change for a
while.
>
>
> > 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).
>
Do I remember that you do really scary code generation stuff? The memory is
vague.
When I need to do uncommon case stuff, well, I tear my hair out (mental
note: stop this before entirely bald), then spend time on it, using the
primitives.
> But these are my issues; most developers do just fine using off-the-shelf
> bits without worrying about the internals.
>
Yep. For the most part I am most developers, and you are right.
Emlyn
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:22 MDT