Хранение информации о незарегистрированных пользователях

Question

Проблема, которая появилась, состоит в том, чтобы открыть наше приложение (мы можем представить его немного похожим на онлайн-магазин) для незарегистрированных пользователей.

На данный момент существует административная система, в которой сотрудники добавляются суперпользователями, и веб-сайт с клиентами, которые добавляют себя путем регистрации.

Нас попросили разрешить клиентам использовать веб-сайт без регистрации или входа в систему, но мы не хотим ломать таблицу «заказов» - нам все равно нужно обращаться к каждому клиенту индивидуально и поддерживать функциональность зарегистрированных пользователей ( поиск адреса, история покупок и т. д.). Основная идея, которую мы обдумали, заключается в использовании адреса электронной почты незарегистрированного клиента в качестве замены суррогатного ключа (или его хеша) в таблице клиентов, чтобы новые и старые клиенты могли просто ввести свой адрес электронной почты при оформлении заказа, чтобы добавиться в нашу базу данных и получить подтверждение их заказа. Проблема разных адресов электронной почты для каждого клиента может быть устранена с помощью инструмента «слияния» на стороне администратора, и проблема, когда несколько клиентов используют один и тот же адрес электронной почты (в некоторых офисных средах), не является для нас большой проблемой.

Основной вопрос заключается в следующем: как реальные приложения обрабатывают незарегистрированных пользователей?

Обновление в ответ на ответы

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

Answer 1

В нашей компании мы делаем это следующим образом:

1. когда ЛЮБОЙ пользователь делает заказ, мы ищем его электронную почту (которую он требует , чтобы указать и является уникальным) в customers таблице.
2. Если его там нет, мы просто создаем пользователя (у нас уже есть все необходимые данные из заказа пользователя) и помечаем его как registred=0.
3. , теперь мы продолжаем заказобрабатывать его идентификатор пользователя.
4. когда кто-то регистрируется под этим электронным письмом, мы просто обновляем его учетные данные (что бы он ни указывал), сохраняя его историю заказов и все остальное.Я не думаю, что это беспокоит безопасность, пользователь должен подтвердить адрес электронной почты, поэтому, если учетная запись действительно не его, он не будет регистрироваться в любом случае.

Мы не разрешаемУже зарегистрировано электронное письмо для создания заказа, так что это должно очистить ваше слияние писем, потому что никто не сможет создать зарегистрированный и незарегистрированный аккаунт под одним адресом электронной почты, и когда он это сделает, он никогда не сможет делать покупки незарегистрированным снова.Надеюсь, это поможет.

Answer 2

В отличие от Pal, я бы настоятельно рекомендовал использовать естественные данные в качестве ключа.

использовать адрес электронной почты незарегистрированного клиента в качестве суррогатного ключа

Во-первых, это утверждениеоксюморон.Суррогатный ключ по определению не имеет отношения к фактическим данным.

Далее, если у вас есть адрес электронной почты, это означает, что они завершили какой-то процесс регистрации.

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

Единственное, о чем вам нужно беспокоиться, это о том, что, используя адрес электронной почты при отсутствии другой аутентификации, вы теряете информацию, которая в противном случае была бы конфиденциальной (например, предыдущие заказы)

Answer 3

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

Используйте полностью синтетический ключ (например, счетчик) и просто используйте его.