Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 20886 invoked from network); 9 Feb 2009 17:28:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 17:28:51 -0000 Received: (qmail 13265 invoked by uid 500); 9 Feb 2009 17:28:48 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 13236 invoked by uid 500); 9 Feb 2009 17:28:48 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 13225 invoked by uid 99); 9 Feb 2009 17:28:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 09:28:48 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 74.125.46.30 as permitted sender) Received: from [74.125.46.30] (HELO yw-out-2324.google.com) (74.125.46.30) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 17:28:40 +0000 Received: by yw-out-2324.google.com with SMTP id 2so380781ywt.5 for ; Mon, 09 Feb 2009 09:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=inXep9iGYg27zXtTOtJMbwMArCk/EkPOtLjqxQxqC2M=; b=FHsOc3TowIN5Q3b+RgpRDig3I3YSGJ0IkEaMdwB7mUiVnhTQHAB5GG3v7Ov6F3um09 8ADPKxKtm57lL+R3Rl/1F4TyVpbKmNcXrM6h9WWboF9Vh9xBMRWlWjGWWTi9mAL3a3dy 3AfjXKynbl7Nkj+Kxkv2/dOnrp9igFhzgG0CE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=H9W65ZEF3F6aFjoQYsT0KHIjFfZS7GdIf0vCcNKBxTbNpyV8XKeEPJUfJuS7X58kQn rhyiVIWAalwCVT3JHWtXAZ6EhTor0RxPMYcGiTY752SNoj2Gklsrg/BY+avEtCphIm6X BepoAvx3uJ6cvUq6s9Bj0GpCHCcXIjmAyZbgU= MIME-Version: 1.0 Received: by 10.100.154.9 with SMTP id b9mr3021154ane.73.1234200499661; Mon, 09 Feb 2009 09:28:19 -0800 (PST) In-Reply-To: <6a8c90ba0902090843u44c60046tcc9ab6d629b2ebcc@mail.gmail.com> References: <5186956f0902082052m43546a8dmb6d9a3ebf9685034@mail.gmail.com> <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com> <5186956f0902090338i2829df1erebaa24a4feea7e06@mail.gmail.com> <5186956f0902090449s76befd76g4cf9ded9f59efc86@mail.gmail.com> <5186956f0902090627y1239b12es505ee80b2d6bd248@mail.gmail.com> <6a8c90ba0902090651q258bb335uf6142ccb25261931@mail.gmail.com> <20090209145701.GR21180@tumbolia.org> <2B705A9C-441C-487C-95E7-B537682F49A7@cisco.com> <6a8c90ba0902090843u44c60046tcc9ab6d629b2ebcc@mail.gmail.com> Date: Mon, 9 Feb 2009 12:28:19 -0500 Message-ID: Subject: Re: [user] Re: The Blog From: Paul Davis To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Feb 9, 2009 at 11:43 AM, Adam Petty 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 wrote: > >> On Mon, Feb 9, 2009 at 10:18 AM, Wout Mertens 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 >> >