title: How to model data for a CouchDB geocoder
body: <p>I am working on a CouchDB based geocoding application using a large national dataset that is supplied relationally. There are some 250 million records split over 9 tables (The ER Diagram can be viewed at <a href="http://bit.ly/1dlgZBt" rel="nofollow">http://bit.ly/1dlgZBt</a>).  I am quite new to nosql document databases and CouchDB in particular and am considering how to model this.  I have currently loaded the data into a CouchDB database per table with a type field indicating which kind of record it is.  The _id attribute is set to be the primary key for table [A] and [C], for everything else it is auto-generated by Couch.  I plan on setting up Lucene with Couch for indexing and full text search.  The X and Y Point coordinates are all stored in table [A] but to find these I will need to search using data in [Table E], [Tables B, C &amp; D combined] and/or [Table I] with the option of filtering results based on data in [Table F].</p>
  
  <p>My original intention was to create a single CouchDB database which would combine all of these tables into a single structure with [Table A] as the root and all related tables nested under this.  I would then build my various search indexes on this and also setup a spatial index using GeoCouch for reverse geocoding.  However I have read articles that suggest view collation as an alternative approach.</p>
  
  <p>An important factor here I guess is reads vs writes.  The plan is that this data will never be updated, only read.  Data is released every quarter at which time the existing DB would be blown away and a new DB created.</p>
  
  <p>I would welcome any suggestions for how best to setup and organise this from any experienced Couch or related document database users.</p>
  
  <p>Many thanks in advance for any assistance.</p>