Иметь несколько копий таблиц в базах данных для простого запроса на объединение или данные связаны в программе?

Question

В большой системе, которая использует несколько баз данных.

например:

db_trade используется для хранения торговой информации

db_fund используется для хранения учетной записи пользователя

db_auth используется для аутентификации и авторизации

В этом случае user_info является общей информацией.

Пользовательский интерфейс торговой системы и системы фондов должен отображать информацию о торговле или счете с информацией о пользователе. для повышения производительности необходимо выполнить sql запрос, оставленный join user_info.

Я не знаю, как спроектировать большую систему:

Выполнить ассоциацию данных в программе? Синхронизировать таблицу user_info в каждой базе данных?

Answer 1

У каждого подхода есть свои плюсы и минусы:

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

Денормализованный подход позволяет хранить несколько копий одних и тех же данных в разных местах и ​​лучше для производительности. Этот подход обычно рекомендуется для проектирования больших данных и баз данных NoSQL. Пример, в котором это имеет смысл: предположим, что вы разрабатываете систему чата и вам необходимо отображать сообщения рядом с именем автора сообщения. Вы, вероятно, предпочтете хранить отображаемое имя рядом с сообщением, а не только идентификатор пользователя, чтобы вам не приходилось делать дорогостоящее присоединение при каждом отображении сообщений.

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

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

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

Как правило, системы больших данных жертвуют согласованностью в пользу производительности и доступности.