[Rails] Re: Learning some best DB practices

Thanks

On Jul 31, 11:11 am, Marnen Laibow-Koser <mar...@xxxxxxxxxx> wrote:
> On Jul 31, 1:43 pm, Andrew Pace <andrewpp...@xxxxxxxxx> wrote:
>
> > Also consider the demands of a very very rapidly changing field, like
> > medical informatics.  In this area, many prefer the flexibility of a
> > key/value system because adding columns constantly would be a
> > nightmare.  
>
> First of all, in a typical application, user profiles contain a well-
> defined set of data, unlike the case you are describing, and so it
> should be possible to design a real schema for the data without too
> much trouble.
>
> Second, part of the point of Rails' system of migrations is to make
> database changes *not* a nightmare.
>
> > Think off adding columns for every new lab test, imaging
> > type, procedure, etc.  
>
> If you're doing that, then you're doing something wrong.  This is
> where a bunch of linked tables come in handy, as well as (perhaps)
> some limited use of the key-value pattern, or perhaps some serialized
> arrays to represent complex results.  But this is a solution of last
> resort when the data does not lend itself to a less amorphous schema.
>
> > This is where a system like this is extremely
> > helpful.
>
> Perhaps.  But this is not your use case as you've described it, so
> your bringing it up is a red herring.
>
>
>
> > Another addition that can sometimes be helpful is to add an additional
> > column that holds a "datatype" that represents a traditional database
> > constraint.  
>
> And at that point, you might just as well build a proper database
> schema.  Outside of a couple of special cases, there's so much wrong
> with this idea that I don't even know where to start.
>
> This allows for easy programmatic testing against this
>
> > datatype before the data enters the database.  Obviously this requires
> > some programming work up-front, but this can be exceedingly useful
> > once it is built.  Again, flexibility is the key here.
>
> > Some links:
>
> >http://ycmi.med.yale.edu/nadkarni/eav_CR_contents.htm
> >http://www.cdc.gov/nedss/DataModels/index.html
> >http://www.research.ibm.com/journal/sj/461/eggebraaten.html
>
> These basically seem to talk about reinventing database features
> within tables -- even to the point of storing metadata.  That way lies
> abstraction inversion.  Don't reimplement what the database will
> already do for you -- unless you have a very good reason to do so.  In
> your use case, you don't.
>
>
>
> > Andrew
>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...@xxxxxxxxxx
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---