Question

i’m Creating an application that will be working off a User table, the user table has many other columns like Email,Name,Address,etc. There is a verification stage for the User that needs to be verified when they enter an email address. The page would display all the users that are not verified and that entered an email address.

I’ve prepared three examples/approaches and wondering what would be the most productive way if there would be a need for also Logging all the verifications in case one is verified by mistake, therefore, delete a verification. Also, lets say there is more than one type of verification, so there is one for email address and another one for street address.

A few things to consider is that if the user adds an email address at a later date, then it should automatically go into the verification queue because it would recognize it either directly, or it would have to create a pre-set value (like example 2).

I prefer making the application more light-weight (like example 1), but i don’t want to compromise on performance, and need some help or some re-affirmation with how to approach this..

FIRST EXAMPLE

Verification Queue Page would display the data:

SELECT * WHERE EMAIL <> '' AND User.IsVerified = 0
The fields would look more like this:

//for handling verified
User.IsVerified bit = 0,
User.VerifiedDate datetime,
User.VerifiedNotes varchar(250),
User.VerifiedBy varchar(20)

SECOND EXAMPLE

First we define if it needs verification:

UPDATE User SET User.NeedsVerification = 1 WHERE User.Email <> ''

Second, the page would display the data:

SELECT * WHERE User.NeedsVerification = 1 AND User.IsVerified = 0

The fields would look more like this:

//for handling verified
User.NeedsVerification bit,
User.IsVerified bit,
User.VerifiedDate datetime,
User.VerifiedNotes varchar(250),
User.VerifiedBy varchar(20)

THIRD EXAMPLE

Verification Queue Page would display the data:

SELECT * FROM User INNER JOIN Verification ON User.ID Verification.UserID WHERE User.EMAIL <> '' AND Verification.ID Is Not Null

The fields would be in another table, only considering this option because there may be more types of Verifications and instead of a NeedsVerification field, it can be more like If it even exists sort of deal:

Verification.UserID int,
Verification.Type int,
Verification.IsVerified,
Verification.VerifiedDate datetime,
Verification.VerifiedNotes varchar(250),
Verification.VerifiedBy varchar(20)

Answer 1

I’d lean toward a collection of tables to record the various verifications, one for each type. Thus you would have EmailVerifications, BillToAddressVerifications, ShipToAddressVerifications, CreditVerifications, …, e.g.:

EmailVerificationId int identity,
UserId int,
EmailAddress varchar(256),
ChangeDate datetime, -- When the user updated the EmailAddress.
VerifiedDate datetime null, -- IsVerified if this is not NULL.
VerifiedNotes varchar(250),
VerifiedBy varchar(20) -- Or AdminId?

This allows you to accomodate:

1. Multiple changes per user, e.g. several email addresses over the years.
2. Adding additional types of verifications, e.g. telephone number, as time goes on.
3. You can also use the history for things like sending notifications to both old and new addresses when a change is made.
4. Adding verifications that are applied according to business rules, e.g. someone signing up for a newsletter doesn’t need a verified email address. A supplier does.
5. You could extend it to support “validated” and “verified” data. A validated email address doesn’t cause bounces and is good enough for a newsletter, a verified email address has been confirmed to be correct.

For performance you could denormalize the data and keep an IsVerified summary bit in the user record and use triggers to maintain the value based on updates to the other tables.