Thanks
On Jul 31, 11:11 am, Marnen Laibow-Koser <[email protected]> wrote:
> On Jul 31, 1:43 pm, Andrew Pace <[email protected]> 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
> [email protected]
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
