[Rets-dev] Re: ENCODED vs.DECODED

[Robert Davis]

As a frequent Requestor (I access RETS systems that use MarketLinx,
Interealty, FNIS, Rapattoni, and a couple of custom ones), I exclusively
pull encoded values unless the MLS system doesn't permit it.

One of the reasons for this is that MLS's, for the most part, do not
create good decode values and the decoded values are just as readable to
the general public as the encoded values.

For example, the encoded/decoded value pair for a Condo feature may be A
= ELVTR. Well, a Real Estate professional may know instantly that it
means that the building has an elevator, but the general public does
not. Plus abbreviations like this simply look bad on websites. Would you
rather use a website that says that a Condo has "ELVTR, OUTPL, FPMB,
2GAR" or a website that says that a Condo has "Elevator, Outdoor Pool,
Fireplace in Master Bedroom, Two Car Garage"?

So, smart developers will further decode the decoded values.

The next reason is database normalizations and storage space. Let's
consider a feature field that allows multiple choices and has an average
of 5 encoded values that take up an average of 14 spaces. The same field
if decoded may take up an average 44 spaces. Multiply that by 40,000
listings and the difference is 560,000 characters vs. 1,760,000
characters.

Now, I currently have almost 4.5 Million listings in my database from
approximately 40 different MLS's. So if I had this one hypothetical
field in my database for every MLS, I'm looking at a difference of
63,000,000 characters vs. 198,000,000 characters.

Big difference!!! And to top that off, I literally get some multiple
code decoded fields that are over 1200 characters long!!


Robert Davis


-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of David A. Riggs
Sent: Thursday, May 18, 2006 10:57 AM
To: rets-dev at rets.org
Subject: Re: [Rets-dev] Re: ENCODED vs.DECODED

As an intermediate client (oops... Requestor), we need to provide
encoded values to data recipients who are essentially synchronizing
databases, and decoded values to data recipients with "shallow" caches
or near-realtime use.

We can derive decoded values from encoded values, but not vice versa.
It'd be quite a shame were this removed - if I had to choose only one
format, it'd be encoded.

- David A. Riggs


On Thu, 2006-05-18 at 10:42 -0700, Paul Stusiak wrote:
> Adding is good.
> 
> It would be nice to have some Requestor vendors participate here, 
> since the DECODED format came from that community. Perhaps there are 
> other voices that need to be heard?
> 



--
David A. Riggs
Threewide Corp. - It's all about the data!
riggs at threewide.com
304-296-9595 x104
_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev