Some things are worth repeating.

I just got pn3d. Recall back on May 10th when I said "know your specs"? I just got caught out because I didn't know them. In this case it was the HTML 4.01 spec.

I've been implementing an interface where the client has refused to make any accomidating code changes. Therefore, I'm left to use jakarta's HttpClient class to navigate their site and perform a multipart post to submit a file. I had been screwing around with HttpClient, and had convinced myself I just wasn't using it correctly (though my code matched their example almost verbatim).

My issue? I was posting the login/password params sure enough, but you must also post the submit input name and value. Really? I wouldn't have expected that, but it's in the spec (See: Successful Controls).

What is a database, exactly?

Ok, we all know that "data" goes in the database, but what about code?

I think we all have a basic understanding of what a database is, so why do I ask? Well, we recently got into a discussion as to the role of the database in our web application. Some say that a DBMS is a highly tunable entity that is an expert at sorting through vast amounts of data. Others say that when writing an application, you should not write many stored procedures, becasuse you end up becoming died to the vendor's flavor of SQL.

I can certainly understand the merits of wanting no not tie yourself too closely to any vendor's anything. However, w.r.t. a DMBS - the investment is so large to get it, and the paybacks can be so large, that I now truly believe that all of the features that you have paid for should be exploited. Companies do not change DBMS's like people change underwear. It's a long term - high dollar investment, and I think you're just foolish if you don't maximise the return.

In my case, our software runs on Oracle. However, our data is manipulated through lovingly crafted SQL in java dispatched via JDBC. No stored procs here, or very few anyway.

It's killing us.


I'm not a DBA, but I know what SELECT does...

Do you? I didn't. Not really. I just finished the most enlightening 30 minutes I ever spent reading about databases (Oracle 9i in my case) came from Effective Oracle by Design: Chapter 5, Statement Processing. Anyone familiar with AskTom knows who Tom Kyte is. In this particular chapter, he goes over the phases of statement processing.

As boring as that sounds, it is tremendously important. This gets at the very heart of our own DB performance problems. The way we've written the application, we hard parse every statement. Don't dismiss this as a simple "cache miss" scenerio - that's what I thought it was. It's much worse than that!

Each time Oracle gets a statement to process, it must

validate it syntatically,

validate it with respect to other objects (can it view the tables/data is is asking for?)

validate it with respect to the oracle environment.

generate the code

optimize the query

stuff the statement in the SGA

Now, it can execute the statement. Imagine how fast your code would be if it had to compile/link a class every time it ran? That's basically what a hard parse implies.

What is my point exactly? Well, that I didn't know what was going on - and had I known we could have been addressing this years earlier.