I have experienced a number of companies that are stripping direct access to the DB from the application layer, by implementing other layers. Most DBAs and Devs are familiar with 3 layer systems: Database, Business & Data Access, and Application. However, I am seeing a trend now towards 4, 5, and 6 layers, aided significantly by the .NET framework(s). Layers like: Database, Data access, Business Rules, Security/Firewalls, Interfaces, Presentation, and Application. In this latter paradigm, the Application never touches direct access to the data. Data is ported from system to system like a virtual multi-appendage mobile such as those that babies play with, often in XML, JSON, or proprietary format, and encrypted.

However, at the end of the day, we all quietly know that such things:

- bog down the major change process... significantly.

- only serve to help keep the honest, honest.

- and most importantly, still do not prevent the inside man, nor the end user from using data inapropriately.

At the end of the day, you still have to trust people that must use the data.

But still, multiple layer design also allows greater flexibility in cross-system (and GUI) portability, and also allows separate development teams to tackle upgrades to significant portions of the system without affecting the others, as long as the standing "contracts" of interchange are not broken. In essence allowing far greater possibilities. But it requires much more forethought in design.

Personally, I feel logging is still deep in the Network Admin's realm, and is really only useful at the database level to track precendence and change flow in OLTP systems, and keeping the honest in good working order.

That's my take...