Spikeh'd

I've spent many years debating with my fellow developers across all manor of subjects (I do love to talk), but one subject that comes up time and time again is the usage of the UNIQUEIDENTIFIER data type in SQL Server; especially when they're used as identity and key columns. In fact, I see this more often than you would expect, and misconfigured UNIQUEIDENTIFIER columns can create "hidden" problems that can be difficult to discover and / or rectify, depending on the SQL experience throughout your team. If you care to ask around your colleagues, it's almost guaranteed that you'll get multiple conflicting opinions on why you should or should not use GUIDs in SQL Server, but few developers actually realise the impact of such a design choice. In the interests of science, I'll try and keep this as factual as possible, and I'll focus on the topic at hand, rather than GUIDs / UUIDs in general. Here's a list of common reasons for using a GUID in your d...

I've been doing a lot of database analysis recently, and fortunately I'm one of those people that enjoys it. I'm primarily a .Net developer, but I've spent many years looking after SQL Server databases, helping out (and even educating) DBAs, writing ETL packages and designing both large and complex databases. The database in question was in pretty bad shape; missing, unnecessary, and extremely fragmented indexes, missing primary and foreign keys, bad normalisation, and (the main reason I decided to look into it) undesired table locks during ETL operations. It's a 24/7 system, and live lookups are performed around the clock - data is imported early in the morning (when usage is at a minimum), which is when most of errors occur. Amongst many other pre-emptive actions I've recently performed on the database, I decided to set up regular table index maintenance job to keep queries as quick as possible. Unfortunately the database is SQL Server Standard edition, an...

Last Friday I smoothly installed MVC 3 via the Microsoft Web Platform Installer. Having not used it before, I was impressed... it was quick and easy, though I did get a few reference related errors in Visual Studio shortly afterwards. Regardless, I decided to have a look at the other packages on offer. After reading a few posts on Scott Hanselman's blog, I skipped off on my merry way towards the WebMatrix package, so I could have a play with the new Razor engine with standard ASP.Net pages. Unfortunately when selecting WebMatrix, the Web Platform Installer seems to hang on the first step (SQL Server System CLR Types [Step 1 of 5]): I've tried it a few times - rebooting, closing all applications / non essential services etc, but nothing seems to help. After a little bit of digging, I figured out that the WPI keeps log files in the following directory: C:\Documents and Settings\[USERNAME]\Local Settings\Application Data\Microsoft\Web Platform Installer\logs One file in...