Отображение первичного ключа базы данных C # - String или int - PullRequest
2 голосов
/ 24 марта 2009

В наборе Northwind Starters первичные ключи из базы данных сопоставляются со строками в C #.

Это хорошая практика? И если да, то почему?

thx, Ливен Кардоен

ps: извините за возможно неправильный вопрос ...

В Northwind Starters Kit некоторые таблицы имеют автоинкрементный первичный ключ с типом данных int, а другие имеют неинкрементный первичный ключ с типом nchar (5). Почему это? Ну, очевидно, некоторые первичные ключи являются просто кодами (формат nchar (5)). Извините, что использовал ваше время.

Я думал, что тип данных int был сопоставлен со строкой C #, что мне показалось очень неправильным (но это не так).

Ответы [ 3 ]

4 голосов
/ 24 марта 2009

Все зависит от типа данных столбца в базе данных.

Хорошей практикой является использование совместимого / соответствующего типа данных. Если база данных использует int, используйте int. Если база данных использует uniqueidentifier, используйте Guid. Если база данных использует nvarchar, используйте строку.

Все остальное вызовет проблемы в будущем. Гарантированный.

3 голосов
/ 24 марта 2009

Для чистой эффективности лучше использовать Int в качестве первичного ключа просто благодаря поддержке сравнения Ints на уровне машинного кода. Строки сравниваются с использованием алгоритмов, реализованных на уровне базы данных. Если ваши строки не очень короткие, ключ Integer также займет меньше места на странице (страница БД).

Обновление : Судя по другому ответу на доске, я не уверен, правильно ли я понял ваш вопрос. Вы спрашиваете, лучше ли использовать Integer в качестве ключа по сравнению со строкой (где можно выбрать любой из них)? Или вы спрашиваете, должен ли ваш тип C # соответствовать вашему типу базы данных? Я предполагаю первое ... и был бы очень удивлен, если это второе - чей ответ, я думаю, очевиден.

Обновление : Ливен теперь уточнил свой запрос, чтобы сказать, что он на самом деле спрашивал, будет ли поле Int или nchar лучше в качестве индекса, поэтому мой первоначальный взгляд на этот вопрос был верным.

Чтобы добавить к моему ответу, Ливен, почти всегда лучше иметь Int в качестве ПК. Исключением является случай, когда существует естественный ключ, который может быть записан в виде короткой символьной строки (например, в системе учета, где записи "Item" являются символьными строками). Причины тройные.

Во-первых, целые числа представляются в виде машинного типа (32- или 64-разрядное слово) и обрабатываются с помощью машинно-машинных операций, тогда как строки не сравниваются, но должны сравниваться с использованием метода char-by-char. Так, например, при обходе индекса PK (обычно некоторого варианта BTree), чтобы найти запись, операция сравнения на каждом узле является отдельной операцией. Это огромная вещь? Вероятно, нет, если вы не работаете с действительно большой базой данных или транзакционной нагрузкой. Если у вас есть натуральный символьный ключ, то обязательно используйте его! Однако, если ваш «ключ» - это первые пять букв фамилии плюс первый инициал плюс число, чтобы сделать его уникальным, вам, очевидно, будет гораздо лучше с полем Int.

Во-вторых, целые числа просто занимают меньше места, чем почти любая клавиша char (кроме char (1) при условии использования Unicode). И это не только комната на главной странице таблицы, помните, что поля индекса также представлены в индексе. Опять же, это большое дело? Не совсем, если вы опять не работаете с огромной базой данных.

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

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

1 голос
/ 24 марта 2009

Всегда используйте соответствующий тип данных C # для типа данных Sql. Как отмечали другие авторы, делать что-то еще - значит, потом возникать проблемы.

Взгляните на эту статью: http://msdn.microsoft.com/en-us/library/ms131092.aspx для получения полного списка эквивалентов типов данных Sql Server / C #.

...