NYCPHP Meetup

[Rob Marscher]

MongoDB works great for storing documents like this altogether in one collection with varying schemas.  It makes it easy to query across all documents. But you could also accomplish something similar with an RDBMS with a table for each type and a search tool like ElasticSearch to index it all in one place. 

I'm not very familiar with Drupal and what it offers for MongoDB.  But the php mongo extension is solid. Doctrine has pretty good MongoDB integration and can be plugged into nearly any project. The Lithium php framework was built with MongoDB in mind first so its models work well with it.




On Oct 26, 2012, at 10:16 AM, "Greg Rundlett (freephile)" <greg at freephile.com> wrote:

> 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
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/show-participation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20121109/a94c02f7/attachment.html>