That being said, I run into this kind of thing [crap data being persisted] a lot.

I'm currently working closely with ERP (inventory/job management systems, basically.) and tying into these legacy databases.

It's unfortunate because a lot of vendors store stuff in flat-files with no real relational checks or constraints. This bad data gets pushed to my app with an RDBMS and a schema and all kinds of foreign keys and I end up having to dance around the bad data.

What is so unfortunate is that this data isn't necessarily bad. It's all data you need, it just is out of date or inconsistent for whatever reason. You can't really discard it, but you can't really force it into an RDBMS without a makeover, either.

So what you end up with is a generic import routine that has lots of special cases for each different table that has to deal with inconsistent legacy data. It's a fricken nightmare at times.

While I know the article was about the UK, in the USA a lot of clinical data is not stored in an RDBMS.

The software is written in MUMPS, which has a built in (sort of) document oriented data storage layer.

http://en.wikipedia.org/wiki/MUMPS

You can read the Wikipedia page and look at some sample code and draw your own conclusions on whether that's better or worse.

MUMPS has featured several times on The Daily WTF (here's one: http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx). That alone should tell you something...

This is funny, because MUMPS actually ticks the modern trendy boxes of "NoSQL" and "DSL".

Thanks for the link.

What a name for a product servicing the healthcare industry. :-(