I am not the person you want working on your hardware, so having a digital watch of sentimental value entrusted to me is a very nervous occasion.

My dad’s Casio 596, a Father’s Day gift from a now-deceased young man who was a dear friend of the family, decided to stop blinking at me when I tried to reset it for the end of Daylight Savings Time this year. I’ve tried popping the back, and the contacts are making and breaking as they should, and the removal/replacement of the battery (I’m thinking hard reset here) isn’t obvious. He’s WD-40ied (or is that WD-40ed?) the buttons, and I’ve worked them with tweezers–they seem to be okay. I’ll take this to a jeweler if I must, but it seems to me I should be able to do a bit more with it.

So: Where do you go to learn how to fix a timepiece of the ancients? This watch dates back to 1988–it’s damn near a digital antique. Can you help?

Dieselpunk? Crystalradiopunk? Just a plain ordinary punk for not getting something fixed for my dad? Can you help me avoid that final, dreadful, unthinkable fate?

I have been poring over an Oracle procedure of death in which a loop over a complex cursor calls a no less complex function in which multiple SELECT statements set various ancillary variables before a row insert accompanied by an UPDATE of the corresponding row of one of the tables referenced in the initial cursor. Still with me?

I have several times heard that procedures and simplistic SQL statements make for easier-to-maintain programs. I am not that sure; my only certainty is that it makes it easier to assign more junior, and therefore cheaper, developers to the task. I am under the, possibly false, impression that to most young graduates GROUP BY represents the ultimate level of SQL sophistication.

But complexity isn’t inherent to a language, whether it is SQL or a wrapper language to embed SQL statements. Complexity is born of business requirements, and usually
made significantly worse by poor database design.

I am not sure that a long succession of if … else if … else if … embedding a number of SQL statements makes for an easier read than a CASE construct and a handful of outer joins. Actually, my feeling is that the larger the number of lines, the longer it takes me to grasp what the damn thing is meant to do.

But what I am certain of is that if we don’t replace this
procedure with an INSERT … SELECT and a trigger to update the other table, we won’t be able to go much faster than the 150,000 rows per hour that are currently processed.

Ever had one of those ideas you didn’t want to mention because you hoped no one else would ever think of it? I’ve had three of those, and one of them still hasn’t happened, but today the most recent one came true: I got an email with this subject line:

Re%SYMBOL_TWO Tentative discussed tes…

Looks like your average technical e-mail list subject line, right? But it was just spam.

Someone finally figured out how to get technically-minded people to pop open the occasional spam message.

This one fills me full of hate in a way that no other spam ever has.

Got technospam?

Related link: http://www.oracle.com/innodb/index.html

No doubt that the OpenSOurce community is shaken by the
announcement on October 7th that Oracle is acquiring Innobase, the company behind InnoDB. InnoDB is the product that enables MySQL to turn into an enterprise-grade DBMS, with the support for commit and rollback, foreign keys, row locking … Forget about all the reassuring noises about
“commitment to open source software”, etc. Commitment to keep OpenSource software under close watch, so that it stays a toy, and not a menace in the corporate world ? (OpenSource database software, that is. Anything that has to do with operating systems, word-processing or spreadsheets is welcome).

In fact, there are many positive aspects to this announcement. Firstly, Oracle still has an interest in databases, something that wasn’t absolutely obvious from the recent buying-spree. Secondly, Oracle implicitly acknowledges that OpenSource software databases have reached a level of maturity that makes them worthy contenders in the corporate market. Thirdly, it may be an opportunity for some other OpenSource entreprise-grade DBMS products to step out of the MySQL shadow. Fourthly, it makes MySQL a greater champion, if the MySQL announcement is to be believed, of the GPL license; time to dust off business models perhaps. And fifthly, it may announce the birth of a new lucrative cottage-industry: developing strong storage engines.

Related link: http://www.oracle.com/corporate/press/2005_oct/inno.html

Oracle has purchased Innobase Oy, the creators of MySQL’s only enterprise-class storage engine, InnoDB.

I’ve requested a short interview with Heikki Tuuri and will post an article soon.

Read the press release here.

It’s funny how people tend to side naturally with one school of thought or another. Database topics often polarize practitioners, and one of the issues that are hotly debated happens to be the ‘natural key vs surrogate key’ question, that is whether the primary key should have some significance outside the information system or merely being an internally generated number. I don’t see any reason why I would call 357914358 something that I could call 'SPADE', and I use natural keys whenever I can. But a friend had a very interesting reaction to my mentioning that primary keys should not be updated:

We don’t update PK’s because of the inherent difficulty of propagating changes to related tables (assuming that we are using natural leys). This is one reason people go with surrogates. But what uniquely identifies a row can and will change. For example, what about a Companies table, and a company goes through a name change. Is the PK partly based on the name of the company? … This idea that we don’t update PK’s seems rooted more in the difficulty of updating PK’s when natural keys are used.

Cough, choke! There seems to me to be a confusion between the identification of a row (what the primary key is about) and the subtly weaker condition of distinguishing one row from another. As it happened, my company changed its name some time ago. Why could we keep our banking accounts without having to close and reopen them? Why could we keep our contracts running? Simply because the registration number attached to the company when it was incorporated didn’t change. The name of a company distinguishes it from another. But it’s not what truly identifies it. Some might argue that a registration number is a surrogate key of sort; and indeed it might be considered a shorter alias
for a company that was created under a given name at a given place and date by some particular people and as a particular type of company. It’s a surrogate key, but it’s rooted in the real world. It seems to me quite acceptable to use a surrogate key to identify a company, as long as we
clearly understand that it’s merely a short-hand for information such as incorporation details that we have no use for in our model otherwise.

If you were to change what truly identifies something, how would you know that it is the same thing? There is no way to distinguish an update from a delete followed by an insert. “Updating a primary key” implicitly acknowledges that you have some out-model knowledge that the before
update and after update values truly represent the same item. What truly defines the row isn’t in your model. Don’t blame the theory, blame your model.