Andrew Pace wrote: [...] > > (SQL is below, but I try to explain here for clarity) For example, > let's say I want a user's table in the database. I will usually > create it with only necessary information. Name, username, password, > timestamps, etc.
What do you mean by "only necessary information"? If information is unnecessary, you shouldn't be storing it. If it is necessary, you should bother to design a proper DB schema. This is true regardless of whether you're using PHP, Ruby, Python, Perl, BASIC, or Lolcode for your application. :) > Then I set up a "users_profiles" table that is > essentially a table with only three columns (1. A reference to the > user_id, 2. A 'key' column (varchar), and 3. A 'value' column > (text).). So the key column is a type descriptor for the value column, so that you might have user_id | key. | value 1 | email | j...@aol.com 1 | phone | (555) 123-4567 1 | birthday | 4 Jul 1976 2 | birthday | 02/12/1982 ? If so, then let me tell you that in most cases, this is a bad habit in any language context. It basically defeats the purpose of having a structured database by munging all the data into a single text column. This makes queries harder. For example, how would you search for all users with birthdays greater than a certain date? Heck, how do you store data in a consistent way (was user 2 born on 2 Dec or 12 Feb)? There are situations where extremely flexible databases like CouchDB without a consistent record schema may be beneficial. But storing user information is probably not one of them. [...] > Does anyone know if this would be considered a poor way > of managing data in the "rails way". This would be considered a poor way of managing data, period, because it doesn't manage the data -- it just stores it in a messy way that makes querying difficult. (If you *must* do something like this in Rails, consider serialize. But avoid it if at all possible) > It seems to me that it would > function similarly, in that it would save a lot of updates with the db- > migrations. There's no advantage to saving migrations just for the sake of saving migrations. The structure of the DB should, as far as possible, reflect the structure of the data, not a half-assed design that a lazy programmer came up with because he didn't want to bother figuring out what he needed to store. > > Thank you in advance for your help! > > Andrew Pace > Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
