更新视图与触发器

Question

I am studying for a final exam, and came across this question:

Explain why updating views is not recommended. Explain how triggers can be used to support view updates.

I have looked on the web, and read a couple chapters from the book to no avail.

I have seen points made to where views can help make life easier, but none arguing against them.

Is this a possible answer?

One could use the INSTEAD OF clause in a TRIGGER statement in order to circumvent the updating of a table. This would allow for the update of multiple tables that could be represented by one view.

So, my questions are:

1.) Why are updating views not recommended?

2.) How can triggers be used as a solution to the problem?

Answer 1

There are many restrictions on inherently updatable views .

This can be both frustrating and fragile, as future evolution of your view and/or schema might made the view no longer inherently updatable -- so breaking code that relies on this feature.

At the expense of few lines of code, using an INSTEAD OF trigger will have the benefit of both reducing the above concern and to allow you to update a non-inherently updatable views. You can use an INSTEAD OF trigger on an inherently updatable view to override the default behavior.

Answer 2

When researching views, be sure to rely on relatively recent data as views have changed over the years so older opinions on the subject may not be valid. When views were first made updateable, the restrictions were many and control of the operation was little or nonexistent.

With the ability to write triggers on views in many systems, the restrictions have fallen away and control is precise. We can now determine exactly what happens to all the data during DML to views. It is now to the point where I disallow direct access to tables by applications. All DML originating from apps have to go thru views (or stored procedures, but they are not as good as view triggers). The benefits are so vast I don't see why it hasn't become a universal standard.

Indeed, many people's "views" on views (unfortunately, many people who are in charge of databases) seem to be stuck in the 1990's. Some don't want any views at all in their database. Some allow views but don't allow using them for DML. Many insist on giving them special names ("VW_name", "name_View" or similar) which breaks an extremely useful wall of abstraction for your data. Data abstraction is not a strong point of databases, so grab it where you can.