incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: [user] Re: The Blog
Date Mon, 09 Feb 2009 17:28:19 GMT
On Mon, Feb 9, 2009 at 11:43 AM, Adam Petty <adamjpetty@gmail.com> 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.

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.

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 <paul.joseph.davis@gmail.com>wrote:
>
>> On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens <wmertens@cisco.com> 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
>> &trade;.
>>
>> > 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
>>
>

Mime
View raw message