Best way to implement?

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.

Can somebody help me out?

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 [ ]. 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.

Regards, Craig

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.

Regards, Craig

That could be an option...maybe the best. Does anyone else know of a better way before I try it this way?

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.

Jeremy wrote:

Can somebody help me out?

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):

# Table name: reflists

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:

<label>Bedrooms</label> <%= @listing.bedrooms.count %>

<label>Bathrooms</label> <%= "#{@listing.bathrooms.count} Full, #{@listings.halfbaths.count} Half" %>

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. :slight_smile:

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.