On Jul 31, 1:43 pm, Andrew Pace <andrewpp...@gmail.com> 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-Koser http://www.marnen.org mar...@marnen.org --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
