New Technologies -- MIDRANGE-L

> From: Metz, Zak
>
> My situation is not the norm, so allow me to explain a bit. I do
> have a day job where I code in RPG, some C, etc. but at home I
> run a music review website, and that is the project I speak of. I
> report to no one and the only cost is my time.
(...)
> All in all, it's a
> learning experience, and I'm nerd enough to think it's fun. I'm
> lucky enough to have time to play--at nobody's expense.

More people should do this.  People who actually do this stuff on their own
time are more committed and so have a better chance of making good
decisions.  Of course, you don't get paid for it, so you have to WANT to
learn it.


> Knowing my database layout intimately, creating the SQL statement
> was a very quick process, no more than five minutes to create a
> working version, albeit a slow one. Optimizing the query as
> documented in my post took around a half hour, including writing
> the post. Total time of about 35 minutes or so.

I didn't get that feel, Zak, I thought it was hours or even days of work.
Now, don't take this badly, but the fact that a self-acknowledged SQL expert
still had to dig through joblogs to do this is a little problematic in my
mind, but I guess in a way it's not so different from program dumps or trace
logs.


> The SQL performance issues I've seen
> are generally related to lack of skill, not system deficiencies.

I sort of agree.  It may just be that debugging an SQL is a completely
different animal - this sifting through logs and messages to try and
understand what's going on is frankly disconcerting to me.  But I can
acknowledge that that particular lack of comfort may well be more an issue
of me as a person than a problem with the technology.  If a junior
programmer can learn SQL debugging as quickly as they can learn RPG
debugging, then the problem is with me, not the language.

Of course, I'm still reluctant to agree that it's that easy.  In fact, the
only reason some junior programmers can learn SQL debugging at all is that
they learn it in college.  But then again, that cold harsh fact is a
reality, and one that needs to be considered in any busniess decision.


> I believe that where this really shines is maintenance and
> flexibility. I can change this view any time without affecting
> the programs that use it (because they use SQL to get at it).
(...)
> I know I can
> write any and all of that faster in SQL than RPG. I know that
> from experience. YMMV.

And this is indeed where SQL shines.  Queries.  SQL is very, very flexible
at querying data.  And if you think you'll need to change views often, or
you need to provide ad hoc capabilities to your end users, then SQL is
usually much easier than RPG.  This isn't always the case; there are still
times when RPG is easier, especially when there are complex decisions to be
made, but in general SQL queries are far more flexible.

As you point out, there are still trade-offs.  I just wanted to point out
that you need to make those decisions with your business goals in mind.
Just doing it "because it's there" is a pretty weak excuse, unless you can
honestly justify the learning curve argument.  Which, in your case, Zak, you
obviously can.

Joe