Thread

Hello there,

I’ve had a bit of a search around the forums and documentation, but haven’t quite found an answer… I was hoping someone database-minded might be able to give some insight and advice on the following.

We’re developing a real estate website where we need to store different types of properties. Usually we would set these up as one channel (“properties”) with different categories, but we were wondering whether there would be any performance benefit to splitting up each type of property into their own channel? (Is it much more efficient to query just a channel, rather than filtering by category?)

Other info:
- There will be 5-6 different types of properties.
- There will be ~1000 entries for each property type. (Would the efficiency be irrelevant at this size?)
- One type of property listed at a time. (No combined channel/category queries.)
- We’ll be using pagination, searches based on custom fields, and filtering by categories/subcategories.

Thanks very much!

Hi Josh,

Thanks for your question!

I think the best approach would be 1 channel and use categories for the property types. Especially if the types of information will be the same.

I look forward to your reply!

Cheers,

I pretty much agree with Dan, unless properties have vastly different needs for custom fields it’s much easier to use a single channel with custom fields to cover any type of property - in reality most property information is universal so this would save lost of duplication.

You can always use custom fields for property specifics - on one property site I did I used a mixture of custom fields, categories and Statuses to define stuff eg,

1. Statuses
- For sale
- New to market
- Sold
- Under offer
...etc

2. Custom fields

a) Property type
- Detached
- Semi detached
- Bungalow
- Flat/Apartment
- Land
- Commercial
...etc

b) Tenure
- Freehold
- Leashold
...etc

3. Categories - used for areas/locations

Using this approach you can obviously use categories to filter by location, but then use Dynamic parameters to filter by status, property type, tenure or whatever setup you have.

Is it much more efficient to query just a channel, rather than filtering by category?

I love this question, and the answer for me is “it depends on your priorities”.

Is your number one priority:

1. (computers) Screaming fast page loads (don’t make the computer work too hard)

2. (front-end user) Human Friendly Navigation with Nested URI’s (don’t make the user think too hard)

3. (back-end publisher) A content entry experience that requires little or no training and encourages proper data entry. (don’t make the publisher think too hard)

My firm tends to let computers work a little harder if it is to the benefit of the users and publishers.

If the property types are clearly defined (no property might fall into two or more types) then splitting things into channels might just make more sense for the users, and the publishers, especially if using “sort-style” search like in the EDIT tab of EE. So even if it doesn’t help the server have an easier day, life will be improved for the humans.

——-

For our property site, we actually chose to go the route Dan and Rob mention, but we didn’t have as many properties as you do. Our challenge was that each property had up to three different types of apartments, and might be for rent now, or in the near future, so we needed some way to make that easy for our publisher so that the information on the site remained up-to-date and accurate.

We ended up building a special tab in the CP that lets the publisher store information about the different apartment types in each property and when an apartment of that type is available. (see screenshot for example) This way the publisher just turns the different apartment types on and off based on availability and doesn’t have to re-enter info each time. Also, we could use the info to dynamically populate a “current vacancies” page saving the publisher yet another task.

The site is: http://reachcdc.org/properties/all-communities/

Really helpful replies, thanks all!

Regarding priorities, there are some extra influences that I should have mentioned (I didn’t want to bog you all down with the details!):

- Back-end users are unlikely to edit the properties from within EE. (They’re entered in an external system).
- The properties will be imported into the system from XML through Data Grab or Importer.
- There are nearly 100 custom fields in total in a shared field group, however about half of these are only relevant to certain property types.

So, thinking through Kurt’s priority list:

3. Front-end user
In terms of user-friendly URLs, I’ll be setting up a custom template structure that is somewhat unhooked from channels and category paths, so I think the effect will be negligible either way (channels vs categories).

2b. Back-end user
As mentioned above, back-end users will probably not edit property entries. If properties are edited by back-end users some time in the future, multiple channels would allow for custom publish page layouts, which would be beneficial with the large number of fields. (Though admittedly, one channel could have fields arranged in different tabs.)

1b. EE
To import the properties, the importer add-on needs to run once per property type, and again for each additional category (this is the case with Solspace Importer, at least). So this is a small negative point against extra categories.

1a. Server
Given that front-end and back-end users are a minor concern, the server-side effect of channels vs categories is therefore my highest concern.

I’m guessing that querying a channel and then filtering by category would be more intensive, so I’m currently swaying towards multiple channels, especially given that there will be further filtering and searching on the entries.

Any further suggestions or technical titbits would be appreciated 😊

—

Vaguely offtopic: Nice website, Kurt! The apartments would have been a bit tricky. Did you think about using a Matrix field or setting up the apartments as a channel and linking them via Playa? (Or did you think the extra add-ons would be a bit overkill? What you’ve set up looks very usable!)