Question

I have a requirement to store the list of services for multiple computers. I thought I would create one table to hold a list of all possible tables, a table for all possible computers and then a table to link a service to a computer.

I was thinking to keep the full services list unique, I could possibly use a hash of the executable as the primary key for the service, but i’m not sure if there would be any downsides to this (note that the hashing is only for identification. Not for any types of security purposes). I was thinking rather than using a binary field as the primary/foreign key, that I would store the value as a base 64 encoded sha512, and using an nvarchar(88). Something similar to this:

CREATE TABLE Services
(
  ServiceHash nvarchar(88) NOT NULL,
  ServiceName nvarchar(256) NOT NULL,
  ServiceDescription nvarchar(256),
  PRIMARY KEY (ServiceHash)
)

Is there any inherent problems with this solution? (I will be using a SQL 2008 database and generally accessing it via C#.Net).

Answer 1

The problem is that a hash is per definition NOT UNIQUE. It is unlikely you get a collision, but it IS possible. As a result, you can not use the hash only, which means the whole hash id is a dead end.

Use a normal ID field, use a unique constraint with index on the ServiceName.