The First One

So, I have re-named the data structures.  I used the database project template in Visual Studio 2010, and to be honest I wasn’t impressed. As a database management project tool, I found it almost impossible to commit the updated changes back to the database.

But first, let me look at what I did and what I liked and what I didn’t like at each step.  My first step was to use a clean install of the project and get that imported into the database project.  That worked pretty well.  It created one file for each database object (stored procedure, table etc.) which I thought was great.  It created a good structure which was pretty easy to understand (for a non DBA like me).

To me, this structure is very similar to the structure that you see in the MS SQL Studio, which is a good thing in my mind.

Then I did one of the items on my version 2 list for the project, to rename the database tables.  The refactoring was very much in line with the way code gets refactored in VS2010.  It was quick and easy, and every reference was renamed.  Needless to say I did like that.

Now to the parts I didn't like.  I wanted to set one of the tables to save the data within as it was part of the project, not the dynamic data of the system usage. I could not work out how to do this.  I would have thought that a database project would have been able to allocate some default data to the tables, if not mark some tables as having all their data from the project loaded into the implementation of the project.

This leads to my next problem.  I got the source data structure from a database.  I made a relatively simple if somewhat extensive change.  I then wanted to update the database with the changes and it would not update.  Kept on returning a user error or something.  I am going to be honest here.  This to me is the core of a database project.  Writing scripts is one thing.  The ability to use a GUI to manage the code is awesome.  The UX for updating the data structures is not.

As a result, at this time I am not going to use the database project for my changes.  At least until I am able to resolve the 2 issues that I have encountered so far.  So, at this stage I have renamed the database tables, and am about to tackle another of the items on the list.

Audit Again

So, I am reviewing the audit code that I have written.  Following the review of some posts by a friend, I am going to write the next version of the audit functionality that I finished a while back (a whole 2-4 weeks). So, using that as a basis, and ensuring that I maintain the aims set out in the previous version (for a refresher, go here).

Now, the aims for the next version are as follows:

• Process logging, not just a generic log table, but one that is based on each process so that the logging system can differentiate between 2 processes running at the same time.  Also increased logging for better debugging of issues.
• Allowing for the core parts of the audit to be in the line of business database, but still archiving to a separate database.  The audit should be configurable so that it can either run out of the archive database or the line of business database, or both (where the business has 2 audited databases there should only be one archive database).
• Rename the data objects so that they make logical sense.
• Further refractor the code so that there are as many re-usable parts as possible.
• Use the 2010 Visual Studio 2008 Database solution template to write the code in.

That is all I can think of as improvements for now.  If I think of anything else that I would like to add to the next version, I will let you know.

Coding Rules

There are many rules when it comes to coding.  Some can only be bent (they get broken and bugs magically appear); the rest can be broken. The question is which rules are ones you can break, and which can you bend?  Here are some of my thoughts....

Firstly, try to make your code readable.  It might take a bit of getting used to, but try to write code in functions where each function is 10-15 lines long.  There might be a trail to follow to debug the code, but it is better than trying to untangle a mess of one big function that does everything.  It can, when you think about it, also lead to more reusable code.

Know what the function of the code is to be before you start. This is one that can be broken. Whilst we as coders can't know the in's and out's of everything, we do understand functionallity. So, before you start, understand the inputs to what your writing, how it should be processed, and the outputs.  Then take a step back and think about that you need to do. When I do that, it helps me to focus more on what I need to do, and usually means that I only have to do it once.  A trap is to get an outline and start coding without thinking about what you need the code to do.

Finally, be teachable.  In any code that I write, I try to always be of the mind that there is a better way to do it.  It dosent mean that I am always rewriting my code and so get nothing done, but it means that when someone has an idea as to a different way of doing something, I do my best to look at what they are saying objectivily.  Sometimes I am the one who is right, sometimes not.  Many a time fellow coders, and even on the odd occaision non-coders, have suggested changes to my code that would make the code faster, easier to understand or just neater.

Anyways, these are just a few of my thoughts on the rules of coding.  If you have any others let me know, this isn't ment to be a definative list, just some of my thoughts on coding rules.