Re: Design question

pepe
Tue, 18 May 2010 18:47:53 -0000

On May 18, 10:08 am, Sharagoz
<shara...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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