Rails 中的位置数据库模式表

发布于 2024-10-05 22:59:11 字数 447 浏览 4 评论 0原文

我正在尝试在 Rails 应用程序中设计位置属性的架构。

这应该是正确的设计吗

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

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

兰花执着 2024-10-12 22:59:11

我想这取决于您希望模型如何与您的表单集成。
我假设位置模型中的数据是由用户通过针对 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

我使用浮点数表示经度/纬度,尽管使用字符串可能同样好,甚至更好。

我对地区、国家和 Hpu(健康保护部门 - 英国国民医疗服务体系服务的一个区域部门)的地理细分使用了单独的模型和表格。

造成这种情况的原因有很多,包括将用户输入限制为下拉菜单,这些菜单仍然可以由管理员编辑(地区和国家是稳定的单位,但 Hpus 正在进行名称更改)。

其他原因包括扩展地理模型以包含附加信息,例如 shapefile 信息(用于渲染单位的边界 - 在此迁移中未显示,因为 shapefile 是稍后使用 PostGIS 导入工具添加的),以及使用这些附加模型提供的关联

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

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
原谅我要高飞 2024-10-12 22:59:11

除非有特殊原因您认为这不能解决您的解决方案,否则从语法上来说,它对我来说看起来是正确的。 Rails 的优点在于,如果不正确,您可以迁移数据模型以在需要时添加更多属性。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文