What is a database view?

Making liberal use of views is a key aspect of good SQL database design. Views allow you to encapsulate the details of the structure of your tables, which might change as your application evolves, behind consistent interfaces.  

CREATE VIEW company_manager AS
SELECT id, name, email
FROM  companies
WHERE role='manager';

SELECT * FROM company_managers;

So what is a Materialized view?

1. It’s read-only (pseudo-table) so you can’t update it.
2. You need to refresh the table to get the latest data.
3. While refreshing, it would block other connections to access the existing data from the material view, so you need to make the refresh run concurrently

So why use Materialized views in Rails?

• Capture commonly used joins & filters.
• Push data intensive processing from Ruby to Database.
• Allow fast and live filtering of complex associations or calculation fields.

How do you use it in Rails?

bundle exec rails g migration create_all_time_sales_mat_view

class CreateAllTimesSalesMatView < ActiveRecord::Migration
  def up
    execute <<-SQL
      CREATE MATERIALIZED VIEW all_time_sales_mat_view AS
        SELECT sum(amount) as total_sale,
        DATE_TRUNC('day', invoice_adte) as date_of_sale
      FROM sales
      GROUP BY DATE_TRUNC('day', invoice_adte)
    SQL
  end
  def down
    execute("DROP MATERIALIZED VIEW IF EXISTS all_time_sales_view")
  end
end

class AllTimeSalesMatView < ActiveRecord::Base
  self.table_name = 'all_time_sales_mat_view'
  def readonly?
    true
  end
  def self.refresh
    ActiveRecord::Base.connection.execute('REFRESH MATERIALIZED VIEW CONCURRENTLY all_time_sales_mat_view')
  end
end

AllTimeSalesMatView.select(:date_of_sale)
AllTimeSalesMatView.sum(:total_sale)

Regular
       user     system      total        real
     (976.4ms)  0.020000   0.000000   0.020000 (  0.990258)
MatiView
     (2.3ms)    0.000000   0.010000   0.010000 (  0.012010)

Summarize

Good Points

• Faster to fetch data.
• Capture commonly used joins & filters.
• Push data intensive processing from Ruby to Database.
• Allow fast and live filtering of complex associations or calculation .fields.

Pain Points

• To alter table we need to write SQL
• We will be using more RAM and Storage
• Requires Postgres 9.3 for MatView
• Requires Postgres 9.4 to refresh concurrently
• Can’t have Live data
  • You can fix this by creating your own MatViewTable and updating it with the latest information

References

• https://www.postgresql.org/docs/9.3/static/rules-materializedviews.html
• http://en.wikipedia.org/wiki/Materialized_view
• http://dev.mysql.com/doc/refman/5.7/en/create-view.html
• https://blog.pivotal.io/labs/labs/database-views-performance-rails
• https://www.sitepoint.com/speed-up-with-materialized-views-on-postgresql-and-rails/

• Storing data in JSON and JSONB format
• Generating JSON results from the query itself

Getting Started

How to generate JSON

select row_to_json(users) from users where id = 1;

{"id":1,"email":"hsps@redpanthers.co","encrypted_password":"iwillbecrazytodisplaythat",
"reset_password_token":null,"reset_password_sent_at":null,
"remember_created_at":"2016-11-06T08:39:47.983222",
"sign_in_count":11,"current_sign_in_at":"2016-11-18T11:47:01.946542",
"last_sign_in_at":"2016-11-16T20:46:31.110257",
"current_sign_in_ip":"::1","last_sign_in_ip":"::1",
"created_at":"2016-11-06T08:38:46.193417",
"updated_at":"2016-11-18T11:47:01.956152",
"first_name":"Super","last_name":"Admin","role":3}

select row_to_json(results)
from (
  select id, email from users
) as results

{"id":1,"email":"hsps@redpanthers.co"}

select row_to_json(result)
from (
  select id, email,
    (
      select array_to_json(array_agg(row_to_json(user_projects)))
      from (
        select id, name
        from projects
        where user_id=users.id
        order by created_at asc
      ) user_projects
    ) as projects
  from users
  where id = 1
) result

{"id":1,"email":"hsps@redpanthers.co", "project":["id": 3, "name": "CSnipp"]}

array_to_json(array_agg(row_to_json(user_projects)))

json_agg(user_projects)

json_build_object('foo',1,'bar',2)

{"foo": 1, "bar": 2}

References

CREATE INDEX index_name
ON prices (user_id);

add_index :prices, :user_id

CREATE INDEX index_name
ON user_views (user_id, article_id);

add_index :user_views, [:user_id, :article_id]

scope :articles, where(:spam => 'true')

CREATE INDEX index_name
on articles (spam is true);

add_index :articles, :spam, name: "index_articles_on_spam", where: "(spam IS true)"

DROP INDEX index_name;

remove_index :books, :created_at

• Index Primary key
• Index Foreign key
• Index all columns you would be passing into where clause
• Index the keys used to Join tables
• Index the date column (if you are going to call it frequent, like rankings of a particular date)
• Index the type column in an STI or polymorphism.
• Add partial index to scopes
• Do not index tables with a lot of read, write
• Do not index tables you know that will remain small, all through out its life time
• Do not index columns where you will be manipulating lot of its values.

User.find(156).withdraw(1000)
User.find(157).deposit(1000)

User.transaction do
  User.find(156).withdraw(1000)
  User.find(157).deposit(1000)
end

@user.transaction do
end

User.transaction do
end

User.transaction do
  Order.create order_attributes
  Purchase.create purchase_attribute
end

User.transaction do
  User.create(username: 'Kotori')
  User.transaction do
    User.create(username: 'Nemu')
    raise ActiveRecord::Rollback
  end
end

class Projects < ActiveRecord::Base
  has_many :tasks
end
class Task < ActiveRecord::Base
  belongs_to :project
end

class Task < ActiveRecord::Base
  belongs_to :project, counter_cache: true
end

class AddTasksCounterCacheToProjects < ActiveRecord::Migration[5.0]
  def change
    add_column :projects, :tasks_count, :integer
  end
end

Project.find_each { |project| Project.reset_counters(project.id, :tasks) }

class Task < ActiveRecord::Base
  belongs_to :project, counter_cache: :not_the_default_column_name
end

<% Project.all.each do |project| %>
  <%= project.name %> (<%= project.tasks.size %>)
<% end %>

• :counter_cache is the optional attribute of a belongs_to relationship
• It requires the creation of an extra column (tasks_count) in the table which has the has_many relationship
• One can use another column name by passing the name along with :counter_cache option
• To use the counter_cache, one must use the “.size” method