In SSMS and MySQLWorkbench a view is the SQL that generates a result set. In Access those are called queries. Is a view the same as a query?
A view is essentially a stored/predefined query. Depending on the database in question, views may additionally have indexes defined against them, have referential integrity defined on them, and/or be materialized (pre-queried and persisted to disk).
Related
When you create a view, the column structure of the view is created and stored, and thus you can see it in object explorer:
When you alter the source data tables, sometimes things go wacky, because the view may have been built with "Select *" yet the schema created for you has the old information without the additional columns.
Does SQL Server have an easy way to rebuild the view schemas?
Do not use SELECT * in views. I say this as someone who has spent much too much time (in the past) debugging views that had this "feature".
When you do create a view in a production system, create it with SCHEMABINDING:
SCHEMABINDING
Binds the view to the schema of the underlying table or tables. When SCHEMABINDING is specified, the base table or tables cannot be modified in a way that would affect the view definition. The view definition itself must first be modified or dropped to remove dependencies on the table that is to be modified.
Although this adds an extra step when trying to modify tables, the increased resilience of the system is worth it.
I need to create an index on a view in mariaDB. Is this possible?
Note that, I can't create an index on tables since admininstrator permissions are not given to access tables.
No, you cannot create indexes on a View in MariaDB.
Indeed, Views are not real relations, but simply aliases on relations (tables).
You could have created indexes on a Materialized View but MariaDB does not implement (in a native way) Materialized Views as of today.
Sometimes I found some code that makes triggers to allow user to delete from View ?
But why we need to delete from View ,, because simply we can Go to Table > and execute delete like this simple code :
delete from table where x=y ;
My question why we use deletion on views by using TRIGGERS ؟
in another words what is the advantages of using delete over a View !
The reason we use view are mainly to hide the complexity of data
sources , Hide away the actual tables (For security reasons), saving
us writing the same code over and over again.
Now if you havent let your users access the tables directly and they
only work through View in this case they will be executing Deletes
against views.
Triggers are only used when your View has more than One underlying
table. You cannot do update, insert or delete operations on view if it
effects multiple underlying tables. Therefore we make use of Instead
of Delete/Update/Insert Triggers to do these operations against
views.
When you have multiple Underlying tables if you Update,Delete or
Insert effects only One underlying table it does allow you to execute
the statement but it is not guaranteed that it will be done correctly.
therefore if you have a situation where your view is based on
multiple underlying tables you should always do update/delete/inserts
1) Directly to underlying tables. 2) Use Instead of triggers.
Also Read here for more details on why you shouldnt do update/delete/insert operations on views with multiple underlying tables.
I create a indexed view View1 on Table1 and Table2 and have instead of trigger and after trigger on Table1 that use of View1. It seem that data of View1 not change when I use this view on instead of trigger and after trigger. But I want to use View1 with new data when use this view on after trigger. How can I do it. It should be noted that I use with Noexpand hint when use indexed view (when don't use with noexpand hint in SQL Server 2008 R2 act this indexed view such as no indexed view).
The indexed view is updated after all triggers on the base tables are executed. You can see that in the query plan. There will be only one clustered index update on the view.
However, you can create INSTEAD OF triggers on the view and then make all your operations on the indexed view. However,there are some restrictions when updating/inserting/deleting through an updateable view. You can read about them here.
Note that views allow only INSTEAD OF triggers, not AFTER too.
The most important thing to know about updating indexed views is that any modifications, including UPDATE, INSERT, and DELETE statements, must reference columns from only one base table.
If a "WITH NOLOCK" query hint is used on a View in SQL Server, does it propagate that hint to the view definition itself, even if NOLOCK is NOT used for the raw tables in the View definition? The reason to need this is that sometimes the support staff wants to do huge time-consuming queries but would rather not force this lock on all queries using the view within the application itself.
Yes, NOLOCK will propagate to the tables used by the view definition (at least in SQL Server 2005).
See Table Hints in MSDN:
In SQL Server 2005, all lock hints are propagated to all the tables and views that are referenced in a view. Also, SQL Server performs the corresponding lock consistency checks.
However,
If a table contains computed columns and the computed columns are computed by expressions or functions accessing columns in other tables, the table hints are not used on those tables. This means the table hints are not propagated. For example, a NOLOCK table hint is specified on a table in the query. This table has computed columns that are computed by a combination of expressions and functions that access columns in another table. The tables referenced by the expressions and functions do not use the NOLOCK table hint when accessed.
If you're using indexed views you might want to read a bit more as there are some special cases there too.
Also see View Resolution for more info.
Just to supplement Rory's excellent answer.
He writes "Yes, NOLOCK will propagate to the tables used by the view definition (at least in SQL Server 2005)."
In fact this will work in SQL 2000 as well.
From BOL:
Because select_statement uses the SELECT statement, it is valid to use and hints as specified in the FROM clause. For more information, see FROM and SELECT.