Will Merrell wrote:
> Marnen Laibow-Koser wrote:
>>> 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.
>>
>
> I'm certainly not in favor of over design, which is why I suggested
> something in between. That said, I have rarely seen a case where wide
> and shallow is the proper solution.
Likewise. But the OP's problem -- lots of independent attributes -- is
one such case.
> The OPs problem looks like it needs
> some kind of normalization.
Nope! The table is already well normalized, I think. If you disagree,
please tell me what normalization condition is being violated.
>
>>> featureable_type ('property', 'unit', or 'room')
>> do that unless there's absolutely no alternative.
>>
>
> Could you say a little more about which part of this you find terrible.
> I have used techniques like this for some situations, and have seen
> others use it also.
Oh, it gets used, all right -- by people who either are dealing with
unusual situations or don't know how to use a database properly.
> If I'm missing something I want to know. If I
> misspoke, I want to clean it up.
Then just avoid this pattern altogether. See discussion at
http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/2ee6d1546a20409e?fwc=1
for more information.
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.
