The Weird, Wild, and Counterintuitive World of Fund Management Database Structure

By Ben Hendershot

Let’s geeks out on databases here for a bit. I’m guessing that most people who use or are evaluating fund management software don’t spend their days thinking about proper database structure. They already have a full-time job, after all, and I’ll be the first to admit that the topic of database structure isn’t exactly the sexiest or most exciting thing to talk about at parties.

Proper database structure is, however, key to getting organized, insightful, and actionable data out of the system you’re likely to be spending thousands of dollars on. It is also, unfortunately, often counterintuitive to a lot of the fund managers I talk to who are in the market for a new system or in the process of building their own.

(Incidentally, if you do really want to geek out on database structure, a good place to start is the Five Normal Forms in Relational Database Theory. Warning: it gets complicated quickly).

A common example of this counterintuitiveness is when users want to store everything they know about a given company on that company’s account page. This is where you might intuitively go to find out what stage you are in with that company or how much you have invested in them in the past, so it makes sense to cram as much historical information about that client on the same page, right? Well, no.

The reason that this is a bad idea is because you’re likely to evaluate that same company more than once over its lifetime and if you’re tracking due diligence on them in your database you’re either going to end up overwriting that data when you evaluate them again–at which point that information is then lost and of no value to your firm–or you end up stuffing that account record with disorganized historical data that is very difficult to report on or deduce any valuable insights from.

A lot of people make the same structural mistake when tracking post-investment data. I’ve seen plenty of databases in which a prospect has created a bunch of fields at the account level that are called “Investment 1,” “Investment 2,” “Investment 3,” etc. It looks like it might work; if you’ve never made more than one investment this seems like a logical place to store investment data. But what happens when your firm grows (hopefully it does) and you get to investment 11 or 12? You’ve got to add a new field each time which not only wastes a lot of screen real estate but also makes that data nearly impossible to aggregate easily. Before you know it, you’re six months or maybe two years into a new database and its already a tangled rats nest of data.

This is when we usually get the call to come in and untangle a custom-built system or maybe a competitor’s system and install a system with the correct database structure. Or, if you want to save yourself a year or two and a few hundred thousand dollars, give me a call and I’ll tell you what the correct structure is.