Sarvesh
Sarvesh

Reputation: 1202

Location database schema table in rails

I am trying to design a schema for location attribute in my rails application.

Should this be the right design

class CreateLocations < ActiveRecord::Migration

  def self.up
    create_table :locations do |t|
      t.string  :zip        
      t.string  :city,       :null => false
      t.string  :state,      :null => false
      t.string  :country,    :null => false
      t.string  :latitude   
      t.string  :longitude
      t.timestamps
    end
  end  

end

Upvotes: 0

Views: 1499

Answers (2)

Pasted
Pasted

Reputation: 864

I suppose it depends how you want the model to integrate with your form. I'm assuming that the data in the Location model is populated by the user, via geocoding the zip against Yahoo / Google or from a static zipcode lookup table.

Any way here's the migration for my Location model, that I populate from a static lookup table via the user inputted postcode (zip) - this is populated in the main form by an AJAX call, which sends a geocode request off to Google if it can't find the postcode (the table is getting fairly old now)

class CreateLocations < ActiveRecord::Migration
  def self.up
    create_table :locations do |t|
      t.primary_key :id
      t.string :category
      t.string :placename
      t.string :address_1
      t.string :address_2
      t.string :address_3
      t.string :town
      t.string :region
      t.string :postcode
      t.float :lon
      t.float :lat

      t.integer :local_authority_id
      t.integer :hpu_id
      t.integer :region_id
      t.integer :country_id

      t.timestamps
    end
  end

  def self.down
    drop_table :locations
  end
end

I went with floating point numbers for the lon / lat although using a string is probably just as good if not better.

I used seperate models and tables for the geography subdivisions of Region, Country and Hpu (Health Protection Unit - a uk regional division for nhs services).

A number of reasons for this including restricting the user input for these to dropdown menus, which could still be edited by admins (Regions and Countries are stable units but the Hpus are undergoing name changes atm).

Other reasons included expanding the geography models to include additional information such as shapefile information (to render borders of the units - not shown in this migration because the shapefiles are added later using PostGIS import tools), and to use the associations provided by these additional models

class CreateRegions < ActiveRecord::Migration
  def self.up
    create_table :regions do |t|
      t.primary_key :id
      t.string :name

      t.timestamps
    end
  end

  def self.down
    drop_table :regions
  end
end

class CreateHpus < ActiveRecord::Migration
  def self.up
    create_table :hpus do |t|
      t.primary_key :id
      t.integer :region_id
      t.string :name

      t.timestamps
    end
  end

  def self.down
    drop_table :hpus
  end
end

Upvotes: 2

Jed Schneider
Jed Schneider

Reputation: 14671

unless there is a particular reason you don't think this is solving your solution, syntactically it looks right to me. the beauty of rails is that if it isnt right you can migrate the data model to add more attributes as you find you need them.

Upvotes: 0

Related Questions