Marnen Laibow-Koser wrote:
Will Merrell wrote:
Marnen Laibow-Koser wrote:
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.
If the OP's problem really is lots of truly independent attributes,
selected from a finite list, with a limited and known number of repeated
attributes, then yes, wide and flat, (the OP's option A) is probably an
optimal solution.
But, that is not what I read in his post. How many pools should he be
able to capture for a property? Can a property have six doormen? What
about the property with the helipad? The problem with wide and flat is
that it requires a fixed problem domain. Cleaver as I am, I can not
fully anticipate what crazy examples the real world of the users is
going to through at my system.
As I read the OP's description I saw that the list of features he needs
to capture is not fixed and that some features could occur multiple
times. To me that demands that features be objects in their own right
and that the database design should capture the relationship between
properties (et al) and features. There are at least two tables here,
properties and features. The exact structure (and number) of these
tables is a second question.
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.
Thank you for the link, I see what you're driving at. I mostly agree.
Certainly in the case discussed in the thread you linked to the
key/value pattern is a bad idea, and should be avoided.
There were really two intents in my original post. The first, and most
important, is that there are other ways to solve the OP's problem beyond
the two that he presented. His first seemed to me too simplistic and
headed for trouble (as discussed above) and the second seemed too
complex and also headed for trouble. I simply wanted to suggest that
there may be a third choice. Whether my suggestion is that better choice
is a separate issue.
The second point i wanted to make is that the recording of a feature
need not be very complex. The presence or absence of a record may be
sufficient. What the OP needs to record about a given feature probably
needs a good deal more thought and discussion, but the existence of the
feature can be very simple, and just naming it may be enough.
I really do agree that recording a feature as a collection of key/value
pairs is almost certainly a bad idea, and I did not intend to suggest
such a structure. If you heard that in what I posted then I did misspeak.
I think what we both mean to say is that good database design requires a
good understanding the problem space. Duct tape and bailing wire works
for MacGuyver, but not for the rest of us.
-- Will
--
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.
