title: Is this a good DB schema for locations
body: <p>I'm working on an application that is location specific -- think of it as a store locator where store owners enter their address information and other users can only see nearby stores within a certain range. However, it's a little different in the sense that an exact location is not required, only the city/state is required (weird, I know). I have thought about the schema for storing locations, and have decided on this one.</p>
  
  <p><strong>Locations</strong></p>
  
  <pre><code>id                      -- int
  formatted_address       -- varchar(200)
  is_point_of_interest    -- bool
  name                    -- varchar(100) -- NULL
  street_number           -- varchar(10)  -- NULL
  street                  -- varchar(40)  -- NULL
  city                    -- varchar(40)
  state                   -- varchar(40)
  state_code              -- varchar(3)
  postal_code             -- varchar(10)
  country                 -- varchar(40)
  country_code            -- varchar(3)
  latitude                -- float(10,6)
  longitude               -- float(10,6)
  last_updated_at         -- timestamp
  </code></pre>
  
  <p>Here are some notes about the application:</p>
  
  <ul>
  <li>I want to keep the door open for international locations</li>
  <li>I plan to use a geocoding service to search for and validate the locations specified by the store owner</li>
  <li>I truly only need the lat/lon, but the other data is necessary for displaying store information</li>
  <li>The formatted_address field will contain the fully formatted address -- e.g., Giants Stadium, 50 NJ-120, East Rutherford, NJ 07073, USA -- to allow for easier searching of stored locations</li>
  <li>There will possibly be a lot of duplicate fields, because each row may have a different level of granularity -- for instance, <code>123 Main Street, City, State 12345</code> is different from <code>Main Street, City, State 12345</code> because one has a specified street number and the other doesn't</li>
  </ul>
  
  <p>I understand that the schema is not very normalized, but I also do not see the need to normalize it any more because locations are very complex, which is why I'm relying on a stable geocode service (google). Also, I plan to allow freeform text input/search, so theres no need for any dropdown lists. </p>
  
  <p>Does anybody see anything wrong or have any improvements, taking into consideration what I've mentioned? I can see this table growing rather large.</p>