﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by mark.stockwell  / Roll Your Own Materialized Views / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Fri, 24 May 2013 08:11:55 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Roll Your Own Materialized Views</title><link>http://www.sqlservercentral.com/Forums/Topic853407-1704-1.aspx</link><description>As another example of the issue: assume the data actually changes in the base table, but the checksum of the new data is the same as the checksum of the old data.From here on out, the view will continue to return invalid (old) results until the data changes to a data set that returns a different checksum.  When you have bulk changes on large numbers of rows, large numbers of changes, or very specific collision generating changes (adding leading zeroes in particular, for CHECKSUM()), the code is more likely to fail to notice changes that actually happened.</description><pubDate>Thu, 11 Feb 2010 12:27:16 GMT</pubDate><dc:creator>Nadrek</dc:creator></item><item><title>RE: Roll Your Own Materialized Views</title><link>http://www.sqlservercentral.com/Forums/Topic853407-1704-1.aspx</link><description>Point well taken, checksum is not very unique.  The code should mitigate this, if there are duplicates you may end up deleting records that haven't changed, then adding them back. Little extra work for server, that's ok...</description><pubDate>Thu, 11 Feb 2010 12:21:29 GMT</pubDate><dc:creator>mark.stockwell</dc:creator></item><item><title>RE: Roll Your Own Materialized Views</title><link>http://www.sqlservercentral.com/Forums/Topic853407-1704-1.aspx</link><description>I would primarily note that CHECKSUM() returns a 4 byte CRC-32 value, and therefore has a very small number of possible values; a four and a half billion row table (i.e. data warehouse) absolutely guarantees collisions.Unfortunately, the chance of a collision is much greater than that.  For trivial collisions, try:SELECT CHECKSUM(1,1,1,1)SELECT CHECKSUM(0,1,1,1,1)SELECT CHECKSUM(0,0,1,1,1,1)I'd recommend changing this to actually do a full field by field comparison (noting which fields are NOT NULL and which allow NULL values).  If you truly insist on a hash, your best, still fairly simple, bet is probably to use SHA512 out of some CLR code.  HASHBYTES with SHA1 is built into SQL 2005+, though SHA1 is still not very good... but 160 bits of SHA1 hash is immensely better than 32 bits of CRC-32.Untested reference for SHA512: [url=http://sqlblog.com/blogs/michael_coles/archive/2009/04/12/let-s-hash-a-blob.aspx]http://sqlblog.com/blogs/michael_coles/archive/2009/04/12/let-s-hash-a-blob.aspx[/url]</description><pubDate>Thu, 11 Feb 2010 11:54:13 GMT</pubDate><dc:creator>Nadrek</dc:creator></item><item><title>Roll Your Own Materialized Views</title><link>http://www.sqlservercentral.com/Forums/Topic853407-1704-1.aspx</link><description>Comments posted to this topic are about the item [B]&lt;A HREF="/scripts/materialized+view/69350/"&gt;Roll Your Own Materialized Views&lt;/A&gt;[/B]</description><pubDate>Mon, 25 Jan 2010 19:42:59 GMT</pubDate><dc:creator>mark.stockwell</dc:creator></item></channel></rss>