On 9 Feb 2009, at 18:28, Paul Davis wrote:
On Mon, Feb 9, 2009 at 11:43 AM, Adam Petty <[email protected]>
wrote:
If a hospital starts to move to an SOA - and all the business logic
gets
abstracted to the web services that each department exposes in the
use,
transmission (security) of data... wouldn't that then become almost
the
perfect place for couch?
Now if it's already in Oracle - I can see how it might not be smart
to
retool just for couch, but starting from scratch, I can't think of
anything
that goes on in a hospital that doesn't revolve around physical
documents.
I've done consulting for medical records processing companies - but
not for
hospitals themselves - any specifics as to why this wouldn't meet
requirements?
I saw the schema for an Oracle db used in production at a teaching
hospital. It still gives me nightmares. This was the general business
database not related to things like patient records etc. Ie, it tracks
which doctor is on what rotations in which department. AFAIK, it
basically ran everything *except* patient records. Personally I'd
probably pick up a commercial solution for things like medical records
for liability alone.
I think for the sake of the argument we're assuming that we're building
a new commercial solution on top of CouchDB.
The larger picture here though is when business logic and consistency
are more important than availability and partition tolerance. These
are systems that are designed to be run on a single machine with
perhaps a hot spare etc.
A double-write proxy in front of the master & hot spare and not using
replication gives you CA!P instead of !CAP. CouchDB lets you even
make the choice. It is moar bettar! :)
Cheers
Jan
--
In other words, these are not your Web 2.0 "Let's have an ORMgy!"
databases.
On Mon, Feb 9, 2009 at 11:12 AM, Paul Davis <[email protected]
>wrote:
On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens <[email protected]>
wrote:
On Feb 9, 2009, at 3:57 PM, Noah Slater wrote:
On Mon, Feb 09, 2009 at 09:51:18AM -0500, Adam Petty wrote:
Could this thread be added to the wiki - with only minor
editing for
length
- maybe as "a RDBMS vs couch 'Discussion' ?" or something
similar?"...
We've learnt from the book that such comparisons tend to be
harmful.
They lead people into thinking that there is a direct meaningful
comparison.
Fundamentally, CouchDB and RDMS solve different problems.
I dunno, I think it would be interesting to compare the main
benefits of
each so that you know what the strong points of each are.
For example, suppose you implement schema-free in an RDBMS by
adding a
text
field that contains a JSON string. You still keep some of the
metadata,
like
_rev and _id, in proper fields.
If you stuff a structured string into an RDBMS you're Doing It Wrong
™.
However, thinking about that, it means you will need to re-
implement
everything CouchDB does, like views and replication.
To be honest, I think saying RDBMS and CouchDB are for different
solutions
is just you guys being nice. I think that any application would
benefit
from
using the CouchDB model and only in very specific, very demanding
cases
an
RDBMS would be better. I can't think of any examples though.
So here's my challenge to the mailing list, it's pretty much the
same one
that MrDonut posted: Give us an example of something that would
be better
be
done with an RDBMS and something that would better be done with
CouchDB.
I'll help you: I think it would be easier to create a wiki with
CouchDB
than
with an RDBMS. It is possible in both but CouchDB just makes it
easier. I
suppose we'd have to ask the http://couch.it guys to know if that's
true.
I don't know what would be done better in an RDBMS. Performance
logging
perhaps? Something with really stringent schema requirements?
Wout.
Things that CouchDB is better at:
The interweb.
Things that an RDBMS is better at:
Huge amounts of business logic. As in the Oracle install running
your
favorite hospital. Think along the lines of 10's and 100's of
thousands of lines of app logic in the DB itself.
HTH,
Paul Davis
