NYCPHP Meetup

NYPHP.org

[nycphp-talk] form and database solutions, particularly with large records without a common schema

Greg Rundlett (freephile) greg at freephile.com
Fri Oct 26 10:16:15 EDT 2012


I've got to *quickly* create an application that will have a large form
front-end.  The form doesn't have to be multi-page, meaning it could be a
monololithic page, but the page does have to be dynamic in the sense that
entire sections will depend on options within the form.  Plus, some options
will ideally be treated as 'accordion' type display so that when you focus
on element "foo" to enter details for "foo", a number of checkboxes will be
revealed, and then that section will collapse again when focus is lost.
 Each record is an MLS listing (Residential Real Estate) plus property
photos, plus associated documents.

I'm just wondering if anyone has suggestions on how they've done this type
of thing with a particular framework or set of tools.  Of course the bosses
just want a simple, quick solution that collects this info into a database.


I'm hacking away in Drupal, using the dRealty module as a way to get 80%
there from the start.  http://drupal.org/project/drealty

I was thinking of using a Mongo storage backend because there are 300+
fields for a given property class (i.e. single family, condo, multi-family,
land, commercial), and the "schema" changes for every class and every MLS
system.  Ultimately there would be ~15 different schemas (3 MLS systems x 5
property classes) with more to come.  Since mapping this data into a common
taxonomy has historically been a monumental task [1], I am thinking it
would be better to not map it for storage, but rather to create the field
mappings in code.  If you've done something like this in Mongo (which is
new to me), I'd like to look at it or hear more.

If I were to use an RDBMS as the backend, I'd be tempted to use the object
model inheritance capability of PostgreSQL so that I could more easily
create a limited subset of data fields that are always present in every MLS
system and class (e.g. price, id, address, type, status) and independent
tables would store each property class.  This way views could represent
aggregate data across property classes and MLSes.  If you've done something
similar in PostgreSQL, I'd like to know more about your implementation.

Have you done this in Cake, Symfony, NodeJs, something else?

Thanks,

Greg Rundlett

[1] There is a RESO Data Dictionary http://rets.org/cms/node/180 which
defines 504 fields of data for a Real Estate property listing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20121026/a5685a9c/attachment.html>


More information about the talk mailing list