Database Project Entropy

With every new release of a software product, some features are altered at the request of the majority of users with the aim to improve the product. And generally these changes are correct. Most, but not all. Some are short sighted at best. And if there was one feature change which Microsoft acquiesced to which I just cannot abide by was to remove the automatic creation of the folder structure in Visual Studio database projects. It’s bad enough that they totally did away with it rather than make it opt out, but what really grinds my gears is that all new objects are created in the root location. So now everything can be found in one place, with just the one small problem of having to search through everything else. Folders can now be created at the developers discretion, or they can keep a single long list of files at root. There are so many reasons why I think this is a bad idea

  1. structural entropy; a single list will work fine if it’s a small team of developers, the optimal number being one developer who creates his own structure and changes it arbitrarily as he goes on. Add another developer into the mix and they’re going to have their own ideas on folder structure. Sure, you can have resolve this by having long boring meetings to agree on a standard structure, but this still relies on developers following the structure, and is still open to interpretation. In larger teams on a project that has been around for years there will come a point where the structure of the folders hits entropy.
  2. impedes learning; the benefits of a structure enforced by default means that any new user of that project will be immediately familiar with the structure and will know where to find indexes/tables/views etc. Remove that and you end up with an arbitrarily organised project with a reliance on developers to keep the structure logically organised, which will take longer for a new developer to get acquainted with. If the project dealt with the structure, the developers can get on with development and not maintenance.
  3. Hidden objects; With no structure there’s nothing stopping from a script containing completely unrelated objects in one script, meaning any changes you make could break something in another file that you weren’t even aware of until you build the solution, at least. Nasty lurking surprises like views and triggers can be a particular pain to discover after making changes.

    Now where did I put that view?
    Now where did I put that view?
  4. hybrid structure; most projects I’ve dealt with have been imported from a previous version of Visual Studio, and IIRC you could define whether you wanted to keep the structure. I opted to keep the structure, but now certain developers have realised that structure is no longer necessary, so they just started creating files at root filled with creating files/filegroups and partition functions/schemas etc, but left the rest of the objects in the structure. This is worse than point 3 beacause rather than confusion causing inconsistency, this is laziness causing inconsistency and confusion. It’s infuriating to pick apart a labyrinth of object declaration and slows down actual work in place of boring maintenance of the project which no one wants to do

Course, the counter argument to these points is

  • you just create a structure yourself and follow that
  • other visual studio projects, like C#, do not enforce folder structure, why should SQL be so different?

The first point is not a bad one, but it relies on developers not only agreeing on a folder structure that is robust and makes sense to a new developer, but also voluntarily following the agreed structure. This is idealistic at best, and reminds me of the anarchy vs democracy feature in Twitch Plays Pokémon. It feels like it would be a constant battle to keep the project from descending into chaos without a real collective effort and communication and removing any agendas and egos (ie “my structure is better than your structure” mentality).

w/r/t the 2nd point you do indeed have a list of files at the root of a project for C#. The big difference here is that developers are far more likely to navigate using namespaces than solution explorer, and so the structure is far less significant. In SQL Server Management Studio, the structure is much the same as what it was in the old database projects, so really it makes even less sense to not at least follow the structure that you have in SSMS.

Now I do understand that the folder structure was complex, even for the most basic of database projects, and that at it’s worst the structure was a “one size fits none”, but I’m not convinced that no structure is better than one structure that’s complex and rigid.

The best cure for a hangover is to never drink in the first place: By making folder structure an option we’ll end up with a hangover every morning we work on the project. Some of you may disagree with me and I’ll be interested to hear your points below.

Author: Richie Lee

Full time computer guy, part time runner. Full time Dad, part time blogger. Pokémon Nut. Writer of fractured sentences. Maker of the best damn macaroni cheese you've ever tasted.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s