A database view defines table joins for reporting purposes.
For example, a database view can join the Incident table to the Metric Definition and Metric
Instance tables. This view can be used to report on incident metrics and may include fields from
any of these three tables.
A number of useful database views are installed with the Database View plugin and the Database
Views for Service Management plugin. These database views cover most metric reporting needs and
greatly reduce the need to define new ones.
Note: In general, as the number of tables that are included in the view and the number of records
that those tables contain increases, the accumulated impact on performance grows. In addition,
to optimize the performance of the database view ensure that the ‘where’ clauses that are
defined in the database view are based on indexed fields.
Database views cannot be created on tables that participate in table rotation.
It is not possible to edit data within a database view.
ACLs and database views
You do not need to create ACLs on fields in the view. The system honors contextual ACLs (ACLs
with a condition or script) that already exist on the underlying table. Non-contextual ACLs
(ACLs with only role checks) are still honored just as with previous releases.
You can revert this functionality to legacy behavior and require explicit read ACLs to be
added to the database views. Set the glide.security.expander.view.legacy
property to true. For upgraded instances, add this property to the
system, and set it to true for the same legacy behavior in pre-Istanbul
releases, or set to false to use the new behavior.
You can still create additional ACLs on the database views. These ACLs are evaluated last and
are always honored.
Database view reserved words
Using the terms may cause unintended or undesirable performance. For more information, see the
MySQL reserved words document.