Problem
In a team of SQL and front-end developers, changes to the database can affect team mates inadvertently. Is there a way to establish a base upon which the front-end can be built while allowing necessary database changes to be made? How can impacts to everyone be minimized? Check out this tip to learn more.
Solution
The use of views can insulate tables from certain kinds of changes, allowing for the front-end to be pinned to stable castles in the sky. This tip will define what I like to call the “Pigs in a Blanket” strategy of using views, how various development scenarios need handled and how to implement them programmatically.
New Development Scenarios
In this approach there is one view per table, typically listing each column and then any one-off columns or combination of columns frequently used. Because each view wraps tightly around its base table, it reminds me of “sausages surrounded by bread”, an hors d’oeuvre called “Pigs in a Blanket”. It’s also similar to insulating copper wires in rubber so there are no unexpected shocks when moving things around.
Consider the table:
Create Table used in subsequent examples |
---|
create table table1 ( |
Create a table
Each table gets a view that references all of its columns. For useful concatenations or aliases, these are added into the view too.
Rename a table
Using the SP_NAME system stored procedure to change the table name will require altering the view to match the table’s new name. Until the view is altered, using it will result in a binding error.
Binding Error that happens with SP_RENAME and DROP TABLE or DROP COLUMN |
---|
Msg 208, Level 16, State 1, Procedure v_table1, Line 3 |
Drop a table
Dropping a table without dropping any referencing views is permitted by SQL Server, but results in binding errors when the view is referenced.
Insert a new column
When adding a table column that needs to be shown in the output, an ALTER VIEW command is needed to append it. If the column is purely for behind-the-scenes work, the view can remain as is.
Rename a column
Perhaps the best use of this technique is that the view can alias a changed column to its original name. No front-end code needs to be changed, but the view will need to be altered.
Rename a column and modify the view example |
---|
exec sp_rename |
Drop a column
Removing the column from the view is safe way to preserve the data while lessening the result set of queries. If the column is best removed from the table, it will need removed from the view using ALTER VIEW.
Implementation Scripts
This section features some scripts for automating view creation and maintenance.
Wrap all existing tables in Blankets i.e. views
“Pigs in a Blanket” View Creation Script |
---|
/* |
When creating a new table, you can use the above script and filter on the new table.
One-Off Views
The wrapper script prints the create view statement it will run. This can be useful to quickly implement one-off views using the alter view command.
Alter View copied from print statements |
---|
/* This text was copied from the print statement |
Next Steps
- Discuss with your team the benefits of having wrapper views at the table level.
- Determine a naming convention for tables and views.
- Explore CREATE VIEW and ALTER VIEW in Books Online.
- Review INDEXED VIEWS to see if performance can be improved.
- There will subsequent tips exploring views on a combination of tables. Stay tuned.
- Check out all of the tips on views.