Лучшая производительность и эффективная структура таблиц для создания системы очередей проверки

Question

Я создаю приложение, которое будет работать с таблицей User, в пользовательской таблице есть много других столбцов, таких как «Электронная почта», «Имя», «Адрес» и т. Д.Для пользователя существует этап проверки, который необходимо подтвердить при вводе адреса электронной почты.На странице будут отображаться все пользователи, которые не подтверждены и которые ввели адрес электронной почты.

Я подготовил три примера / подхода и задаюсь вопросом, что будет наиболее продуктивным способом, если потребуется также ведение журнала.все проверки в случае, если один проверен по ошибке, поэтому удалите подтверждение.Кроме того, предположим, что существует более одного типа проверки, поэтому есть один для адреса электронной почты, а другой - для адреса улицы.

Следует учесть несколько моментов: если пользователь добавит адрес электронной почты позднееdate, то он должен автоматически войти в очередь проверки, потому что он распознает его либо напрямую, либо ему придется создать предварительно установленное значение (как в примере 2).

Я предпочитаю сделать приложение более легким.вес (как в примере 1), но я не хочу идти на компромисс по производительности, и мне нужна помощь или какое-то подтверждение того, как подойти к этому ..

ПЕРВЫЙ ПРИМЕР

Страница очереди проверки будет отображать данные:

SELECT * WHERE EMAIL <> '' AND User.IsVerified = 0 Поля будут выглядеть примерно так:

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

ВТОРОЙ ПРИМЕР

Сначала мы определяем, требуется ли проверка:

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

Во-вторых, на странице будут отображаться данные:

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

поля будут выглядеть так:

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

ТРЕТИЙ ПРИМЕР

На странице очереди проверки будут отображаться данные:

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

Поля будут находиться в другой таблице, толькоРассматривая эту опцию, потому что может быть больше типов Проверок и вместо поля NeedsVerification, это может быть больше похоже на Если даже существует какая-то сделка:

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

Answer 1

Я бы склонялся к набору таблиц для записи различных проверок, по одной для каждого типа. Таким образом, вы бы имели EmailVerifications, BillToAddressVerifications, ShipToAddressVerifications, CreditVerifications, ..., например ::

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?

Это позволяет разместить:

1. Несколько изменений на пользователя, например, несколько адресов электронной почты за эти годы.
2. Добавление дополнительных типов проверок, например, номер телефона, время идет.
3. Вы также можете использовать историю для отправки уведомлений на старые и новые адреса при внесении изменений.
4. Добавление проверок, которые применяются в соответствии с бизнес-правилами, например, кому-то, подписавшемуся на новостную рассылку, не нужен подтвержденный адрес электронной почты. Поставщик делает.
5. Вы можете расширить его для поддержки «проверенных» и «проверенных» данных. Подтвержденный адрес электронной почты не вызывает отказов и достаточно хорош для рассылки, подтвержденный адрес электронной почты подтвержден.

Для повышения производительности вы можете денормализовать данные и сохранить итоговый бит IsVerified в пользовательской записи и использовать триггеры для поддержания значения на основе обновлений других таблиц.