Проектирование базы данных: первичный ключ от нескольких источников данных - PullRequest
Новая
       38

Проектирование базы данных: первичный ключ от нескольких источников данных

2 голосов
/ 01 ноября 2011

Изначально я импортировал продукты из документа Excel из Источник питания 1 , и в нем был тип VARCHAR первичный * (пример PK # FOOD0001) * (поскольку 1 источник в то время, когда я только что импортировал его непосредственно в таблицу продуктов с автоматическим увеличением int ID)

Но мне нужно импортировать еду из другого источника Источник пищи 2 , который имеет полностью первичный тип ключа (INT) (пример PK # 25928747)

У меня сейчас есть:

Таблица продуктов

INT FoodId<PK>, Имя

Сервировочный столик

INT ServingId<PK>, FoodId<FK>, Имя, Размер

Каков наилучший дизайн базы данных, чтобы можно было импортировать любой источник пищи, который не повлияет на текущие идентификаторы или, по крайней мере, имеет отображение, чтобы продукты можно было легко обновлять, удалять и т. Д.? Я не хочу менять идентификатор на VARCHAR по соображениям производительности

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

Стол для еды 

INT FoodId<PK>, *VARCHAR FoodSourceFoodId*, Name
      1               #FOOD0001             Food 1
      2               #FOOD0002             Food 2
      3               25928747              Food 1
      4               25928748              Food 2

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

Как вы думаете, это путь? Или вы бы предложили что-нибудь еще?

Ответы [ 2 ]

2 голосов
/ 01 ноября 2011

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

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

CREATE TABLE Foods
(
 FoodId INTEGER NOT NULL UNIQUE, 
 Name CHAR(6) NOT NULL 
    CHECK (Name IN ('Food 1', 'Food 2')), 
 UNIQUE (Name, FoodId)
);

CREATE TABLE Foods1
(
 FoodId INTEGER NOT NULL UNIQUE, 
 Name CHAR(6) NOT NULL 
    CHECK (Name = 'Food 1'), 
 FOREIGN KEY (Name, FoodId)
    REFERENCES Foods (Name, FoodId)
    ON DELETE CASCADE
    ON UPDATE CASCADE, 
 Food1_ID CHAR(9) NOT NULL UNIQUE 
    CHECK (Food1_ID LIKE '#FOOD[0-9][0-9][0-9][0-9]')
);

CREATE TABLE Foods2
(
 FoodId INTEGER NOT NULL UNIQUE, 
 Name CHAR(6) NOT NULL 
    CHECK (Name = 'Food 2'), 
 FOREIGN KEY (Name, FoodId)
    REFERENCES Foods (Name, FoodId)
    ON DELETE CASCADE
    ON UPDATE CASCADE, 
 Food2_ID INTEGER NOT NULL UNIQUE
);
1 голос
/ 01 ноября 2011

Это похоже на хороший план. Другим более распространенным вариантом будет создание таблицы поддержки с INT FoodID в качестве внешнего ключа (для таблицы продуктов) и VARCHAR ID. Тогда, когда вам больше не нужно поддерживать импорт, вы можете просто бросить таблицу.

...