tangentalizingly delicious

Thursday March 16, 2006

I had the opportunity last night to do a bit of work involving ER Diagrams. Really simple stuff, just in discussion with a database guy, and primarily to help quickly get a grasp on where I was in terms of cluefulness.

I am pretty sure I passed, I’m a pretty decent database guy.

But what sticks out is both how much fun I had doing it, and how useful I can see them being in the long term. If there were people who read this, a significantly large percentage of them that knew anything about databases, and UML and software design principles in general would probably be saying “duh”, but they aren’t, so fuck you duh-sayers.

Well, not really, because it is kind of a duh sort of thing. An ER Diagram is an Entity Relationship Diagram, which is basically a picture of things and the way they interact (a diagram of entities and their relationships, see how cleverly I broke that down?). To help illustrate, one of the (theoretical) examples I worked with was sort of a musicians colony. So there are entities like: Musician, Song, CD, Instrument and there are relationships between them like “Musician Plays Instrument”, or in the jargon “Musician Has-a Instrument”. It is a Has-A relationship, which when setting up a relational database (and other logical structures) helps in the process of defining what information needs to be stored in the database, and how that information interacts.

I sort of feel like I’m just repeating myself in a few different ways, but I think I’m making progress, so just put up with me for a bit.

The discussion took place in part in the context of examining a current system, built as a ASP (not .NET)/PHP-type page-based server-side web application, and migrating it to more of an OO/MVC type system such as .NET or RoR. To make the move to that latter system it helps to know what your objects are, and how they interact, and that’s where an ER Diagram comes in.

Converting between an ER Diagram and SQL is sort of an easy thing to me. Relational databases seem to be the context in which they’re most often used, but relational databases are in a lot of ways very object oriented beasts.

This is probably making the “duh” people leave or something, because I am talking theory I have very little actual knowledge of and am probably laughably wrong, but hey—at least I made you laugh.

I’ve been thinking, independantly of this specific situation, about mapping actual objects to databases, and these here ER Diagram things are going to be an interesting tool with which to do so. I do remain somewhat wary of them though, in the way that I’m wary of almost all external documentation.

It is good to describe a system of course, but lately I’ve been siding with the “code is the best description”, but at the same time, customers aren’t going to read the code, especially in a closed system.

This has caused problems for me in the past with an application whose intended behaviour wasn’t properly described to customers, so their assumptions and expectations are never set which means they can never be met. Stale documentation is not the place to set an assumption, but when a customer says “So, why is it that this is happening” having an actual answer for people to respond with without necessarily needing to dig into the code is a good thing.