SQL Server - update underlying table Record from View AFTER INSERT

Question

This is my first time asking a question on here, I have gotten many answers to my questions just browsing though - so thanks folks for that, but this time I am stuck.

I am mostly new to SQL so bear with me and I am also working with a SQL Server 2008 R2 database not designed by me, I am just trying to get data out of it for other uses, I also use SQL Server Management Studio (SSMS).

SETUP: There are many tables but in this case I am working with one main specific Items table and 5 other "joined" tables and a view created from those tables. I then use the view in MS Access which I am more familiar with, I have added some new columns to the main table and one of them I want to store a computed MachineRate of the specific Item based on values of the main table (same record) and the other tables. I was able to do all of this fine on the view.

But my question is this: would it be possible to have this computed value used as the default value of the main table or fired in there with a trigger?

I have tried functions and triggers and am starting to wonder if this will not work, and as mentioned the view is based on the table I want to insert the value into.

For ex (this is just partial) : main table has the following columns...

RecID, PartRef, Material, Width, Length, Thickness, MachRate etc

And MachineRate table

RecID, Rate

And TableOfTech table

RecID, Material, Thickness1, Thickness2, AddToMachRate  etc...

Those 3 of 5 tables are needed for my computed value, the main table's MachRate value needs to be (Rate from MachineRate + AddToMachRate from TableOfTech) where TableOfTech.Material = MainTable.Material and MainTable.Thickness between TableOfTech.Thickness1 and Thickness2

Not sure how much the ex: really helps, but to give u an idea what I am working with, so does it really work to insert into a table column on ONLY the NEW record being inserted... a value based on a View from the SAME table ?

And I better explain why I want to do this....In this case it is necessary for the users to be able to change that value but for the most part defaults will be ok and we are using it like that at the moment

I hope this makes sense to you guys, I look forward to any help !

S. Brubacher

Answer 1

In a scenario where you have a computed column in a table it is best to keep all the column from where the value is being computed for this computed column in that same table.

You can have computed column whos value is being computed from columns from other tables but than you have to create INSTEAD OF INSERT triggers, AFTER UPDATE, AFTER DELETE triggers on all tables from where the value is being computed to sync the computed column for any changes in the source table, which can be a hell of task and Triggers can be silent killers at times.

So to avoid all this hassle just keep the columns from where the values are being computed and the computed column it self in One table.

Another even simpler option will be to create another view which gathers data at run time from these multiple underlying tables and compute them at runtime for you. Since you already have the data in you database from where this column is being computed its better to compute them at runtime only when you want to see the computed results.

If you have lots of data in your underlying tables and computing them values at run time takes a lot of time then consider INDEXED VIEWS.

My suggestion would be avoid as much as possible to have a situation where you have a computed column and source columns in multiple tables.