Question

Here’s a simplified example.

UserDetails (UserID INT UserGUID UNIQUEIDENTIFIER Name VARCHAR(50) Age INT)
UserRatings (UserID INT Rating INT Date DATETIME)
UserVotes   (UserID INT Votes INT Date DATETIME)

The UserGUID only exists in the main table.

In the application layer only GUID’s are parsed around, never INTS. This is to prevent competitors from guessing at some key numbers on my site like (e.g. user count).

In the SPROCS relating to tables UserRatings and UserVotes, I have to DECLARE UserID and SET it based on the UserGUID that is getting parsed back at the start of every procedure.

This occurs not just for the Users table but for every other object that has a main table and branched tables so there are tons of these DECLARE/SET type procedures all over the place.

Is this a good design?

Answer 1

The UserGUID only exists in the main
table. In the application layer only
GUID’s are parsed around, never INTS.
This is to prevent competitors from
guessing at some key numbers on my
site like (e.g. user count).

Seems quite reasonable to me.

In the SPROCS relating to tables
UserRatings and UserVotes, I have to
DECLARE UserID and SET it based on the
UserGUID that is getting parsed back
at the start of every procedure.

You could also define a view spanning UserDetails+UserRatings, as well as UserDetails+UserVotes (or even all three tables at once), which include the GUID from the UserDetails table. This would make querying the tables easier and you wouldn’t have to first extract the ID from the GUID and use that to query the table in question.

Update: if you e.g. need to query UserRatings frequently, you could create a view like this:

CREATE VIEW dbo.UserRatingsWithDetails
AS 
    SELECT 
       ud.UserGuid, ud.Name, ud.Age,
       ur.UserID, ur.Rating, ur.Date
    FROM
       dbo.UserDetails ud
    INNER JOIN
       dbo.UserRatings ur ON ur.UserID = ud.UserID

and then you can select from that view without running a separate SELECT first:

SELECT UserID, Name, Rating, Date
  FROM dbo.UserRatingsWithDetails
 WHERE UserGuid = @SomeGuidValue

With the right indices (on the foreign key field in UserRatings), this is a very highly performant JOIN – no worries here!