Original: https: //blog.csdn.net/chuangxin/article/details/84574557
"SQLite Definitive Guide" in the author's view is so defined: a view that is a virtual table, also called derived tables, because their contents are derived from the results of other tables. Although the view looks and feels the same as the basic form, but they are not the base table. The basic contents of the table are persistent, and the content view are dynamically generated during use.
1, views, create, modify SQL syntax
MySql reference manual 5.7 14.1.21 CREATE VIEW Syntax
CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | INVOKER }] VIEW view_name [(column_list)] AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION]
Sqlyog, Navicat other client visualization tools can define, modify the view, and therefore omitted.
2, views, use and usage scenarios
purposes:
view at all in my opinion a purpose: to simplify sql query, improving development efficiency. If there is another use that is compatible with the old table structure.
Usage scenarios:
1) the need computed columns, database design paradigm requires that we reduce redundant field, so now a lot of data tables are not calculated column fields, such as purchase orders: price, quantity, tax rate, tax amount, probably not without tax amount, tax, and these will be used in the field there is a lot of reports, so we can create a view that contains a computed column field to solve this problem.
2) different tables field aggregation, information reorganization, such as: when the dealer usually clerk, the clerk usually has a superior-subordinate relationship (account manager, regional manager, regional manager, etc.), so we need to see to see the dealer salesman who salesman straight pipe that? Regional Manager of the corresponding clerk, who is the regional manager (possibly NULL)? So we can co-dealer table, table sales information, sales reporting relationships defined in a table view dealer.
3) security needs, mainly early legacy systems integration needs, such as: the need xx system data, not any interfaces, how to do? Direct operation of the database, this time involving data security, the rational use of view, it can reduce the number of authorized work and ensure data security. The current system, almost all newly constructed exposed api interface, so pay more attention to data security in authentication and data granularity interface aspects.
4) compatible with the old data tables, have encountered such a problem.
The company independently developed inventory management system, initially for personal use, and later also with partner companies, so I plan to Saas technology, had made one of the biggest changes is that almost all the tables using the addition of a unit (co_id) field. Another sad reminder that outsourcing procurement system uses a single table, the system has stopped maintenance, and continued in use. So he created a company owned co_id = view, named for the original purchase order table, and the original purchase order table into the new table name. As a result of outsourcing the system can continue to use, and the data is also no problem.
3, view performance and precautions
have to sql simplify and improve development efficiency, but also improve performance, which is a bit of fish and can not have both, not to mention a little weak MySql query chicken, how to do? My suggestion is not that bad poor performance on the good view can be obtained using the expected data. How not to make it worse performance?
MySQL two algorithms in processing view, referred MERGE and TEMPTABLE.
You can specify which algorithm to use when performing "CREATE VIEW" statement. Do not show specific words, Mysql Merge algorithm is used by default.
MERGE, will merge into the main view sql query sql, the re-constitute a new sql queries. Online there is a very good heroes say "somewhat similar to the C language macro expansion,"
the TempTable, see text intended to know, it is to make temporary table to view a single process.
The so-called MERGE refers to the process operation related to a view, a view of the operation will be expanded in accordance with the definition of the view, somewhat similar to the C language macro expansion.
In general, when nothing can use MERGE algorithm processing view MySQL performance problems, because you can use the index, mysql query optimization algorithm, but not MERGE algorithm can be used at any time. In fact, as long as the definition of the view a little bit complicated, MySQL is no way to use the MERGE algorithm. Accurate to say, as long as the view definition uses the following building blocks can not use SQL MERGE algorithm:
Aggregate Functions
DISTINCT
the GROUP BY
the HAVING
set operations (UNION, UNION ALL)
subqueries
For complex view definition, MySQL used in a method of maintaining the status quo, i.e., to perform the view definition, the temporary table using the result saved, so that subsequent manipulation of view of operation translates into a temporary table. Can not say that from the perspective of software design from a single view, such a method is very elegant, but from a performance point of view, this approach is also very poor.
Caution:
1) try to make use of merge algorithms view, the view definition to avoid DISTINCT, GROUP BY, etc. A collection of related operations;
2) If the view is complex using TEMPTABLE, then think of ways to reduce the number of records TEMPTABLE.