Will Merrell wrote:
> Taylor Strait wrote:
>> I am trying to decide between two different database architectures for
>> an application to manage properties. For capturing the property
>> features, I have two options: a single model/table with all the features
>> as fields, or a set of joined models - property, feature, feature data.
>> (see attached ERD diagram)
>
> You're right that option A is pretty much a bad idea. I can't tell you
> how much time I have spent refactoring databases that were *guaranteed*
> never to change.
That shouldn't be a problem. Broadly speaking, it is better to refactor
a database tomorrow than to overdesign it today.
> In that sense option B is much better.
>
> However, there may be a solution between the two.
>
> Consider the following table:
>
> Features
> id
> name (the name of the feature: 'pool', 'doorman', or whatever)
> featureable_type ('property', 'unit', or 'room')
> featureable_id (property.id, unit.id, or room.id)
>
> With this, you just add whatever feature you want. If the record exists
> the property has the feature. The name field can be user enterable, or
> you can fill it from a listbox if you want to control what the user can
> enter. The list can even be editable by an admin if you want the control
> and the extensibility.
That's terrible! It defeats the point of having a database. Don't ever
do that unless there's absolutely no alternative.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
