We use views to represent data from different tables in one row and available faster for read operation.
What if the views is just a copy of a table ?
what will be faster read operation on that table or read operation on the view of that table?
Thanks
Views are not (in general) "copies" of tables. Views are definitions of queries that are substituted into other queries.
There is an exception to this rule: materialized views which some databases (such as Oracle) support but not all.
For fastest access, you should in general go to the tables directly and set up the tables to optimize your query -- this usually involves creating indexes and sometimes vertical partitions. Views are a great convenience and useful. Their performance often equals that of direct access to queries. But, with the exception of materialized views, they do not offer performance advantages.
Related
I understand from this question that SQL language does support calculated columns in views.
I have a requirement where I have a table with multiple columns, and I need to calculate a sorting column in order to simplify my queries. I am thinking of creating a view for my origin table with those sorting columns calculated. But I am afraid that could be a performance nightmare as my table grows bigger.
Does any one have an idea on how that would affect performance?
Is it possible to create index on a calculated column in a view ?
UPDATE 1:
I am planning on using postgresql, but I am open to other opensource alternatives like MySQL
UPDATE 2:
as N.B. suggested:
I'm not a Postgres user, but the docs here are showing how to create that view and how to index it. If you're using Postgres and are familiar with it - stick with it. All databases work nearly the same, but if you're more proficient with one - no reason to change it. As for how it affects the performance - be it a view or a query that you construct dynamically - it's the same thing. View is just a huge help when querying, and if you can index it it means some memory will be spent on index. You have to measure
I am thinking now that materialized views are the way to go for my functional requirements, I can setup a trigger to refresh the Materialized View on each and every update on my table once I confirm this point:
How does REFRESH MATERIALIZED VIEW work ? does it drop the data and recreate the view from scratch ? or does it do some kind of differential refresh ?
Disclaimer: I have used both MySQL and PostgreSQL Database on a remote server for about 8 months only, and I have a preference for PostgreSQL for your use case.
TL;DR
According to the documentation, REFRESH MATERIALIZED VIEW
command will drop all data and re-populate the entire query's data if you add the WITH DATA clause.
You can create indexes for materialized view. The index could be on the calculated fields that are stored in the columns.
You cannot index a view (non-materialized)
You can create different types of materialized views depending on your needs (see URL link below).
Long Explanation
A) Materialized Views types and performance
I have a requirement where I have a table with multiple columns, and I need to calculate a sorting column in order to simplify my queries. I am thinking of creating a view for my origin table with those sorting columns calculated. But I am afraid that could be a performance nightmare as my table grows bigger.
If the calculations are very expensive, consider consuming more memory to store the results in materialized views or tables.
A materialized view is like a table that stores the result of a query. In the case of PostgreSQL materialized view, indexes can be created on it to speed up queries and it can be vacuumed to update the meta-data.
The materialized view that PostgreSQL provides is a naive one because you must manually refresh the data with REFRESH MATERIALIZED VIEW command. According to the documentation, this will drop all data and re-populate the data if you add the WITH DATA clause.
After that, you need to consider the performance needed for insert, update, delete operations:
If you have no real-time requirements (i.e. a full table
re-population is acceptable) then this option is fine.
Else, you might want to see this website post for different setup of materialized views, some of which allows for lazy refresh of data (trigger refresh data by rows)
https://hashrocket.com/blog/posts/materialized-view-strategies-using-postgresql
The second point also applies to MySQL as well (and is actually the traditional and customized way of building materialized views). To my knowledge, MySQL does not support materialized views out-of-the-box (require plugins). The convenience provided in (1) is one of the reasons why I chose PostgreSQL.
Is it possible to create index on a calculated column in a view ?
It is possible to index the columns of a materialized view, just as you do for a table.
B) Window functions in PostgreSQL
The second reason for choosing PostgreSQL over MySQL is because the former provides extended-SQL functions (or I would like to call them OLAP functions) that help with complex queries like ranking of rows and so on.
I shall leave it to you to explore this option (just do a Google Search on "PostgreSQL Window Functions").
According to my latest knowledge, MySQL has no built in support for this (maybe rely on plugins or own coding?).
I've found MySql views to be one of the most common performance pitfalls, mostly for reasons mentioned in this answer.
The biggest drawback is in how MySQL processes a view, whether it's
stored or inline. MySQL will always run the view query and materialize
the results from that query as a temporary MyISAM
One big drawback of a view is that predicates from the outer query
NEVER get pushed down into the view
What are the performance differences (if any) for views in Aurora compared to MySql?
Do Aurora views necessarily materialize without considering predicates on the outer query?
Can we create Materialized view in mysql or sql which will automatically reloaded with the data from the underlying bases table without hitting the base table.
Elobration:
I have created viewMasterTable view which is join of 3 tables,
TableA,TableB,Table = viewMasterTable
Now i want this view to be reloaded with the data if any changes i.e upadate,insert or delete is made on the base table without hitting the base table.
**Will this view concept will help in performance increase**
You can create materialized views in SQL-Server Enterprise Edition. In MySQL you cannot create materialized views. Thus this only applicable to SQL-Server and a very specific edition.
Now you don't get something for nothing. If you materialize a view it means that the source columns used in the base table(s) have to remain in synchronization with the data in the base tables. Thus any updates/inserts/deletes on the base table will be impacted as the server now has to write to the base tables and update the view. So you will have an extra operation to complete for every write this will incur a performance penalty on the server itself. Depending on size of tables, views and frequency of updates this might or might not be a small penalty.
You can index materialized views and this is where the power really shines. Say you have a very complex view that can be filtered by various columns a materialize view will allow you to index the fields in the view allowing a user to filter much faster. However the downside is that for every index that you create on a materialized view it will incur more write penalties as the server needs to update indexes when updating the view.
So while it can be a really good way to increase performance for reads on a complex query you will see a performance penalty on writes. How bad will this penalty be? Well that depends on how you have arranged your Disk IO pathways i.e. for example placing your indexes, views and tables on separate physical spindles will help alleviate some of the write overhead.
I'm new to SQL 2008. As I look at the Common Table Expressions (WITH keyword), how is the performance compared to using a temp table. Besides syntax / readability, are there any other benefits to using CTEs?
I have not done exesive measuring, but temp tables are stored in the temp database. CTEs are not, so in most simple cases they should be faster. But in some cases you might create big temp tables and would create indexes on them to speed up further calculations. That's not possible with CTEs. In such cases they are probably slower. But as usually: I don't think that there is a general answer. It always depends on your query and the resulting query plan.
Is it all right to have many tables inside a database or should I create another database? If so, what is the limit on how many tables I should have in a database?
Will having many tables in a database affect the speed of the database?
It depends on the size of the tables, as well as the amount of reading / writing you're going to be doing, which again depends on the hardware you're running, and the types of tables you're using.
Performance is usually reduced by lots of I/O because that tends to be the slowest part of a system.
As for your other question about limits, may I suggest having a look through the MySQL documentation.
Really, the key is to employ a good relational database design, and understand and optimize your queries appropriately. Having many tables in a database won't affect the speed. Building those tables with bad design, and accessing data with inefficient queries absolutely will.
One limitation in MySQL to be aware of is that a single table cannot be over 4GB in size using the MyISAM database engine. InnoDB does not have that limitation that I'm aware of.
I don't believe it makes much difference in performance if your multitude of tables is in one or several databases. (If you need to reference multiple tables in one query then they will be a bit easier to write the queries if the tables are not all in different databases, though that's not a performance matter.)
Implied in your question, however, is another question: What are the performance effects of structuring my data into specifically these tables as opposed to some other schema that uses a different number and structure of tables. That's a question many DB designers face. There often are significant performance differences. There are few general rules with any validity. One that's included in the MySQL manual is: Use the schema that minimizes total DB size. It's not guaranteed to be the most performant schema but it's often one worth considering.