Если мои пользователи хранятся в другой базе данных, должен ли я дублировать их в своем сервисе, который использует базу данных SQL?

Question

Если мои пользователи хранятся в какой-то другой базе данных, но я строю посты в своей базе данных SQL, я должен создать другую таблицу users?

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

Какая рекомендация?Создать другую таблицу users или просто передать идентификаторы пользователя для запроса?

Answer 1

Существует 3 очевидных решения.

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

Следующий вариант - сохранитькопия пользовательских данных вместе с вашими сообщениями.Это приводит к интересным режимам сбоев - данные в пользовательской базе данных могут быть не синхронизированы.Однако это довольно распространенная стратегия при использовании сторонних систем аутентификации (например, вход в систему с учетными данными Google / Facebook / Github / Stack Exchange).Способ сделать эту работу состоит в том, чтобы минимизировать объем дублируемых данных и обеспечить их безопасность, если они устарели.Например, отображаемое имя пользователя, вероятно, в порядке;текущий остаток на банковском счете, вероятно, нет.

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

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

CQRSподход (общий для микросервисных архитектур) обеспечивает некоторую структуру для этого.

Answer 2

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

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