You could argue for and against this kind of abstraction. By factoring it out you reduce the number of fields in the database, you reduce repetition, you have a model to put name related logic in if there is any and it is easier to implement changes in the naming convention later. The draw back is that the data structure becomes a bit more complex, which will affect most the CRUD operations on those tables. It's probably overkill for only two tables, but could be worth it if there are a lot of them.
My attitude is always to try new things if you've never done them before. That way, the next time you face a similar design issue, you have some first hand experience to base the decision on. Try it. If it doesn't work out at all, it wouldnt be too difficult to refactor. I would structure the models different, using a polymorphic association: class Name < ActiveRecord::Base belongs_to :nameable, :polymorphic => true end class User < ActiveRecord::Base has_one :name, :as => :nameable end class Customer < ActiveRecord::Base has_one :name, :as => :nameable end On May 18, 3:15 pm, Tim Lovett <timo...@gmail.com> wrote: > Are customers different than users? > Can customers also be users? > > I'd say you should probably just put the customers and users table into one. > You can create a table that links off of users that links them to orders > (customers) if the need arises. Or if they are two separate roles can always > have a flag that denotes it. > > The normalization is fine on the name breaking it out to its pieces. > > The problem arises though when you try to break off users and customers that > if they are the same person they likely will need to reinsert all of their > previous information when signing up. It just adds messiness to the database > and makes it harder to associate their information with the user without > somehow getting the original table's name id back to the new one. And > imagine if they have two separate name ids... then they have to go and > update their values in both tables. > > I'd personally suggest you combine all three tables unless there is a clear > distinction between customers and users, > > Tim > > > > On Tue, May 18, 2010 at 8:58 AM, pepe <p...@betterrpg.com> wrote: > > I'm working on application where several tables > > (users,customers,other...) will have the same name structure (prefix, > > first, middle, last, suffix). > > > I have thought about factoring out the name to a separate model: > > > *** Migrations *** > > class CreateNames < ActiveRecord::Migration > > def self.up > > create_table :names do |t| > > t.string :prefix > > t.string :first > > t.string :middle > > t.string :suffix > > end > > end > > end > > > class CreateUsers < ActiveRecord::Migration > > def self.up > > create_table :users do |t| > > t.integer :name_id > > # other columns here > > end > > end > > > class CreateCustomers < ActiveRecord::Migration > > def self.up > > create_table :customers do |t| > > t.integer :name_id > > # other columns here > > end > > end > > > *** Models *** > > class Name < ActiveRecord::Base > > has_one :user > > has_one :customer > > end > > > class User < ActiveRecord::Base > > belongs_to :name > > end > > > class Customer < ActiveRecord::Base > > belongs_to :name > > end > > > I believe the concept is sound but I am concerned about a couple of > > things. I know that search capabilities by user/customer/other are > > coming and name searches are going to be in the mix. > > > Am I putting myself into a bad situation by going this way? > > Are named scopes going to be my friends? > > What would be the best/fastest way to query the database with this > > design? > > Am I abstracting the DB too much? > > > Thanks > > > Pepe > > > -- > > 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-t...@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscr...@googlegroups.com<rubyonrails-talk%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- > 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-t...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/rubyonrails-talk?hl=en. -- 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-t...@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.
