2012-02-14 1 views
4

У меня есть две таблицы с отношением «один к одному». Таблица 1 имеет составной первичный ключ, состоящий из 4 столбцов. Внешний ключ таблицы 2 установлен в первичный ключ таблицы1.Можете ли вы использовать INNER JOIN с первичным ключом?

Когда я пытаюсь следующий пункт UPDATE, я получаю сообщение об ошибке:

UPDATE Table2 
SET column1 = fakeTable.c1 
FROM Table2 INNER JOIN 
    (
     SELECT Table1.primaryKey 
     , (Table1.column3 + Table1.column4) AS c1 
     FROM Table1 
    ) AS c1 
ON Table2.foreignKey = fakeTable.primaryKey 

Могу ли я не разрешается ссылаться на ключи, как будто они являются столбцами?

+3

Какая Ваша ошибка? –

+1

В инструкции есть только одна ссылка на 'fakeTable', так что это один из источников ошибки. Вы хотели написать 'AS fakeTable' или' SET column1 = c1.c1'? –

+0

SQL Server 2008. Хорошая уловка по отсутствующей ссылке на fakeTable в инструкции ON. К сожалению, это не исправить. Я думаю, мне нужно на самом деле ссылаться на столбцы, составляющие ключи. Я думал, что все дело в ключах, чтобы избежать необходимости конкатенации столбцов! – eek142

ответ

4

Нет, вам нужно перечислить все поля отдельно. Но вы можете избежать подзапрос, что у вас есть ...

UPDATE 
    Table2 
SET 
    column1 = Table1.column3 + Table1.column4 
FROM 
    Table2 
INNER JOIN 
    Table1 
    ON Table2.foreignKey1 = Table1.primaryKey1 
    AND Table2.foreignKey2 = Table1.primaryKey2 
    AND Table2.foreignKey3 = Table1.primaryKey3 
    AND Table2.foreignKey4 = Table1.primaryKey4 

EDIT

ответ на комментарий:
- I thought the whole point of keys was to avoid having to concatenate columns!

Ключи не экономия времени устройства, они это устройства для защиты данных.

Первичный ключ - это уникальный идентификатор. Я могу быть составным или нет, но важно то, что он уникален и не имеет значения NULL.

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

+1

+1 Для указания того, что подзапрос, вероятно, не нужен ... –

+0

Это сработало! Спасибо. Я знал, что это слишком сильно. Должен ли я создать новый столбец в каждой таблице, который является конкатенацией столбцов, которые я использовал для создания ключей? Это поможет избежать всех проверок И. – eek142

+3

@eek - В общем, 'НЕТ'. Если отдельные поля означают что-то индивидуально, придерживайтесь, как и вы. Набивание нескольких элементов в одно и то же поле - это анти-шаблон SQL и часто вызывает больше проблем в будущем, чем того стоит. Самый близкий подход, который я бы отстаивал, - это иметь другой столбец IDENTITY в таблице 1 и внешний ключ к этому. Вы можете * по-прежнему * поместить уникальный ключ в 4 идентифицирующих поля. Это называется суррогатным ключом (другой ключ вместо сложного ключа). – MatBailie

2

Нет, вы не можете ссылаться на ключи, как на столбцы. Вам нужно будет указать все столбцы как в PK, так и в FK ... как в вашем суб select, так и в вашем joinon.

+0

Вы рекомендуете конкатенацию столбцов, чтобы мне не приходилось перечислять столько операторов И? – eek142

+1

@ eek142 Я бы не рекомендовал это ... вместо этого я предпочел бы предложение Dems для столбца «IDENTITY». –