CODEWITHSUNDEEP
ruby-on-railspostgresqlruby-on-rails-5database-migrationrails-migrations
Thierry
Thierry

Reputation: 121

Rails - DB migration best practice

I have designed the following migration and wanted to check with the community is that is meeting the best practices of rails migration. I am running a postgres db.

I am trying to achieve a db structure where the various status attached to a user is stored in a separate table. for instance, its marital status.

let me know if that sounds like a reasonably efficient table design. and what I could improve.

class CreatePrequalifications < ActiveRecord::Migration[5.2]
 def change
   create_table :prequalifications do |t|
    t.string :attachment
    t.text :description
    t.integer :marital_status
    t.integer :professional_status
    t.integer :collateral_status
    t.integer :income_direct
    t.integer :income_support
    t.integer :income_scolarship
    t.integer :income_other
    t.boolean :blacklist

    t.references :user, foreign_key: true

    t.timestamps
  end
end

create_table :marital_status do |t|
  t.string :single
  t.string :married
  t.string :other
  t.string :divorced
  t.string :with_dependants
  t.references :user, foreign_key: true
  t.references :prequalifications, foreign_key: true
end

create_table :professional_status do |t|
  t.string :self_employed
  t.string :employed
  t.string :student
  t.string :other
  t.text :description
  t.datetime :contract_created_at
  t.datetime :contract_terminated_at

  t.references :user, foreign_key: true
  t.references :prequalifications, foreign_key: true
end

create_table :collateral_status do |t|
  t.string :collateral_name

  t.string :collateral_income
  t.boolean :visale_collateral
  t.boolean :student_collateral
  t.boolean :bank_collateral

  t.references :user, foreign_key: true
  t.references :prequalifications, foreign_key: true
end

end

Upvotes: 1

Views: 1006

Answers (2)

sammms
sammms

Reputation: 677

In this case, best practices would dictate:

  1. Break each create_table into its own migration.
  2. Your table names should be pluralized, e.g. marital_statuses.
  3. Time stamps are a good idea.
  4. Consider adding indexes to fields that will be queried regularly, e.g. model names, user emails, or foreign keys.

Check out the rails guide on migrations for information about best practice: https://edgeguides.rubyonrails.org/active_record_migrations.html

Upvotes: 1

MrShemek
MrShemek

Reputation: 2483

Let's start with:

  1. Is it a single migration? If so, I would start with splitting it into several migrations (one for each table).

  2. Add timestamps for each table (t.timestamps null: false). You will thank me later ;)

  3. For statuses tables (martial_status, professional_status) create simpler tables with just name and references (no need to create column for each value). Also, you probably do not need the table for marital status, because you can use classy_enum instead.

  4. In prequalifications you have integer columns for relations (maritial_status, professional_status). Don't do that, use references.

  5. For boolean columns, define default values.

Upvotes: 1

Related Questions