Forum Discussion
IR with no Collission
smpa01 I think you can rely on GUID because the chances of it being a duplicate is extremely low
https://betterexplained.com/articles/the-quick-guide-to-guids/
1/(2^128) * 1/(2^128) = 1/(2^256)
which will return 8.63617e-78 so that's 78 zeroes after decimal and then 8636 so 0.0000000000000000000000000000000000000000000000000000000000000000000000000000008636 which is very low probability of 2 GUIDs being the same.
Thanks AntrikshSharma yes, I have thought that but with my IR being set up the way it is now, how can I ensure that it does not introduce any collision in the data, meaning how can I ensure that checksum(NEWID()) called today and checksum(NEWID()) called in perpetuity will never return a same ID as previously called.
If there is absolute cetrainty , I am totally up for it. I want to devise a solution that works for eternity without needing to be bothered about the data so that i can focus on analysis and viz. Data issue is currently holding me back and I am looking for a permanent fix for this issue.
smpa01 I think you can rely on GUID because the chances of it being a duplicate is extremely low
https://betterexplained.com/articles/the-quick-guide-to-guids/
1/(2^128) * 1/(2^128) = 1/(2^256)
which will return 8.63617e-78 so that's 78 zeroes after decimal and then 8636 so 0.0000000000000000000000000000000000000000000000000000000000000000000000000000008636 which is very low probability of 2 GUIDs being the same.
While NEWID() is awesome, I have experimented in last few weeks whether a column created through DAX (instead of PQ) in a table that has IR is immune to IR or not. It turned out that DAX values are not getting duplicated.