Question

我正在尝试在rails应用程序中为location属性设计架构。

这应该是正确的设计

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

Answer 1

我认为这取决于您希望模型与表单集成的方式。我假设用户填充了位置模型中的数据，通过对Yahoo / Google或静态邮政编码查询表进行地理编码。

这里的任何方式是我的位置模型的迁移，我通过用户输入的邮政编码（zip）从静态查找表填充 - 这是通过AJAX调用填充主窗体，发送地理编码如果找不到邮政编码（桌子现在变得相当旧），请向Google发送请求

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

我使用了lon / lat的浮点数，尽管如果不是更好的话，使用字符串也可能是好的。

我使用了区域，国家和Hpu（健康保护单位 - nhs服务的区域部门）的地理细分的单独模型和表格。

这有很多原因，包括限制这些用户输入到下拉菜单，管理员仍然可以编辑（区域和国家/地区是稳定的单位，但Hpus正在进行名称更改）。

其他原因包括扩展地理模型以包含其他信息，例如shapefile信息（渲染单位的边界 - 此迁移中未显示，因为稍后使用PostGIS导入工具添加shapefile），并使用由这些额外的模型

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

Answer 2

除非有一个特殊的原因你不认为这是解决你的解决方案，从语法上来说它看起来对我来说。 rails的优点在于，如果它不对，您可以迁移数据模型以添加更多属性，因为您发现需要它们。

rails中的位置数据库架构表

2 个答案: