Как выглядит таблица БД, созданная фреймворком Rails?

Question

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

Когда Rails создает таблицу на основе вашей «модели», которую вы настроили, Rails создает таблицу, которая точно отражает эту модель, или она добавляет дополнительные поля в таблицу, чтобы помочь ей творить чудеса? Если да, какие еще поля он добавляет и почему? Возможно, вы могли бы вырезать и вставить структуру таблицы, или просто указать мне на раздел документации или учебника, который решает эту проблему.

Answer 1

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

ruby script/generate model User name:string

создает как файл user.rb для модели, так и миграцию:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :name

      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

Вы можете видеть, что по умолчанию сценарий генерации добавляет "временные метки" для (созданные и последние обновленные), и они управляются автоматически, если им разрешено оставаться в наличии.

Не видно, но важно, чтобы дополнительный столбец "id" создавался как единственный первичный ключ. Это не является обязательным условием - вы можете указать свой собственный первичный ключ в модели, что полезно, если вы работаете с устаревшей схемой. Предполагая, что вы сохраняете id в качестве ключа, тогда Rails будет использовать любые специфичные для СУБД функции, доступные для новых значений ключа.

Answer 2

В ActiveRecord модели создаются из таблиц базы данных, а не наоборот.

Возможно, вы также захотите взглянуть на миграцию, которая является способом описания и создания базы данных из кода Ruby. Однако миграция не связана с моделью; модель все еще создается во время выполнения на основе формы базы данных.

На сайте Rails есть скринкасты, связанные с ActiveRecord и миграциями: http://www.rubyonrails.org/screencasts

Answer 3

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

Одно скрытое поле является наиболее очевидным - поле "id" (целое число), которое Rails использует в качестве первичного ключа по умолчанию. Если не указано иное, каждая модель в Rails имеет поле «id», которое является уникальным, увеличенным целочисленным первичным ключом. Это поле «id» будет появляться автоматически в любой модели, созданной в Rails посредством миграции, если вы не скажете Rails не делать этого (указав другое поле в качестве первичного ключа). Если вы работаете с базами данных Rails из-за пределов самого Rails, вы должны быть осторожны с этим значением.

Поле «id» является ключевой частью магии Rails, потому что оно используется для определения ассоциаций Rails. Скажем, вы связываете две таблицы вместе - группу и личность. Модель Group будет иметь поле «id», а модель Person должна иметь как собственное поле «id», так и поле «group_id» для отношения. Значение в "group_id" будет ссылаться на уникальный идентификатор связанной группы. Если вы построили свои модели таким образом, чтобы следовать этим соглашениям Rails, вы можете воспользоваться преимуществами ассоциаций Rails, сказав, что модель Group "has_many: people" и что модель Person "own_to: group".

Миграции Rails также по умолчанию хотят добавить поля «create_at» и «updated_at» (так называемые «метки времени»), которые являются полями datetime. По умолчанию они используют «магию» в базе данных, а не в самом Rails, для автоматического обновления при создании или изменении записи. Я не думаю, что эти столбцы сбивают вас с толку, потому что о них следует заботиться на уровне базы данных, а не с помощью какой-либо специальной магии Rails.

Answer 4

Здесь - официальная документация для ActiveRecord. Согласен с Брэдом. Возможно, вы видели другой метод доступа или миграцию (которая изменяет таблицы и, следовательно, модель)