So I'm new to all this Rails stuff and this is probably a database
design-related question to, but here it is...
Just for learning I'm trying to build a little real estate listings
application. Of course there is the listings model which will store
basic information like name, price, description, and all that jazz.
I'm to the point where I want to figure out how to handle number of
bedrooms, garages, heat/air, and stuff like that. I'd like to present
those as dropdowns with options in the admin and then of course show
the value when viewing the listing.
So how do I do it? I see that I could extend my listings model out to
have something like bedroom_id in it and then have another model
called Bedroom and it have a value column in it. That works fine to
show my dropdown. I think I might need to be using some join table
for these kind of things, but I don't know enough about it I guess.
It would be overkill to introduce models like Bedroom just so you can present a drop-down that contains a list of numbers. However, I’m not at the point in my knowledge of the Rails view stuff where I could recommend the “best” way to do what you want. Perhaps you could use the select_tag helper [ http://www.railsbrain.com/api/edge/doc/index.html?a=M001871&name=select_tag ]. The only thing I don’t like about that is that you’d have to put in the view the options for what you want to show. In this simple case, though, that might be a good way to start.
Let me just summarize my earlier reply: a simple number_of_bedrooms attribute on the Listing plus the use of the select_tag helper might be a good start.
Sorry that I left off the summary and spread this across two replies.
In this case, to store the number of bedrooms for a specific place, you
should really just use a num_bedrooms field. You don't need a join table
or any model for Bedroom because bedroom doesn't contain any
information.
You would only need a Bedroom model if users specified specific
information about each Bedroom for instance
For instance, if users entered information for every bedroom:
type: master
space: 500sqft
windows: 3
etc
then a Bedroom model (linked to the property) would be a great idea.
Save that, just use an integer column in the table.
I'd think that you'd want a generic Room model, and have the type and
dimensions be attributes of the room. After all, there is a huge variety
in the numbers and types of rooms in any particular dwelling.
Something like:
Room
listing_id (a room belongs to a listing, no?)
room_type
room_dimensions
room_notes (space for stuff like "New Hardwood Floors!" or "New
Tile!")
+ whatever else you decide is important for a room
The room type could be served from another model/table. I typically use
a model called Reflist to store all my 'reference' lists that looks like
this (with a Reflists model and views, you can easily add to your
reference lists, leaving it data driven):
Great suggestions, Ar Chron! I was going to suggest something along
the same lines since you really do need to present much more than just
the number of BR (e.g., dimensions) but the number is often an
important search criteria for real estate.
In this case it might be worth checking into Single Table Inheritance
(STI) and creating a generic Room model that is subclassed by Bedroom,
Bathroom, HalfBath, DiningRoom, etc The Listing could then
have_many :rooms, :bedrooms, :bathrooms, :halfbaths, :foreign_key=>:room_id
The reason to do this is that you could fairly quickly:
You'd also be able to create a useful query for people to find a
listing based on #bedrooms, bathrooms, etc but we'll leave that as an
exercise for the reader.
Good stuff...I may very well implement it this way. If I were simply
wanting to store JUST the number of rooms for now, would hard coding
the values into the select box be the best way, or is there another
best way to store just the number of rooms?
The only thing I can think of that might be worth considering is
acts_as_configurable. This allows you to easily add and remove
fields, but without changing the database every time. However, since
you are probably going to want to do a search on these fields (i.e.
"find me all the houses with 2 bathrooms and 3 bedrooms"), I wouldn't
recommend it.
Now, if you have an option with strings instead of numbers, like an
enumeration, say for instance floor plan style, or maybe brick vs.
wood vs. siding vs. stucco exterior, having a separate join table may
make sense. Numbers are much easier to search for and compare than
strings, and will be slightly faster. In your app, don't actually
join the table (because then you are back to comparing strings within
the joined table), just search for the correct numeral. The join
table is just internal documentation to help you remember what each
number means.
Hard coding isn't evil, it can just be more difficult to maintain.
Rather than hard coding the options into the view, I'd create a
constant in the model that contains an options array, e.g.,
NUMBER_OF_BEDROOMS = [1, 2, 3, 4, 5]. You could then reference this
constant in a helper in the view as Listing::NUMBER_OF_BEDROOMS. It
might keep your view cleaner.
All valid suggestions, but I don't think I've never seen real estate
listings with the kind of information that's being discussed here.
Perhaps if it were a B2B site dealing with new real estate
development, but that wasn't what was described in the original
request.
I'm to the point where I want to figure out how to handle number of
bedrooms, garages, heat/air, and stuff like that. I'd like to present
those as dropdowns with options in the admin and then of course show
the value when viewing the listing.
num_bedrooms, bedroom_count, or whatever you decide to call it is a
simple scalar that will be common to basically every residential
property, so creating a Room model is way, way beyond what's required
in my opinion. The same thing can be said of a garage flag (boolean)
or number of garage spaces (integer) and most if not all other data
fields relating to properties. Given the description provided for
this application, going for fourth normal form on a project like this
is fine as an exercise, but practically speaking, it's going to add
unnecessary complexity and slow down DB operations and page rendering
unnecessarily.
