Database Reference
In-Depth Information
Now, insert a row in the
view_select
view using the following statement:
warehouse_db=# INSERT INTO view_select VALUES
(4, 'Gary', 'Houston');
Use the
SELECT
command to check whether the changes are logged in the view as
follows:
warehouse_db=# SELECT * FROM tab_view;
emp_id | emp_name | emp_city
--------+----------+----------
1 | Adam | Chicago
2 | John | Miami
3 | Smith | Dallas
4 | Gary | Houston
(4 rows)
You have successfully created an updateable view using rules.
Triggers are ired for each affected row and procedural whereas rules modify
the query tree, and for a database, it's a pure SQL statement. Thus, all rows will
be affected at once. This feature makes them faster as compared to triggers. This
difference would not be evident if you are affecting merely few rows. However, as
the complexity grows, maintaining rules will become dificult whereas in triggers,
complexity is quite low. So, the choice between rules and triggers is certainly related
to the usage and level of complexities involved.
Understanding views
Though the name view itself hints at an object that lets you view, and in databases,
we mean a database object that helps you view the table data. It's not a real table
itself but can serve as a
read-only
view of the table you have associated with. Unlike
tables, views do not exist on their own. They are helpful in the following ways:
• They are created on the table as a query to select all or selective columns,
thus giving restricted or privileged access. Accessing actual data is not at
all required.
• They are capable of joining multiple tables to represent data as a single table.
• They are not real, thus they only use storage space for deinition and not for
the actual data they collect.
• They always bring the updated data when accessed.
