4 ms·

Of course!! Many thanks. Goes to show we hardly use the DB engine to prevent crap data from being persisted! I blame the Java cargo cult for this. ;-)

by ak39 14y ago

bcostlow 14y ago
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 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.
- ak39 14y ago
  Thanks for the link. What a name for a product servicing the healthcare industry. :-(
- paol 14y ago
  MUMPS has featured several times on The Daily WTF (here's one: http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx). That alone should tell you something...
- gaius 14y ago
  This is funny, because MUMPS actually ticks the modern trendy boxes of "NoSQL" and "DSL".
drbawb 14y ago
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.

Of course!! Many thanks. Goes to show we hardly use the DB engine to prevent crap data from being persisted! I blame the Java cargo cult for this. ;-)

by ak39 14y ago

Of course!! Many thanks. Goes to show we hardly use the DB engine to prevent crap data from being persisted! I blame the Java cargo cult for this. ;-)

bcostlow 14y ago

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 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.

ak39 14y ago
Thanks for the link. What a name for a product servicing the healthcare industry. :-(
paol 14y ago
MUMPS has featured several times on The Daily WTF (here's one: http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx). That alone should tell you something...
gaius 14y ago
This is funny, because MUMPS actually ticks the modern trendy boxes of "NoSQL" and "DSL".

drbawb 14y ago

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.