James Rogers wrote:
> On Sun, 21 Jan 2001, Emlyn wrote:
> > > Surely not compared to Windows which to this
> > > day cannot even deal with multiple users correctly.
> >
> > ??? Are you talking about NT5, or Win3.1?
>
>
> Any version, take your pick. Windows in all its incarnations has never
> been a multiuser environment. Take a look at the odd and ugly hack that
is
> Citrix Winframe, trying to (badly) get the same multiuser capability out
of
> Windows that has been a basic feature of Unix for ages (e.g. X).
>
I think I know what you mean here... the way that, for instance, it is
damned difficult to get one NT Server to have multiple users simultaneously,
in a Unix terminal-based style.
I'd criticize it for that too. However, one thing with Windows (nowadays) is
that it is designed for a different architecture to the old
Mainframe+Terminals style. Instead of one expensive box and lots of cheapy
terminals, they go for many (relatively) cheap servers, and many relatively
cheap workstations, which are computers in their own right. So instead of
say, a couple of huge workhorse servers and tons of terminals or
workstations, you might run 20 NT server boxes and fat pcs on every desk.
I realise this has drawbacks, and that people are moving back to the
big-server mode in many cases. I also know that the basic task of running an
arbitrary program on a remote machine is a lot harder to do on Windows than
under Unix.
>
> > However, SQL Server I do love; version 7 is fabulous. I don't know what
DBAs
> > think of it; I know it requires you to replace the Oracle style
architecture
> > of a couple of beasty servers with a cluster of zillions of little,
> > cantankerous machines.But from a developer's point of view, it's pretty
> > damned good. The tools are sweet, too.
>
>
> 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".
Why is it that Oracle's tools are so damned lame? Drives me crazy (I have to
work with them at the moment).
For instance, to run arbitrary SQL against Oracle using a simple query tool
turned out to be hopeless using their basic tools. Admittedly, a lot of this
SQL was generated, and was really long; the oracle tools kept truncating it
(not good). I wrote my own tools to run this stuff, against any ADO
datasource, with some really nice features, in about 6 hours.
Surely Oracle can spare 6 developer hours (make it 12, give 'em time for
testing) to write a halfway decent query tool to go with their products...
> Hence why there is a thriving market for
> third-party Oracle development tools, many of which are as good as you
> will find on any database platform. SQL Server has the reverse situation,
> with lots of reasonably decent development tools surrounding a core engine
> that is still pretty lame (though v7 is quantum improvement over v6.5).
> Since a business runs on the core engine, not on the development tools,
> Oracle is still widely preferred by most management teams. After all,
> good tools can be purchased for Oracle as well (just not from Oracle).
> Also from a management standpoint, Oracle is extraordinarily portable and
> can be migrated with minimal effort to *really big* systems -- no code
> rewrites to change platforms.
>
Funnily enough, the core engine isn't as important as all that, I find,
except for really big, mission critical stuff (which is less common than
you'd think).
For example, I used to work in the network operations for an electricity
utility. I was building a call-center app which needed to do all sorts of
lovely realtime things, integrate with other corporate systems, and
eventually allow clients in the field over wireless connections, and
remotely over modems, as well as locally. It usually had very low traffic,
unless there were storms, in which case you could have a lot of users
bashing it repeatedly.
We used SQL Server 6.5, and it did the job admirably. We were very careful
with application of stored procedures, we indexed things properly,
denormalised where necessary, and ended up with a very efficient
application, running on very cheap servers, costing very little to
administrate and maintain.
As a comparison, in the next room was the network control center; a bunch of
old blokes working round the clock shifts with various stress-related
problems, controlling the grid in the companies' control area. Very
sensitive work. They were running a Unix-based scada system, with triple
redundant hundred-thousand dollar plus oracle servers doing the work; this
system used telemetry to actually directly control the network. Now there is
an application for which I would never even think about SQL Server. Horses
for courses, of course. However, you can imagine how expensive this system
was to maintain, how hard it was to administrate.
> I should also point out that while simple database development can be
> accomplished using GUI tools, there are many things in the database world
> for which there is no substitute for dropping to a rich CLI shell to run
> complicated scripts. Like Oracle SQL*Plus on a Unix character terminal.
>
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)?
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.
> From the standpoint of a DBA/SA on really large database systems, I would
> take Oracle over SQL Server any day. Oracle has been doing these types of
> systems far longer than Microsoft, and ultimately, managing giant complex
> systems from any Windows system is painful.
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 :-)
>
> Of course, there is more than just Oracle and SQL Server. DB2 for
> instance.
>
How 'bout Informix. I've heard good things...
Anyone know Interbase? Borland pushes it, but I'm skeptical. Anyone?
> > Borland Delphi is sweet, beautiful, GUI based and proud.
>
>
> This really is a superior product for GUI application development. I am
> looking forward to the Unix versions I've heard are coming out.
>
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.
>
> > Nowadays I'm writing ASP to talk directly to a database. We're not using
a
> > middle tier :-(, but jscript, as the scripting language, is turning out
to
> > be incredibly efficient (compared to how I expected it to perform); I
wrote
> > a SQL Server -> Oracle sql translator so that we could support multiple
dbs
> > more easily, and I never notice any performance hit, which is surprising
> > because I never designed for speed, and I'm pretty sure the thing is
> > computationally intensive.
>
>
> Perhaps the fact that you are using ASP puts the SQL translation below the
> performance noise floor. :^)
>
Fair call.. hee hee.
>
> > I'm really happy with the current state of the Microsoft OSes, although
I
> > wish they could finally drop the 9x kernel. They're good to program on.
They
> > do lots of great stuff for you.
>
>
> This really depends on what kind of programming you are doing. Some of
> the low-level stuff in those OSes are really pretty awful. The APIs are
> far too rich (and broken in some fashion a third of the time), and there
> are way too many odd and complicated side effects. Look at the thread
> APIs/model on NT if you want an example of a diseased design and
> implementation. I've done parallel development on Windows NT and Unix; I
> spent far more time fscking with the Windows specific code than the Unix
> specific code because there were a lot more things that could go wrong.
> The beauty of Unix is that it *doesn't* try and do a lot of great stuff
> for you.
Yep, I think writing low level stuff on Windows can be painful.
But, to be fair, there's a lot more of the high level stuff. 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. Leaves
you free to spend time debugging the really evil stuff.
The basic windows threading stuff is pretty weird though.
Emlyn
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:21 MDT