• I do everything myself, application side and database side. I do not allow (myself) access to tables directly. Views, read-only, even if it's just a "SELECT everything FROM table" statement. Updates and deletes are done through stored procedures only.

    Allows me to change a table and all I have to do is change the view to accomodate the change - often zero change necessary to the application. And if there is a problem with changes to the data, it all funnels through procedures, which I can modify to include traces, metrics, error checking, whatever is necessary, ALL with NO impact on the application.

    Didn't think of this myself, saw the advice somewhere when I started learning SQL Server, maybe even on this site. Thought about it, decided it was a good idea and have done it that way exclusively.

    I'll always do it that way, unless something even better comes along. I can think of no reason to ever do it any other way. Snivels about performance don't fly. This system, used properly, will perform just as well as allowing direct access to tables, often much better. If the performance isn't adequate, look at the design. Unlocking access to tables for performance reasons is cop-out, and dangerous to boot.