I think you've got the computed column backwards here.
That is, since the data is supposed to be in 1NF, the "divided by 10" value should be in a separate column in the table already. The computed / virtual column would be the combined value, which you currently have as an actual column.
Btw, the term "fields" is anachronistic for a relational dbms; you really should call them "columns".
I get the COBOL reference, but the rest of what you were saying isn't quite registering, and maybe it's because what I wrote and meant and what you read and thought you understood aren't quite the same thing. I'm trying to decide whether I can get better performance by placing a computed persisted column in the base table instead of in a view where the column wasn't even getting used. I won't actually end up with any schema changes in the view, ... only whether the column in the view references the computed persisted column that I'll create, or whether it just does that calculation as part of the view. The calculation is just ColumnName % 10, so it's not complex math. I'm struggling to understand where all the extra reads are coming from in the execution plan that aren't represented by statement completion lines in the .SQLPlan file that I generate using Profiler. The specific portion of the query I'm dealing with might use around 4500 in two pieces, but the whole shootin' match is up over 12,600. If I knew what else to account for, I could probably solve this more quickly, but I'm hitting a wall that's not making sense. I figured that pushing that computation into the base table would relieve the view of the job and the index updates that now include that computed persisted column would do their magic. I do get that part of the query to be better, but I'm at a loss as to how to impact that missing 2/3 of the reads that Profiler isn't directly accounting for, based on what I'm gathering anyway. Maybe I am not gathering all I need?
Sorry, I wasn't clear enough. My point is that if you are often using "ColumnName % 10", then that column should have originally been stored as 2 (or more perhaps) separate columns. This in keeping with the doctrine that each column is a single ("atomic") piece of data (aka first normal form / 1NF).
If any current code no doubt references the existing combined "ColumnName" column, you could create a computed column to construct the original combined column on the fly.
For example, existing definition:
ColumnName int
New definition along these lines:
ColumnNameA int --would be populated as ColumnName % 10
ColumnNameB int --would be populated as ColumnName / 10
ColumnName AS CAST(ColumnNameA + ColumnNameB AS int)
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.