Архитектура для объединения учетных записей пользователей в приложении

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

сценарий 1: Пользователь регистрируется с идентификатором электронной почты и номером телефона => мы создаем новую запись пользователя в базе данных с учетом уникальности электронной почты. сценарий 2: пользователь регистрируется только с номером => мы создаем новую запись пользователя в базе данных с уникальным фиктивным адресом электронной почты, который я генерирую.

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

Теперь мне нужно поддерживать свойство уникальности как для электронной почты, так и для номера телефона. Итак, мне нужно объединить обе учетные записи пользователей (фиктивную электронную почту и реальную электронную почту), которые имеют один и тот же номер телефона.

Проблема в том, что обе эти учетные записи могут иметь несколько ссылок в разных местах базы данных. Каким должен быть подход к объединению двух учетных записей?

edit: я использую MongoDB на бэкэнде. Он генерирует поле «_id» для каждого документа и использует его в качестве первичного ключа для этого документа. Таким образом, это поле «_id» служит внешним ключом для этого пользовательского документа для остальной части базы данных.

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

{
    _id: ObjectId("5d443787f86f9a3dfa782a3c"),
    name: 'user name',
    email: '[email protected]',
    phone_number: '1234567890'
}

другой образец документа в коллекциях пользователей, где у пользователя есть дублирующийся номер телефона =>

{
    _id: ObjectId("5c9a1146c89b2d09740ccd17"),
    name: 'dummy user name',
    email: '[email protected]',
    phone_number: '1234567890'
}

person varshneyanmol    schedule 05.08.2019    source источник
comment
Не могли бы вы показать некоторые образцы данных? Это поможет понять, каковы ваши первичные и внешние ключи - например, есть ли в справочных таблицах адрес электронной почты в качестве внешнего ключа?   -  person Neville Kuyt    schedule 05.08.2019
comment
@NevilleKuyt Я отредактировал вопрос для большей ясности.   -  person varshneyanmol    schedule 05.08.2019


Ответы (1)


Здесь вы можете сделать две вещи: либо создать уровень косвенности (таблица сопоставления, которая сопоставляет идентификаторы вместе, которые вы запрашиваете во время выполнения), либо вам придется обновить все другие места, где вы ссылаетесь на этот идентификатор.

Лично я бы подумал об обновлении и удалении старой записи. Это даст вам возможность решать в каждом конкретном случае, как объединить записи. Простое обновление внешнего ключа, вероятно, создаст множество странных декартовых координат, которых вы не ожидаете.

person Rob Conklin    schedule 06.08.2019