Size of RETS database?

[wilmrewebdev]

I have been tasked to redesign a realtor's website (in the Philadelphia / TREND market), which will include a feed all of the team's current listing, neighborhood listings, and open houses.

I am leaning towards implementing the following solution:

- VieleRETS server to interface with TREND MLS server once a day to replicate the active listing database locally
- WP Realty Wordpress plugin to access locally stored RETS data
- AgentPress by StudioPress theme
- WordPress 3.0 (as soon as it is released) simply because of its multisite capabilities

By implementing the local RETS server, I want to eventually be able to host multiple real estate sites.

MY QUESTION: what is the typical size of the entire TREND active listing (IDX) database? in GB, and number of listings? also, how many listings are typically in the Sold (IDX Plus Sold) database?

TREND calls the feed IDX, but apparently, it is really RETS data:
http://www.trendmls.com/Guest/AgentTools/IDX.aspx

I do not yet have access to the database, however, I need to make some rough server hardware calculations to estimate how much resource I will need to deliver this application.

Is anyone else on this forum developing real estate sites in the Philadelphia TREND market?

Thanks in advance your your help.

[Jared]

Hey I stopped by just to answer your question because I see this a lot. I can easily answer the question below by saying it really depends on the market and that market is one of the larger ones which should be at or about "X Amount" But there are ways to approach this that you should consider. I'll quote your question and then answer it the long way around.

MY QUESTION: what is the typical size of the entire TREND active listing (IDX) database? in GB, and number of listings? also, how many listings are typically in the Sold (IDX Plus Sold) database?

Every single MLS is different enough that its not really easy to answer the "size" or volume of the data you can expect to download. This is for more than just obvious reasons naturally as it applies the actual physical size of the data itself. Factors that matter first deal what the individual client, what he/she wants, expects and or needs.

Its always been my practice in all projects I approach to only use the data home buyers are likely searching for in addition to those fields essential to initiate a call to action. A website servers many purposes but for Realtors most would agree the primary motive is to market real estate listings and their services. For this reason I frequently educate Realtors that downloading data that may have little or no meaning to their visitors is a pointless waste of space and time. Realors tend to like all the "Bells and Whistles" which is fine, but the choices they make reflect heavily on the size of the data you will end up downloading and using.

MLS Images
Its been argued here and there that a person can gain some SEO benefit in having images with MLS ID in the image name on their site. There is literally NO evidence of this. As such, if you can avoid downloading the images you should. I would estimate that 90% of MLS providers have caught on to the substantial savings in bandwith by providing URL resources for all their listing images. Most MLS Data feeds now include some sort of image or photo count you can use to script in the logic for hotlinking. There are other benefits as well aside from space and bandwidth the first of which is image updates. Realtors may often update their listings with fresh photos and there are some MLS providers that make it rather difficult to get the updates by time stamp or other means. With hotlinking you stand a better chance of showing the most up to date images available.

MLS Data
Data size can be widdled down if you use intelligent joins of field data. I will often take fields that compliment one another and join them into a single field to save space. An example would be for instance bedroom width and bedroom length, rather than have two separate fields, I'll join them as W x L into a single field. I may also join interior features with kitchen features, room features, and appliances in a single field separating each by bolding titles. This can then be displayed in a paragraph element on a site for the best benefits.

Since we rarely use vieleRETS as an actual data loader its difficult to suggest the best approach, but if I were required to use vieleRETS I'd make sure it was on a dedicated server and I'd download the data as a CSV file rather than an actual MySQL data import. I would then process the CSV befitting of what it actually features in terms of data. No two MLS's are ever alike. Because of this, each must be dealt with uniquely to use it most efficiently.