December 9, 2021 at 6:58 pm
Makes sense, but I still can't wrap my head around why you would want a column that contains an arbitrary incremental, albeit not.. consistent number that also isn't unique.
Why would a design require such a thing? Something like a person entity, where there is really no set of attributes that uniquely identify a person?
What is the need to "order" the data with a numerical value?
When you say most of what you created is "not very wide and filtered by nvarchar values", I'm kind of curious about your schema. As well as your clustered indexes, and the daily massive fragmentation your indexes must be experiencing.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 9, 2021 at 7:59 pm
I think you are grossly overestimating the amount of tables I build :D. I mostly deal in backups,access, and troubleshooting. The only tables I've built have to deal with keeping track of server data for reporting such as server names, environments they exist on, if they are encrypted and so forth. Because this data inherintly doesn't have any unique values that isn't nvarchar, I would create an identity column such as serverid as a primary key and populate the table so that when I join, I'm joining on that serverid rather than something like servername to pull the data from the normalized tables that contain different server information.
And again "Something like a person entity, where there is really no set of attributes that uniquely identify a person?" if the IDENTITY inherently isn't unique, why would you ever use it WITHOUT forcing it to be unique via primary key,unique keyword, or unique index?
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply