Today was spent on database design for the sip front-end project. All in all fairly productive, we've got the whole thing nicely isolated so that it only needs two references to outside schema. It's fairly straightforward as a design, and shouldn't cause any problems (so expect to hear about lots of frustration and heartache ;) ).

Something that struck me (again) today was the horrible problems that anything which tries to make relational database design easier face. My own PyTable is a fairly extensive set of mechanisms that allow for run-time introspection of a database schema, as well as providing a row-wrapping class that makes working with DB-API rows a little less painful. It is, however, large and property based, and thus not something D'Arcy or Tim are willing to use.

D'Arcy, however, has his own database "helper" application. It's basically a macro pre-processor that lets you substitute variables into an SQL file. Fine enough, but it has so many magic dependencies on environmental settings that I eventually had to just scrap using the pre-processor and substitute in the 3 or 4 variables in the schema with a simple Python script. The benefits for this project were so trivial that it would have taken dozens, maybe even hundreds of times more effort to figure out what was wrong with the tool than to just avoid the tool altogether and write raw SQL.

Now, if I'd been writing the schema myself, I'd have written it in PyTable, and I could actually generate the schema in D'Arcy's preferred format (the benefit of introspectability), but as D'Arcy wrote it, it's in raw SQL, no chance to make all the extra features of PyTable come to bear as a result.

I guess, in the end, it doesn't matter, the schema won't change all that much, and it's small enough that it's managable in plain SQL. It just feels so wrong... so repetitive... so evil... but then I've never really been a huge fan of SQL.

"Is there a point to all this?" you ask. Well, no, probably not, just felt like rambling for a bit... mark of old age I suppose.