[Rails] question about host web based application using rails

[Rick Bradley]

* ChongQing Xiao (CqXiao at epicsystems.com) [041215 17:30]:
> I plan to design a web based EMR system to be used by small clinics.
> The database might have many tables, say patient, provider, schedule,
> user, user_role.
> 
> For different clinics to use my web based application, their data has to
> be separated from each other.
> 
> If I use one database, one suggesting I get is to create a one to many
> mapping table for each table in my database. (Joe, please correct if I
> have a wrong assumption here)
> 
> Say Customer_to_Patient, Customer_to_Provider, Customer_to_Schedule and
> so on. (Customer means each clinic that will use my application)
> 
> I think this will work but sounds like a big overhead.

Getting more specific probably requires more knowledge of the business
arrangements your customers will actually have (which might actually
require a crystal-ball on your part since these might not be made clear
until you bring on a new customer with a different setup).  The overhead
for mapping customers to their various associated resources shouldn't be
that high -- and if it is, profile the code and optimize it. 

Your business domain (with which I'm familiar, having maintained and
working on rebuilding a medical workflow application -- so the customer
entities have the same general layout as in an EMR) requires a degree of
freedom at the customer<->resources level that is best represented
relationally as either one-to-many or many-to-many mappings (depending
on whether you've got things like subcontractors involved or not,
hopefully not), and I can say with some confidence that the developer
time gained by doing this the clean relational way with a
high-productivity tool like Rails will pay off in the long-run.

If you find that having all these mappings in place slows things down,
do your profiling and keep in mind a couple of obvious possible
optimizations:

  - Many times interactivity is hampered by being forced to repeatedly
    pull together disparate table relationships to build a state map for
    things like permission checking ("can user X update object Y?", "can
    customer A view the list of documents from Provider B?", etc.).
    This can often be relieved by loading the relationship graph into
    the session once and keeping it around over many transactions.  This
    can become slightly more complex when you need to be informed that
    some component has changed, but can be dealt with.  Storing
    dependent object graphs as CLOBs/BLOBs isn't unheard of either.

  - Speeding up session and database access through fast caching can be
    effective as well.  I keep speaking about this in the future-tense,
    but memcached looks as if it will make a great fit with Rails for
    fast session retrieval (probably even breaking session affinity in a
    cluster) as well as speeding object lookups.  For many objects
    (Customers, Providers) an EMR is read-heavy.  Even for the documents
    in the EMR typically they are written much less than they are read.
    This provides a potentially good mix for optimizing by methods like
    these.

Best,
Rick
-- 
 http://www.rickbradley.com    MUPRN: 325
                       |  one empty set, so
   random email haiku  |  nothing can contain IlyaZ>
                       |  more than one of them.