Реляционный дизайн БД - главная таблица с несколькими адресами - PullRequest
Новая
       9

Реляционный дизайн БД - главная таблица с несколькими адресами

0 голосов
/ 05 июня 2018

Мне нужно спроектировать реляционную БД, которая будет массово загружать данные о клиенте / адресе на основе таких периодов, как Q1, Q2 и т. Д. Я хочу создать простую основную таблицу клиентов, которая включает демографические данные, такие как адрес.Проблема заключается в том, что адреса клиентов МОГУТ меняться с течением времени, и мне нужно захватить эти новые адреса, а также сохранить старые адреса в качестве снимка для более ранних периодов.

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

Не уверен, что оптимальный подход для такого сценария, и я надеялся, что кто-то еще может иметь некоторыепредложения?

1 Ответ

0 голосов
/ 05 июня 2018

Я хотел бы предложить такой дизайн:

  • покупатель: идентификатор клиента, другие поля покупателя
  • адрес: идентификатор адреса, улица 1, другие поля адреса
  • customer_address: идентификатор клиента, идентификатор адреса, действительный с даты, действительный на дату

Это позволяет сделать несколько вещей:

  • Адреса, которые должны регистрироваться отдельно для клиентов.Как правило, сам адрес не меняется, меняется отношение клиента к адресу.Это фиксируется в объединяющей таблице между клиентом и адресом.
  • В таблице customer_address вы можете зафиксировать действительный от даты и действительный на сегодняшний день.Это позволяет вам не только фиксировать, что адрес действителен для всех кварталов, но и фиксировать изменения в адресах для клиентов.Он также учитывает кварталы в разные годы (например, 1 января 2017 года и 1 января 2018 года - оба квартала).
  • Наличие нескольких таких таблиц уменьшит количество дублирующихся данных в системе.

Ваши запросы могут объединять эти таблицы и фильтровать их по действительным датам в таблице customer_address.

Имеет ли все это смысл?

...