joejuska (7/30/2016)
You said "Quick questions, on what do you base that assumption?" I can't directly answer your question because YOUR QUESTION is wrong. IT'S NOT AN ASSUMPTION BUT AN OBSERVATION. The observation over many years of doing it both ways and any difference (I assume there must be some overhead that would make it theoretically slower) are so small as to be undetectable with tens of thousands of inserts per day. Both methods yield an instantaneous result as perceived by the human users brain.
Of course. That's because you are testing the wrong thing. The performance hit of a computed column does not occur on insert, it occurs when the data is queried.
When this computed column is never or hardly ever queried, then a computed column will not hurt you. But when it's queried very often, you will take a hit. And maybe even that hit will not be perceived by the human brain - but it will increase the total server load.
If you really want to benchmark this, then create a test table with three columns: data, computed column (using hashbytes), and persisted column (storing that same hashbytes result). Fill it with at least ten million or so rows. Now run two queries: one for MAX(computed column) and the other one for MAX(persisted column). Run each twice and time only the second (to make sure both queries are timed from cache). Measure the duraction for each, but also keep an eye on the CPU usage wihile each is running.
You said "Is there a problem calculating the hash on insert?" Yes. There are numerous (unknown number and unknown type) ways users can input the data so we have no control over what is insert so the only way to get a hash is with a calculated field or running a process after an insert.
In that case I would suggest using a persisted computed column. Defined the same way as a normal computed column with the additional keyword PERSISTED. SQL Server will compute the value when the row is inserted and updated and the store it; queries will use the stored value.