Design question

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

I think I would just stick with putting those columns on each table.
Is there a specific problem you're trying to solve by abstracting them
out to a separate table? Unless you're trying to remediate a specific
issue, this seems like a solution in search of a problem.

What would be the best/fastest way to query the database with this design?

The fastest way would be to put the name columns on each table. When
the names are in a separate table, you have to do a join just to get
the full record.

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

Thanks Tim,

I think I would just stick with putting those columns on each table.
Is there a specific problem you're trying to solve by abstracting them
out to a separate table? Unless you're trying to remediate a specific
issue, this seems like a solution in search of a problem.

I am not trying to solve a problem, I am trying to design a database
that is as flexible as possible. I am trying to abstract 'entities' to
their own models. In this case the name has the same structure in all
cases and I am thinking it should have its own 'domain'. I am doing
the same with addresses, although I understand the problem is
different because a person can have more than one address but not more
than 1 name (except for AKAs) or if the person is Jason Bourne... :wink:

> What would be the best/fastest way to query the database with this design?

The fastest way would be to put the name columns on each table. When
the names are in a separate table, you have to do a join just to get
the full record.

I understand that but there are also named scopes, which make your
life much easier than coding manual joins. The question specified
"with this design" hoping somebody would be kind enough to point me
into the right direction if I finally go the route I described.

Thanks a lot.

pepe wrote:

I have thought about factoring out the name to a separate model:

Most of this decision depends on how you intend to treat your Users and
Customers. Perhaps you just have people, with a flag attribute on each,
or people with related models of Customer-specific info and
User-specific info. Is a User really different from a Person (will you
track people who aren't users or customers - if so, then Person isn't
abstract)? But only you know the answers to these questions.

I think of names (first, last, middle, full, nickname, etc) as
attributes of some model, not a model of its own...

Sounds like you *could* have a base (abstract) class of Person, then do

class Person < ActiveRecord::Base
  self.abstract_class = true
  # common methods go here
end

class User < Person
  # User table has all the fields it needs
  # User specific methods go here
  blah blah blah

end

class Customer < Person
  # Customer table has all the fields it needs
  # Customer specific methods go here
  blah blah blah
end

if Users and Customers really, really are different entities.

You could also go the STI route...

Thanks Tim,

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.

Users could be customers but customers are definitely not necessarily
users. Imagine a POS application, you have users that effectively use
the application and you have customers to whom you sell products/
services. Those customers' info can be stored in the DB. Some of the
characteristics will be similar but their functions are entirely
different.

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 am adding also a CUSTOMER_TYPES table because there will be several
user types, including an EMPLOYEE type. How we'll handle that will be
a separate issue and we'll probably provide a way of copying the
information from the users table to the customers table.

I'd personally suggest you combine all three tables unless there is a clear
distinction between customers and users,

I believe there is a clear distinction.

Thanks.

I have used STI before and although it works I am not that crazy about
it and in this case I don't think it can be applied because one person
*could* be both a user and a customer.

I like the concept of the abstract Person model, though. I didn't
think about that one and I think it's a good idea. Any links to a
sample of how to use abstract classes? I've never used them before.

Thanks!

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

Someone in the witness protection program might have more than one name.
Then, there are actors with birth names and stage names. And what about
someone with a name like María Rosario Pilar Martínez Molina Baeza? Is that
one name, or many? Sorry, I couldn't resist. :slight_smile:

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.

There is a third table (for now): EMERGENCY_CONTACTS that will contain
the name of the emergency contact person and his/her phone. This is
actually the one that started me thinking about the name abstraction.
I realized that this table will have only the name of the person and a
phone number and I had just created the other 2 tables also with a
name in 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.

That's usually my attitude too but this time I am under a time crunch
and need to get things done asap. I would rather not have to go back
and redo a bunch of changes to the DB and to code when I figure out
that the design is flawed.

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

Not used polymorphic associations yet. Could be a good way of going.

Thanks a lot