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

0

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

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

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

  • 0
    Используйте одну и ту же базу данных для обоих. Вы можете использовать разные схемы, чтобы иметь «логическую границу», если хотите. Или используйте что-то вроде внешней оболочки данных Prostrgres для доступа к другим базам данных.
  • 0
    Я полагаю, это зависит от того, для чего используется другая база данных? У меня есть система управления студентами, которая взаимодействует с различными системами безопасности в колледже, и мы не хотим, чтобы дверная система подключалась к каким-либо другим системам, поэтому мы храним пользователей в их базе данных, которая обновляет только новые записи каждые 10 минут в течение дня. Если наша база данных управления выходит из строя (или база данных безопасности), они не зависят друг от друга, чтобы продолжать работать.
Показать ещё 3 комментария
Теги:
microservices

2 ответа

1

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

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

0

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

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

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

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

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню