Если мои пользователи хранятся в какой-либо другой базе данных, но я строю сообщения в своей базе данных SQL, должен ли я создавать других users
таблицы?
Если бы я это сделал, я бы дублировал всех своих пользователей и должен был убедиться, что это будет синхронизироваться с другой базой данных, но, с другой стороны, мои таблицы сообщений могут сэкономить место, обращаясь к fk вместо полной строки id каждый раз,
Какова рекомендация? Создать других users
таблицы или просто передать идентификаторы пользователей для запроса?
Если у вас есть служба, которая хранит и предоставляет информацию о пользователях, тогда другие службы, которые нуждаются в этой информации, должны связываться с сервисом пользователя, чтобы получить ее. То есть, по-видимому, причина, по которой пользовательская служба существует в первую очередь.
В зависимости от волатильности списка пользователей и требований к изменениям, которые должны соблюдаться в службе "Сообщения", вы можете рассмотреть некоторое краткосрочное кеширование в службе "Сообщения", но я, конечно, не сохранил бы другую копию списка пользователей там.
Существует 3 очевидных решения.
Самый простой, самый чистый и быстрый способ - использовать внешние ключи и соединения между вашей базой данных "посты" и вашей "пользовательской" базой данных. В этом случае, когда вы показываете список сообщений, вы можете получить как сообщения, так и данные пользователя в одном запросе, и нет необходимости обновлять данные.
Следующая опция - хранить копию пользовательских данных рядом с вашими сообщениями. Это приводит к развлекательным режимам отказа - данные в пользовательской базе данных могут выйти из синхронизации. Однако это довольно распространенная стратегия при использовании сторонних систем аутентификации (например, вход в систему с вашими учетными данными Google/Facebook/Github/Stack Exchange). Способ сделать эту работу состоит в том, чтобы свести к минимуму количество данных, которые вы дублируете, и быть в безопасности, если оно устарело. Например, отображаемое имя пользователя, вероятно, хорошо; текущий баланс банковского счета, вероятно, нет.
Конечная опция - хранить первичный ключ для пользователей в базе данных сообщений и извлекать данные пользователя во время выполнения. Это, скорее всего, приведет к ошибкам с синхронизацией данных, но это может привести к проблемам с производительностью. Получение сведений о пользователях за 1000 сообщений один за другим, очевидно, намного медленнее, чем поиск всего через объединенный запрос.
Тогда выбор заключается в том, что "у меня есть служба, которая объединяет данные для почты и пользователя, а мой пользовательский интерфейс извлекает все из этой службы или я разрешаю пользовательскому интерфейсу получать сообщения, а затем пользователи для каждого сообщения". В основном это зависит от использования приложения и можно ли использовать асинхронные вызовы для извлечения информации о пользователе. Если это вообще возможно (при условии, что вы создаете веб-приложение), самым простым вариантом может быть возврат сообщений и идентификаторов пользователей и использование запросов Ajax для получения пользовательских данных по мере необходимости.
Подход CQRS (общий для микросервисных архитектур) обеспечивает некоторую структуру для этого.