Как я могу спроектировать таблицы SQL для хранения и извлечения текущих и исторических записей конфигурации сущностей? - PullRequest
Новая
       19

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

0 голосов
/ 14 февраля 2019

TLDR: Как структурировать SQL для сохранения / извлечения данных конфигурации объекта с возможностью узнать, какая конфигурация является текущей (активной), а также с возможностью сохранять и извлекать исторические конфигурации, которые больше не могут быть активными.

Подробности

Инструмент продаж используется для предложения товаров и их сопряжения с двигателем.Имеется M двигателей (рамы двигателей), и каждый двигатель имеет P конфигураций мощности.Каждая конфигурация может со временем меняться, поэтому необходимо вести исторический учет каждой конфигурации.Мне нужно знать, какая конфигурация активна (только одна может быть активной одновременно) для данного набора ключей (frame, power).И если он обновляется (создается новая запись конфигурации для этого ключевого кортежа), любые из существующих кавычек все равно должны быть связаны с исходным неактивным (frame, power) набором конфигурации.

Пример заказа

  1. Запрос на поиск текущей активной конфигурации для frame.id = 1, power.id = 1. Версия 1 возвращается как активная
  2. Я пишуэта конфигурация включена в цитату # 1 с использованием (frame, power, version) n-tuple
  3. Компания обновляет frame.id = 1 и power.id = 1, чтобы иметь другой набор атрибутов, который становится версией 2 и активным.Старая запись становится неактивной.
  4. Я создаю Цитату # 2 с этими новыми данными.Цитата № 1 должна сохранять первоначальную конфигурацию.

Как лучше всего структурировать / смоделировать таблицы SQL для этого?

Вот мой предварительный план, где

  • таблица кадров представляет раму двигателя (т.е. 215JM)
  • таблица мощности представляет требования к мощности двигателя (380/60)
  • конфигурация - это и рама, и мощность в качестве ключей вместе с версией (1, 2, 3 ..), и независимо от того, активна ли конфигурация (логическое значение)
  • , полезная нагрузка - это оставшиеся данные в таблице configuration, т. Е. Мощность (л.с.), эффективность

enter image description here

Мой вопрос:

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

Вот SQL, если требуется: 

CREATE TABLE frame (
  id INT NOT NULL,
  size VARCHAR(45) NULL,
  PRIMARY KEY (id))
ENGINE = InnoDB;

CREATE TABLE power (
  id INT NOT NULL,
  power VARCHAR(45) NULL,
  PRIMARY KEY (id))
ENGINE = InnoDB;

CREATE TABLE configuration (
  frame_id INT NOT NULL,
  power_id INT NOT NULL,
  version INT NOT NULL,
  active TINYINT NOT NULL,
  hp FLOAT NULL,
  efficiency VARCHAR(45) NULL,
  PRIMARY KEY (frame_id, version, active, power_id),
  INDEX fk_configuration_power1_idx (power_id ASC),
  INDEX fk_configuration_frame_idx (frame_id ASC),
ENGINE = InnoDB;

1 Ответ

0 голосов
/ 14 февраля 2019

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

Это сделает вашу таблицу конфигураций Медленно изменяющийся тип измерения-2

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

Это также будет означать, что вашТаблица будет иметь новый первичный ключ (суррогатный ключ), который будет однозначно идентифицировать записи.Ваш существующий первичный ключ - версия (frame_id, active, power_id) станет так называемым бизнес-ключом или естественным ключом: 

CREATE TABLE configuration (
  surrogate_key INT NOT NULL,
  frame_id INT NOT NULL,
  power_id INT NOT NULL,
  active TINYINT NOT NULL,
  hp FLOAT NULL,
  efficiency VARCHAR(45) NULL,
  effective_from DATE NOT NULL,
  effective_to DATE NULL,
  current_flag BOOL,
  PRIMARY KEY (surrogate_key),
  ...;

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

PS : Также стоит рассмотреть возможность хранения датffective_from иffective_to в виде целых чисел (либо в формате EPOX, либо в формате ГГГГММДД).фильтрация и объединение.

Надеюсь, это поможет.

...