Общий первичный ключ

Question

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

product1_table:
    id,
    name,
    category,
    ...other fields

product2_table:
    id,
    name,
    category,
    ...other fields

product_to_category_table:
    product_id,
    category_id

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

UPDATE:

Многие люди предлагают наследование таблиц (или gen-spec). Это вариант, о котором я знаю, но в других системах баз данных я мог бы разделить последовательность между таблицами, которые, как я надеялся, были в MySQL аналогичным решением. Я предполагаю, что это не основано на ответах. Я думаю, мне придется пойти с наследованием таблицы ... Спасибо всем.

Answer 1

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

product_table
    id
    name
    category
    general_fields...

product_type1_table:
    id
    product_id
    product_type1_fields...

product_type2_table:
    id
    product_id
    product_type2_fields...

product_to_category_table:
    product_id
    category_id

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

Answer 2

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

Это упрощает основной поиск товаров по идентификаторам и именам по категориям.

Обратите внимание, что ваш дизайн позволяет каждому продукту быть в одной категории не более.

Answer 3

Сначала позвольте мне заявить, что я согласен со всем, что сказали Хаос, Ларри и Фил.

Но если вы настаиваете на другом пути ...

Есть две причины для вашего общего ПК. Одна уникальность по двум таблицам и две для полной ссылочной целостности.

Я не уверен, какая именно «последовательность» поддерживает колонки Auto_increment. Кажется, что есть системная настройка для определения приращения по значению, но ничего для столбца.

То, что я хотел бы сделать в Oracle, это просто разделить одну и ту же последовательность между двумя таблицами. Другой метод - установить значение STEP 2 в auto_increment и начать одно с 1, а другое с 2. В любом случае вы генерируете уникальные значения между ними.

Вы можете создать третью таблицу, в которой нет ничего, кроме столбца PK. В этом столбце также можно указать автонумерацию, если нет способа создать пропускаемый автонуммер на одном сервере. Затем в каждую из ваших таблиц данных вы добавляете триггеры CRUD. Вставка в любую таблицу данных сначала инициирует вставку в таблицу псевдоиндекса (и возвращает идентификатор для использования в локальной таблице). Аналогично, удаление из локальной таблицы может инициировать удаление из таблицы псевдоиндекса. Любые дочерние таблицы, которые должны указывать на родительскую точку этой псевдоиндексной таблицы.

Обратите внимание, что это должен быть триггер для каждой строки, и это замедлит работу crud в этих таблицах. Но таблицы типа «продукт», как правило, НЕ имеют очень высокого уровня DML. Любой, кто жалуется на «влияние на производительность», не , учитывая масштаб.

Обратите внимание, это предоставляется как функциональная альтернатива, а не моя рекомендация как лучший способ

Answer 4

Кажется, вы ищете наследование таблиц.

Вы можете использовать общую таблицу product с атрибутами, общими как для product1, так и для product2, плюс атрибут type, который может быть либо "product2", либо"product1"

Тогда таблицы product1 и product2 будут иметь все свои специфические атрибуты и ссылку на parent table product.

product:
    id,
    name,
    category,
    type

product1_table:
    id,
    #product_id,
    product1_specific_fields

product2_table:
    id,
    #product_id,
    product2_specific_fields

Answer 5

Это еще один случай gen-spec.

См. Предыдущее обсуждение

Answer 6

Ваше объяснение немного расплывчато, но, исходя из моего базового понимания, я бы соблазнился сделать это

Таблица продуктов содержит общие поля

product
-------
product_id
name
...

таблица product_extra1 и таблица product_extra2 содержат разные поля в этих таблицах применяются отношения один к одному между product.product_id и product_extra1.product_id и т. д. Укрепите отношение один к одному, установив уникальность product_id в таблицах внешнего ключа (product_extra1 и т. д.) с использованием ограничения уникальности. вам нужно будет определить бизнес-правила относительно того, как эти данные будут заполнены

product_extra1
---------------
product_id
extra_field1
extra_field2
....

product_extra2
---------------
product_id
different_extra_field1
different_extra_field2
....

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

Answer 7

Вы не можете «поделиться» первичным ключом.

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

Другой вариант заключается в том, чтобы иметь своего рода модель наследования, где у вас есть одна таблица продуктов, а затем подтип «два продукта»"таблицы, которые ссылаются на основную таблицу продуктов и имеют собственный специализированный набор полей.Запрашивать эту модель гораздо сложнее, чем отдельную таблицу, ИМХО, поэтому я считаю ее менее желательным вариантом.