Общий первичный ключ
Я предполагаю, что это довольно распространенный вопрос, но я не могу найти его в списке прошлых вопросов. У меня есть набор таблиц для продуктов, которые должны использовать индекс первичного ключа. Предположим что-то вроде следующего:
product1_table:
id,
name,
category,
...other fields
product2_table:
id,
name,
category,
...other fields
product_to_category_table:
product_id,
category_id
Ясно, что было бы полезно иметь общий индекс между двумя таблицами продуктов. Обратите внимание, что идея держать их отдельно, потому что они имеют в значительной степени разные наборы полей, помимо базовых, однако они имеют общую классификацию.
ОБНОВИТЬ:
Многие люди предлагают наследование таблиц (или gen-spec). Это вариант, о котором я знаю, но в других системах баз данных я мог бы разделить последовательность между таблицами, которые, как я надеялся, в MySQL было похожим решением. Я предполагаю, что это не основано на ответах. Я думаю, мне придется пойти с наследованием таблицы... Спасибо всем.
7 ответов
Это не очень часто, нет. Нет собственного способа поделиться первичным ключом. Что я мог бы сделать в вашей ситуации это:
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
Таким образом, существует одна основная таблица продуктов, которая имеет записи для всех продуктов и имеет поля, которые обобщают между типами, и таблицы с указанным типом с внешними ключами в таблицу основных продуктов, которые имеют специфичные для типа данные.
Лучшее решение - поместить общие столбцы в одну таблицу продуктов, а специальные столбцы - в две отдельные таблицы. Используйте product_id в качестве первичного ключа во всех трех таблицах, но в двух специальных таблицах он, кроме того, является внешним ключом к основной таблице товаров.
Это упрощает основной поиск товаров по идентификаторам и именам по категориям.
Также обратите внимание, что ваш дизайн позволяет каждому продукту быть не более одной категории.
Кажется, вы ищете наследование таблиц.
Вы можете использовать общую таблицу product с атрибутами, общими для обоих product1 и product2, плюс type атрибут, который может быть "product2" или же "product1"
Потом таблицы product1 а также product2 будет иметь все свои конкретные атрибуты и ссылку на родительскую таблицу product,
product:
id,
name,
category,
type
product1_table:
id,
#product_id,
product1_specific_fields
product2_table:
id,
#product_id,
product2_specific_fields
Сначала позвольте мне заявить, что я согласен со всем, что сказали Хаос, Ларри и Фил.
Но если вы настаиваете на другом пути...
Есть две причины для вашего общего ПК. Одна уникальность по двум таблицам и две для полной ссылочной целостности.
Я не уверен, какая именно "последовательность" поддерживает колонки Auto_increment. Кажется, что есть системная настройка для определения приращения по значению, но ничего для столбца.
То, что я бы сделал в Oracle, это просто разделил одну и ту же последовательность между двумя таблицами. Другой метод - установить значение STEP 2 в auto_increment и начать одно с 1, а другое с 2. В любом случае вы генерируете уникальные значения между ними.
Вы можете создать третью таблицу, в которой нет ничего, кроме столбца PK. В этом столбце также можно указать автонумерацию, если нет способа создать пропускаемый автонуммер на одном сервере. Затем в каждую из ваших таблиц данных вы добавляете триггеры CRUD. Вставка в любую таблицу данных сначала инициирует вставку в таблицу псевдоиндекса (и возвращает идентификатор для использования в локальной таблице). Аналогично, удаление из локальной таблицы может инициировать удаление из таблицы псевдоиндекса. Любые дочерние таблицы, которые должны указывать на родительскую точку этой псевдоиндексной таблицы.
Обратите внимание, что это должен быть триггер для каждой строки, и это замедлит работу crud в этих таблицах. Но таблицы типа "продукт", как правило, НЕ имеют очень высокого уровня DML. Любой, кто жалуется на "влияние на производительность", не учитывает масштаб.
Пожалуйста, обратите внимание, это предоставляется как действующая альтернатива, а не моя рекомендация как лучший способ
Вы не можете "поделиться" первичным ключом.
Не зная всех деталей, мой лучший совет - объединить таблицы в одну таблицу продуктов. Наличие необязательных полей, которые заполняются для одних продуктов, а не для других, не обязательно является плохим дизайном.
Другой вариант заключается в том, чтобы иметь своего рода модель наследования, где у вас есть одна таблица продуктов, а затем две таблицы "подтипов" продуктов, которые ссылаются на основную таблицу продуктов и имеют собственный специализированный набор полей. Запрашивать эту модель гораздо сложнее, чем отдельную таблицу, ИМХО, поэтому я считаю ее менее желательным вариантом.
Ваше объяснение немного расплывчато, но, исходя из моего основного понимания, я бы соблазнился сделать это
Таблица продуктов содержит общие поля
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), которая подразумевает, что каждый продукт может быть связан со многими категориями. Теперь он может оставаться прежним.