3 ms·
Sure the guys language was imprecise, but the SQL implementation of the relational model was imprecise as well, so we call all get it wrong with gay abandon. T
by artsrc 16y ago
Sure the guys language was imprecise, but the SQL implementation of the relational model was imprecise as well, so we call all get it wrong with gay abandon.
The funny thing about relational databases they model relationships fairly loosely, mostly understood and expressed by the user, not the system. Object systems have a stronger idea of a one way relationship with a reference anyway.
How many systems should care about relationships. All of them can.
Here in Australia they want to put everyones health records online, and connect all the hospitals, doctors, drug stores, testing labs, etc. to those records.
So far they have spent heaps, $500 million'ish, on a system that does this:
http://www.abc.net.au/rn/healthreport/stories/2010/2975642.htm#transcript http://www.abc.net.au/rn/healthreport/stories/2010/2975642.h...
I think this is a good place for something like a non-relational database. You just create a sequential list of events for a person and you are done.
You can use something like CouchDB. If you loose your network, you can have a local replica at your local hospital and doctors office. Everything re-syncs later.
I think the whole thing is in analysis paralysis because they are trying to systematize the health universe so the meaning of all data is unambiguous. While that sounds grand it will take forever.
I blame the whole failure on a drive to systematize data, which SQL databases foster. If you just view health records as a bunch of bits of paper, and just say we want to store them in one place, in a way that is vaguely sequential, the problem is much simpler.
CouchDB is after all web scale, shard friendly, and there is no impotence mismatch. After seeing this video I am always going to want to say it that way.
- ergo98 16y ago>I blame the whole failure on a drive to systematize data, which SQL databases foster. If you just view health records as a bunch of bits of paper, and just say we want to store them in one place, in a way that is vaguely sequential, the problem is much simpler. It's simpler, and tremendously less usable.
- lars512 16y agoA system that's actually running is more useful than one just planned. Really though, current paper records are "document oriented databases", where each record is self-describing (at the cost of redundancy) and access latency is the biggest issue. Upgrading to electronic document oriented databases would actually be a very natural fit, whilst still leaving open the possibility of further relational optimization in the future.
- ergo98 16y ago"A system that's actually running is more useful than one just planned" Absolutely. To go back to the original point, I don't think it's document-centric or not that causes the massive cost overruns. Instead it's that big consulting companies know that they can absolutely ROB the government blind and get away with it. Here in Canada we've seen the same farce with the long gun registry, with the health records here in Ontario....just about any government-related project is a boondoggle.
- artsrc 16y agoI worked on a project at a bank that started insignificant, and became significant and the loss of quality and the increase in waste was phenomenal. It is great perceived importance that makes a boondoggle. A few employees, government or otherwise, doing a project of no great significance, will not waste much.
- ergo98 16y agoI'm not quite following, however the projects I am talking about have pissed away hundreds of millions to over a billion dollars. That is what makes them significant.
- artsrc 16y agoIf people did not consider those projects in significant in some way other than costing millions of dollars, they would cancel them. Being insignificant creates a need of efficiency.