You know, when you're starting to build something, you allways end up at the crossroad where you need to decide on a simple, yet threatening matter: start from scratch, or spend time trying to use someone elses work. If you choose the latter option, you will most likely end up with starting from scratch anyhow. This is where I found myself at this late friday night (or saturday morning if you will).

As you may have suspected allready, provided that you don't know me allready, I am a software developer. This means that I am prone to being blamed each time your computer fails, since you probably use something I have made. I hope the series of posts I'm writing might enlighten you on the perhaps worst matter at hand for us developers; foolproofing. But I digress.

At the moment I am writing a web-based application to calculate consume trends (hence the domain consumetrends.net), and as mentioned above, I ended up at that particular crossroad. Needless to say, I chose to reinvent the weel. So far I've come up with some small definitions on what the smallest building blocks should be. First out is the database. Should I use asp datasources, or should I go for an object-oriented data access layer approach? Both approaches carries their own pros and cons, and I have so far decided to go for an object-oriented approach. I will revisit that particular matter in a later blogpost. The database, however, still needs to be defined. Should I foolproof it with built-in constraints, should I go for cascading updates and deletes, should I build my own triggers? Should I rather be more concerned about the object-oriented data access layer's specifics and make it less of a hassle to build it, but then at the expense of database normalization? I guess all options are good in their own scenarios respectively, but which one should I go for? That's the million dollar question.

So far I have decided that I would be able to maintain the best quality of my code while at the same time reducing the ammount of work to a feasible minimum by designing the database within normalization laws, and then use a code generator tool to build the data access layer.

In my next post, I will be discussing the problems with showing data intuitively in a user interface.