Wednesday, May 6, 2009

JDBC(TM) Database Access

I now have a mini-applet sitting here. The applet embodies Rasch analysis to the extent that items are grouped by difficulty and offered to students according to revealed ability. But the data used to estimate item difficulty is both static and old. If my applet is to be apply Rasch theory in real time, the estimate of item difficulty must be modified and updated while students are using the applet. Currently items are dished up from an array, which is shuffled each time the applet is used. If my applet is to be apply Rasch theory in real time, it needs to serve items from a database, which both includes historical data on each item, and updates it according to current usage.

This will require quite a sophisticated database application. As the front end sits on the web, and may be used by many students at the same time, there must be carefully thought out locking protocols, to avoid either loss or corruption of data. It's not really my area of expertise. I have attached multiple clients to the Microsoft Jet database engine using Visual Basic 6. All the locking side of things was "off the shelf" from MS, and required no conscious thought from me. It worked reasonably well. Schools using 15-20 workstations simultaneously were able to use the application daily for up to a year without major data corruption. If they remembered to build and repair regularly, they could run for longer.

Working with Java will be a whole new ball game, not least because of the DIY mentality that seems to embrace the Java Community. When I post questions in the forum, there is always a negative reaction if forum users suspect I am using NetBeans. The replies always emphasise the importance of building everything from scratch and learning everything from first principles.

Before deluging the forum with questions I should therefore perhaps better have a glance at the JDBC(TM) Database Access trail. The trail comprises two lessons, and the first lesson opens hopefully with the following claim:

JDBC helps you to write java applications that manage these three programming activities:

  1. Connect to a data source, like a database
  2. Send queries and update statements to the database
  3. Retrieve and process the results received from the database in answer to your query

This is exactly what I want to do, and it is made to sound very easy. The next section describes the JDBC Product Components, which again looks fine, but the acid test will be whether I can apply these components to attach my app to my database. The architecture section is also fine in so far as it goes. It's nice (though not very surprising) to know that the option of a three tier structure is built into the language, but for now a two tier structure will do for me. I just want to make a connection. The section on relational databases and SQL seems out of place here. Surely on-one will be trying to connect an app to a database if they don't know what a database is or how to write a query.

The second lesson, from its list of contents looks as if it might offer substance to fulfil the promises of the first. But it quite quickly in my opinion falls into a heap. A good lesson should satisfy two tests. First it should provide all the information required to complete the task it purports to teach. Second it should provide only the information required to complete the task it purports to teach.

This lesson fails on both counts. First it dedicates a whole section to database theory, which the student could reasonably be assumed to know. And then it signally fails to provide adequate information to make a connection to an existing database. The way the Getting Started lesson is written it could just as well, and more honestly, be limited to the following statement:

"Download NetBeans and follow the instructions therein to construct a database application."

A lot of technicians knock Microsoft Access. Yet is perhaps surprising how many "production" systems out there which use Microsoft Access as a back end. Why is this? The short answer is that it is easy to use. And when you come to create a database application in Visual Basic, it is very easy to make a connection with the Access database you've been working with for years and grown to love. And if you graduate to larger organizations, which require a more robust back end, such as SQL Server, it is still very easy to suck the data from your old Access database. In fact it's pretty easy connecting to any database which ODBC compliant.

I've said before that it the creators of Java wanted to encourage programmers from other languages to jump ship, one might expect them to make the transition easy. But rather it seems they prefer preserve the purity of their own elite little club, shunning Microsoft users, and putting up obstacles to the transition, rather than making it easy.

No comments: