The Web SQL Database API is the logical progression from Google Gears: a programmatic way of accessing a SQL database that’s built into your web browser. The current crop of browsers also have this all nice and sandboxed, so we shouldn’t end up suffering from some of the cross-site data access issues that were a worry in the previous generation.

So far, I think the best user-space access to the databases has to go to Safari. You can get at them in the Security tab of the Preferences window:

But, even better than that, the Developer tools have an actual browser and query console—with smart SQL tab-completion!

(I didn’t do anything magic to hide that rs_hints object—it’s a view. I guess the Safari browser doesn’t show views.)

All of the current browser implementations use SQLite as their storage engine. SQLite has robust SQL support—it’s not meant to be a data warehouse, but it’ll probably do pretty much anything you’d think was sane to do inside a web browser. I’ve successfully been able to use views, unions, several types of joins, indexes, and primary and foreign keys.

I’ve whipped up a quick app that shows off some of the technology: Sudoku + HTML5. The storage layer for the app is done using the SQL engine, as is the business logic (game rules) of the Sudoku game itself. The presentation layer is, of course, done in JavaScript using the HTML5 canvas API. I’ve tested it in Safari, Opera, and Chrome. Firefox, as of 3.5, does not yet support the SQL Database API. I don’t have access to Internet Explorer to test it, but 8 shouldn’t work due to the use of the canvas element.

Here’s a really quick overview of the Web SQL Database API:

var DB_NAME    = "ricko-sudoku";
var DB_VERSION = "1.0";
var DB_TITLE   = "Rick O's SQL Sudoku";
var DB_BYTES   = 500000;
var db = window.openDatabase(DB_NAME, DB_VERSION, DB_TITLE, DB_BYTES);

The first part is very straightforward: I define a few constants and make the openDatabase call. I’m using the constants to illustrate the variable placement—your app may just use literals in the function call.

The openDatabase call takes one additional optional argument that I have elided: a function callback. If the database needs to be created, this being the first time you’ve ever tried to open this database, the extra function will be called. The theory is that you could write all of your table creation and other DDL queries in this callback. However, since SQLite supports the IF EXISTS syntax, I find it easier to run my schema setups immediately no matter if it’s the first time or not.

Before we run any queries, though, it would be helpful to have debugging functions for when our queries go pear-shaped:

function sqlFail(err) { alert("SQL failed: " + err.message); }
function txFail(err) { alert("TX failed: " + err.message); }

Again, nothing tricky here: we’ll use these functions as callback error handler in future queries. For illustrative purposes, we could also have a logger for when our queries succeed:

function sqlWin(tx, response) { console.log("SQL succeeded: " + response.rows.length + " rows."); }
function txWin(tx) { console.log("TX succeeded."); }

A little trickier, but we’ll go into more detail on result sets in a bit. On with the database setup:

db.transaction( function(tx) {
    var queryParams = [];
    tx.executeSql(
        "CREATE TABLE IF NOT EXISTS animals (id INT NOT NULL PRIMARY KEY AUTOINCREMENT, name VARCHAR(20) NOT NULL UNIQUE);",
        queryParams,
        sqlWin,
        sqlFail
    );
}, txFail, txWin);

Again, I’m a little verbose and heavy with the variables for illustrative purposes—you’d use a literal [] instead of a queryParams local variable. Inside of a transaction function, your queries are executed atomically and serially, but also asynchronously so be careful—hence all of the callback functions. The transaction function even has optional failure/success callbacks of its own, but again be careful: they’re in the opposite order of the query functions.

If we insert a row, we can get back the ID of an autogenerated number:

db.transaction( function(tx) {
    var animalName = "Cheetah";
    tx.executeSql("INSERT INTO animals (name) VALUES (?);",
        [ animalName ],
        function(tx, results) {
            var animalId     = results.insertId;
            var animalsAdded = results.rowsAffected;
            // for this simple insert, we should only see 1 row
        },
        sqlFail
    );
});

Using SELECT queries is just as easy:

db.readTransaction( function(tx) {
    var animalName = "%Lion%";
    tx.executeSql("SELECT id, name FROM animals WHERE (name LIKE ?);",
        [ animalName ],
        function(tx, results) {
            for(var i = 0; i < results.rows.length; i++) {
                var row = results.rows.item(i);
                console.log("Animal[" + row.id + "] = " + row.name);
            } // for i
        },
        sqlFail
});

Still nothing too tricky here. Query parameters work just like you’d expect: replace the parameter with a question mark in the query, then pass it in the array afterward. The callback here iterates over the records, each of which is a simple object with column names for keys, and prints them on the debugging console.

There’s not much more to it than that—it’s surprisingly easy for something designed by committee!

There was an Adidas booth at the runner’s expo for the Gate River Run last weekend. In the booth, they were demonstrating their new tech: miCoach. The gist of this collection of devices is this: via a foot pod and heartrate monitor, the central device sits between your MP3 player and earphones and tells you if you’re working at your target intensity. You can still hear your music and use your own MP3 player, but you’ve got a coach with a mute button. The workouts can be programmed in detail: mix any number of minutes at a number of intensity ranges (easy blue to maximum-effort red).

I’ve been on the fence about migrating from my Nike+ to something with a bit more functionality. I love my Nike+ and consider myself one of its original fanboys, but … the fact is that Nike pioneered the tech, then left it to founder. They upgraded the website and made an iPhone app, but the iPod app is essentially the same original version. There’s still no real workout management tool beyond “create a run of a given distance or time”. As I start to get more technical in my runs, adjusting speed and intensity, the Nike+ is beginning to show its cracks.

Not that everything about the miCoach is better than the Nike+. The revamped Nike+ website, for example, has a few more social features—challenges, etc. It’s not exactly DailyMile, but it’s not horrible. The miCoach site isn’t much more than a data sink and management tool. Adidas says that social aspects will be forthcoming, but we’ll see.

I looked into a Garmin ForeRunner, as the Virtual Partner tech is very sexy: a little digital avatar telling me if I’m on pace, above, or below. It’s similar to what the miCoach does, and I imagine the two sets of features will continue to converge. That the new ForeRunners also have heartrate monitors is another great selling point.

But then there’s the cost. We’re talking $400, easy. Not exactly an impulse buy.

So we’re back to my original point: the Adidas miCoach. This is the Baby Bear in this Goldilocks story. It’s got a decent price point at $140, all in. It’s engineered to work with your existing MP3 player. It doesn’t have GPS. Instead of a Virtual Partner, it’s got a voice in your ear telling you to speed up or slow down. And, of course, you’ll look like a gargoyle: heartrate monitor, foot pod, miCoach, iPod with controller watch, and earphones.

But I am nothing if not a data junkie. Hopefully, I’ll be able to crack open and mine the data from the miCoach as easily as I can the Nike+.

So I bought one. It arrives tomorrow night. We’ll see how it goes.

Update: Holy tiny technology, Batman! Here’s a picture of the miCoach pacer and iPod nano in the palm of my hand. It’s much smaller than I had thought it would be.

• Fastest Father-Son Team: Robert and Harrison Gordon, coming in with a 1:03:15 chip time.
• Fastest Father-Daughter Team: Greg Lawrence and Amy Eller, coming in with a 1:08:52 chip time.
• Fastest Husband-Wife Team: Scott and Laura Flint, coming in with a 1:15:02 chip time.
• Best Spirit of Cooperation: Kara Mathias and Manny Gutierrez, a Gator and a ‘Nole, running the entire race together and finishing in just under 66 minutes.
• Most Supportive Running Group: Dominic, William, Tim, Jamie, and Brian from Ponte Vedra, FL, coming in at a chip time of 1:46:48.
• The Family That Runs Together Stays Together: The Gobold family of Jacksonville—Chris and Lesa, with children Jena and Tyler, and friends Christopher and Mary—staying together and finishing in 2:23:30.

I am truly impressed how many husband and wife teams were seeded. That’s absolutely awesome. (And that they can match eachother’s pace the entire race!)

Despite an enormous number of Father-Son and Husband-Wife teams, Mother-Daughter teams seemed to be thin on the ground. My best guess? Jessica and Anna of Jacksonville, FL with a finish time of 1:18:21. Finding them is harder, because the surnames may not be the same. The age difference helps, but isn’t a guarantee. (Woe unto me if I call out a mother-daughter pair only to be wrong! And I’m nowhere near stupid enough to try Father-Daughter or Mother-Son pairs!)

Someone named Nicole Norris of Roswell, GA kept pace with my buddy and I throughout the entire race, crossing each split marker within 3-4 seconds of us each time. Nicole: we were the guys in the red shirt and hat and yellow shirt (mustard, not the greenish of the official race shirts). Sorry we didn’t say hello!