Oracle Licencing IV: The Carnage Continues!

The Register in its delightfully sarcastic way breaks the news of the latest refinement to the Oracle licencing model. Basically,

Sun's UltraSPARC T1 chip will be multiplied by a factor of .25...the dual-core x86 chips from Intel and AMD will be multiplied by a factor of .50, whilst "all other" multi-core servers - mostly the Unix crowd - will follow the .75 rule.

Contrary to the their normal high journalistic standards El Reg don't provide a source for this story but the press release is on the Oracle Corporate site.

This is not quite the revolutionary new pricing strategy Larry hinted at in his OOW2K5 keynote. Instead it further muddies the waters when it comes to costing a server installation without helping those customers for whom none of the current pricing models are suitable. Since you ask, yes, my current client is one such case. They have lots of database applications but almost no Oracle installations. Looking at the roll-out of my current project, the Oracle licensing costs are a substantial part of the problem. The per user model doesn't work with web-based systems. The per employee model doesn't work with a workforce of forty thousand most of whom will use the system maybe once a week. Which only leaves the complex, expensive and - yes - unfair per processor model.

Upgrade your server and pay more to Oracle for the privilege? Hmm, it's a toughie.

Manageability: an Oracle fan gets illogical

Thanks to Doug Burns for pointing out this interesting article on the comparatitive manageability of MS SQL Server and Oracle by Buck Woody (crazy name, crazy guy!).

I was particularly struck by his assertion that SQL Server is easier to manage because it requires fewer steps to achieve any given task. Despite touting this as a scientific assessment Buck Woody fails to provide even the most basic information, such as which versions he's comparing. His "proof" of this statement amounts to an invitation to install MSSQL and see for ourselves.

On the other hand, there was a very interesting presentation at OOW2K5 called "Which Database Is Easier to Manage: Technical Case Study Comparing Oracle, SQL Server and IBM DB2" by Kevin Canady and Aaron Werman of Edison Group, Inc (not Oracle employees) who asserted the opposite. They presented a set of findings based precisely on counting the number of steps reuired to do common database tasks using the vendor's GUI management tool. Oracle have made a lot of progress in manageability in 10g and the Edison Group assessment is Oracle 10g is considerably easier to manage than MSSQL. They have published these findings as head-to-head slapdowns(Oracle 10g vs Microsoft and Oracle 10g vs DB2) but the three-way comparison was dead instructive. In some areas MSSQL is less manageable than DB2. Of course, Canady and Werman were comparing production versions, which meant MSSQL 2000; an old, old product but whose fault is that?

In the Q&A slot I questioned whether counting steps in the vendor's GUI is the appropriate metric for assessing manageability. Particularly for repetitive tasks a GUI is a lot less productive than even SQL Worksheet; besides, many experienced DBAs would have scripts to undertake common tasks. The presenters took the point, but it's the old case of measuring what is what measurable. We can count the number of steps it takes to achieve something in a wizard. It's a lot harder to compare how easy it is to achieve that same thing by the quickest possible means, because that might vary from DBA to DBA: my PL/SQL is quicker than my Python scripting but not as quick as your Perl scripting.

Aargh! HTMLDB is giving me JDeveloper flashbacks!

When I first started working with JDeveloper 3.0 in 2000 - we were not so much early as lonely adopters of BC4J (at least on this side of the pond) - the documentation was in a parlous state. We could get a first cut something working using the wizards, but as soon as we needed to go off piste we were lost. The in-built help text was rubbish; virtually nothing at all on BC4J, which had been introduced into 3.0 and had no link with any existing Oracle technology. All OTN offered were some tutorials and, later on, some How Tos; inevitably these never quite covered the areas that were troubling us the most.

Having spent a couple of days wrassling with HTMLDB I find I'm in the same predicament. Sure I can build straightforward Create/Edit/Delete pages quite nicely but now I want to build an integrated application and ... it's not easy. The document consists of tutorials and How Tos, which - you know what's coming - don't quite show me how to do what I want to do. The problem is the documentation doesn't seem to be written by people with a lot of experience in writing form-type applications. The two day tutorial doesn't even mention Master-Detail forms, which I would have thought is a fairly basic; even spreadsheets frequently have some header info.

Of course, the HTMLDB forum seems to have a lot more answered posts than I recall the JDeveloper forum got back in the days. OTN has quite a few sample applications, so perhaps I just need to install all of them until I find an example. And there's also blogs. So no doubt the information I need is out there, somewhere. It's just finding it that's going to be the issue. At least I hope so. I've been trying to build an LOV that has its query restricted by an existing value on the page; the resources on the interweb have offered me at least three different implementations , none of which worked the way I wanted.

I'm just stressing out here probably because I'm trying to be too clever too soon. I obviously need to stop being an active user and spend two days going through the tutorials, building applications I don't need, in order to get a handle on the basics. But with a heavy heart I'm afraid I have to tell my project manager to start cranking out the Excel again. It's not going to be as easy to implement his spreadsheet in HTMLDB as I thought. Blast.

Neology Corner: Reshoring

I am introducing a new coinage into the wild: reshoring. This is what happens when a project that has been offshored turns out to have been wrongshored (heh); when everything's gone pearshaped and the project is brought back to be sorted out. Sample usage: "Have you heard about Project FFIENNES? They're reshoring it from Bangalore."

Was my coining of this phrase inspired by any specific project I have come across? You might think that, I couldn't possibly comment.