Таблица схемы базы данных местоположения в рельсах

Question

Я пытаюсь разработать схему для атрибута местоположения в моем приложении 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

Answer 1

Полагаю, это зависит от того, как вы хотите, чтобы модель интегрировалась с вашей формой. Я предполагаю, что данные в модели Location заполняются пользователем посредством геокодирования zip для Yahoo / Google или из таблицы поиска статического zipcode.

В любом случае, вот миграция для моей модели Location, которую я заполняю из статической таблицы поиска с помощью введенного пользователем почтового индекса (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 претерпевают изменения имени atm).

Другие причины включали расширение моделей географии для включения дополнительной информации, такой как информация о шейп-файле (для отображения границ единиц - не показано в этой миграции, поскольку шейп-файлы добавляются позже с помощью инструментов импорта 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

Answer 2

, если нет особой причины, по которой вы не думаете, что это решает ваше решение, синтаксически оно выглядит правильным для меня.прелесть рельсов в том, что, если это не правильно, вы можете перенести модель данных, чтобы добавить больше атрибутов по мере необходимости.