SQL Server выбирает первичный ключ из таблицы, где ключ содержит несколько столбцов

Я работаю над устаревшей базой данных. Я не могу изменить схему :( в нескольких таблицах первичный ключ использует несколько столбцов.

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

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

Теперь мне было интересно, есть ли более эффективный способ сделать это. Исходя из фона MySQL я не знаю ни одного, но думал, что SQL Server 2005 может иметь функцию

SELECT PRIMARYKEY() as pk, ...  FROM table WHERE ... 

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

Я искал и не мог ничего найти. Вероятно, я просто суетливый, но мне не нравится уловка конкатенации.

ОКРУГ КОЛУМБИЯ

10.11.2009 05:28:13
2 ОТВЕТА
РЕШЕНИЕ

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

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

1
10.11.2009 05:57:23
Я конкатенирую ключи при чтении, потому что это проще (в выражении sql, то есть: выберите col1 + col2 в качестве uid от blah). Затем я сохраняю полученную строку как уникальный идентификатор в веб-форме. при обновлении таблицы я сравниваю уникальный идентификатор с конкатенацией столбцов в операторе where, то есть: update blah, где col1 + col2 = uid. таким образом, конкатенация все выполняется в sql, и меньше шансов, что кто-то изменит порядок и нарушит его позже. по крайней мере, это теория. Причина, по которой он уродлив, состоит в том, что в первичном ключе 5 ints и один varchar.
DeveloperChris 10.11.2009 21:53:10

«В настоящее время я объединяю различные столбцы PK и сохраняю их как уникальный идентификатор, когда я помещаю данные обратно в таблицу». Разве вы не можете просто сохранить pk как два столбца в целевой таблице и использовать его для соединения с двумя столбцами в исходной таблице?

Какая польза от объединения дает вам здесь?

1
10.11.2009 05:32:06
Он, вероятно, использует это как ключ в некоторой структуре данных в своем языке программирования. Нет в базе данных.
idstam 10.11.2009 05:57:58
Это устаревшая база данных, которую мне дали, оригинальный дизайнер решил использовать несколько столбцов в качестве первичного ключа. Там нет второго стола. Я просто беру данные, представляю их пользователю и помещаю любые изменения обратно. к сожалению, я не могу изменить дизайн стола.
DeveloperChris 10.11.2009 21:45:00