Practicing more on the database - Triggers for journaling

I'm .NET developer not a database developer. But the customer I'm with since June this year wants to have as many things on the database as possible. Yes, as many THINGS as possible. First I thought why would you want to, but now I start getting it. The customer has a long history of Oracle application and as I understood everything is done in the database in case of an Oracle application.

Most of the time I would use a database as a data-store. Using it for creating, reading, updating and deleting data. If the client requires the usage of Stored Procedures, I basically create an Insert, Update and Delete Stored Procedure for every table, nothing special. For the selection of data I create a select by id, and selects that are required by the functionality for the specific table.

But of course the database has a lot of more power. The customer wanted to have a journal of all data operations. It is possible to add this functionality through application code that registers the calls in separate tables. It is also possible to add this functionality through more intelligent Stored Procedures. But the way the DBA wants it to have is the best solution I think. It is through triggers. As my database knowledge is pretty basic, I had to learn how to tackle this functionality using triggers. Now I've set up this functionality I must admit this solution is the only appropriate solution. The solution is tested, and if I'm adding a new stored procedure change my application or whatever change, I don't have to change my journal triggers (if I'm not changing the table structure of course).

The journal table must consist of the following structure: operation type, operation date, user and for every column a new_ and a old_ column.

It's important to understand that triggers are set-based in SQL Server 2000. At first people start testing using a single row, but when you for example update every record from a specific table only one trigger gets fired. Inside the trigger you can get the data using the virtual tables INSERTED and DELETED. For an Insert only the INSERTED columns are provided. When updating a set of data both the INSERTED and DELETED tables are filled. And on deletion only the DELETED table is filled. You can relate the INSERTED and DELETED data by joining them on the primary-key.

This solution makes sure that every data operation get's journaled, not only when calling Stored Procedures or when accessing the application.

Triggers are one of the things I've learned to appreciate of the non-basic dbms functionality. While I'm still no database guy, more on databases will follow in the near future.

Using a personal Wiki as my private knowledge base

Wikipedia-logo I've had a lot of different personal knowledge bases in the past. But not everything was working the way I wanted it to work. So just around a week ago I started my own personal Wiki. I used the free service of wikidot.com to create my personal private Wiki.

As a technologist I organized my Wiki based by the different technology I work in. I have code examples, solutions, helpers, and other things. Also I often find interesting things on the net which I kind of copy to my Wiki by linking to the source and aggregating the needed information so I can use it fast. This is my own personal short-cut to technology knowledge.

Local History feature for Visual Studio 2005/2008

Years ago, during my study Computer Science I developed in Java. The last of my Java years I made use of IntelliJ IDEA as my Java environment. IntelliJ IDEA is a very intelligent IDE from the same guys as ReSharper. I wasn't using a source-control system but made use of a very nice feature: Local History.

I just found out a CodePlex project: Visual Local History 2005. Visual Local History is a Visual Studio 2005 and 2008 add-in that will provide some kind of Local History. It can integrate with some predefined comparison tools. Sadly it is still in Beta, but will that prevent us from using it? At least it is  released in GPL.

I'm not advocating using Local History as a replacement for source-control, but sometimes the changes you made are very large and it takes some time before you are able to check your into your source-control. I think Local History can work without any trouble side-by-side with your source-control. This way you won't loose any control by not using a source-control. You're even gaining control by the ability to browse through your local changes.

This all sounds very nice. This kind of local history could be nice for using with all kinds of documents.

Super Mario Galaxy

super-mario-galaxyIt's been a while since I last posted about me gaming on the Nintendo Wii.

Yesterday I bought the just released Super Mario Galaxy. I didn't have time to play it yesterday, but today I played Mario Galaxy for about 2 hours. I really like it, it's a very nice game to play, the whole game has some very nice gravity. You are attracted or not, it's all very naturally.

Take a look at the dutch Super Mario Galaxy site to get an idea about the game-play. Also Google Video about Super Mario Galaxy.

Personal Performance Indicators (PPI): Tool support on it's way

In the past I talked about Personal Performance Indicators. The last months I've had a few hours to build basic tool support for Personal Performance Indicators. It's all pretty basic. The UI looks like the following.

first-preview-ppi 

The whole tool is based on plugin-support. The two personal goals are configured using a 'periodic' plugin which will be part of the first release.

I can think of other plugins, build by others, or by me. Think about an excel-sheet you use for keeping track of your productivity in hours a week. You already use this excel-sheet, but it could be nice to have an indicator showing if your productivity is on track, isn't it?

Technical details

Now it's time for some technical details. The user interface makes use of Component Factory's Krypton Toolkit, and is very basic. By all means it should be very basic, a goal with an indicator, not much more. Off course the needs to be some additional buttons for configuration of the goals and/or plugins. But this needs to be a very clear user interface.

What about a class diagram for the plugin interface.

first-preview-ClassDiagram

Every plugin has to implement a pretty basic IPlugin interface. It just delivers a few basic strings, and a more complex list of indicators. Every indicator has to implement a basic IIndicator interface.

Besides this the application as a host delivers an implementation of IPluginHost. This is some kind of repository based on db4o, but this basic interface can be easily mocked for testing purpose.

Maybe more on the Personal Performance Indicators tool in the near future.