Какую структуру таблицы использовать, если есть два объекта одного типа, но разной природы? - PullRequest
0 голосов
/ 11 июля 2019

Учитывая, что существует два вида продуктов X и Y. X имеет A, B и C в качестве первичного ключа, тогда как Y имеет A и D в качестве первичного ключа. Должен ли я положить их в одну таблицу? Почему я должен, а если нет, то почему?

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

Ниже приведены примеры таблиц для приведенного выше случая.

CREATE TABLE `product_type_b` (
    `PRODUCT_CODE` VARCHAR(50) NOT NULL,
    `COMPONENT_CODE` VARCHAR(50) NOT NULL,
    `GROUP_INDICATOR` VARCHAR(50) NULL DEFAULT NULL,
    `RECORD_TIMESTAMP` DATE NULL DEFAULT NULL,
    PRIMARY KEY (`PRODUCT_CODE`, `COMPONENT_CODE`)
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
;
CREATE TABLE `product_type_a` (
    `PRODUCT_CODE` VARCHAR(50) NOT NULL,
    `CHOICE_OF_COVER` VARCHAR(50) NOT NULL,
    `PLAN_TYPE` VARCHAR(50) NOT NULL,
    `RECORD_TIMESTAMP` DATE NULL DEFAULT NULL,
    `PRODUCT_TENURE` INT(11) NULL DEFAULT NULL,
    PRIMARY KEY (`PRODUCT_CODE`, `CHOICE_OF_COVER`, `PLAN_TYPE`)
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
;

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

Вот общая картина рассматриваемой системы.

  • Каждый тип продукта имеет свой источник, из которого он отправляется в систему.
  • Нам нужно хранить эти продукты в базе данных.
  • Мне бы хотелось иметь баланс между нормализацией и производительностью, чтобы мои скорости чтения-записи не сильно пострадали из-за чрезмерной нормализации.
  • Существует также веб-приложение, в котором есть страница, на которой пользователь может выполнять поиск по этим продуктам.
  • Пользователь будет заполнять определенные поля столбцов в качестве фильтров, на основе которых нам нужно выбрать продукты и показать их в пользовательском интерфейсе.
  • вариации в подтипах в настоящее время равны 2, и ожидается, что они не превысят 4-5, что снова Может быть, более десяти лет. Это опять-таки приближение.n Я надеюсь, что это представляет более широкую картину системы.

Я хочу иметь хорошую скорость чтения и записи без особых компромиссов. Так стоит ли мне продолжать этот дизайн? Если нет, какой дизайн должен быть реализован?

Ответы [ 2 ]

1 голос
/ 12 июля 2019

Для торговой системы с учетом максимум 5 типов продуктов и очень ограниченного числа атрибутов я бы предпочел одну таблицу для всех продуктов с суррогатным ПК. Подумайте о ссылках на продукты торговых транзакций, это самая большая часть общего контента БД в долгосрочной перспективе.

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

Поисковые индексы отражают самые популярные пользовательские поиски в зависимости от типа продукта.

1 голос
/ 11 июля 2019

Это типичная проблема модели категории / подкатегории. Есть несколько вариантов:

  1. Поместите все в одну таблицу, которая будет иметь несколько столбцов NULLable потому что разные подтипы не имеют одинаковых атрибутов;

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

  3. Каждый подтип имеет свою собственную таблицу, включая все общие столбцы все подтипы.

(1) хорошо, если подтип очень ограничен;
(3) подходит, если вариации подтипов очень ограничены.

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

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

...