Первичный ключ SQL, INT или GUID или ..?

Есть ли причина, по которой я не должен использовать Integer в качестве первичного ключа для моих таблиц?Первичный ключ SQL, INT или GUID или ..?

База данных SQL-CE, две основные таблицы около 50 000 записей в год и несколько небольших таблиц. Только два подключения будут постоянно открываться в базе данных. Но обновления будут запускаться через несколько соединений сокетов TCP, поэтому будет много перекрестных потоков, которые будут обращаться к одному и тому же соединению с базой данных и использовать их. Хотя активность очень низкая, поэтому одновременные обновления весьма маловероятны, но могут произойти, может быть, пару раз в день максимум.

Возможно, будет использовать LINQ2SQL для DAL или типизированных наборов данных.

Не уверен, что если эта информация актуальна, но вот почему я спрашиваю, потому что я не знаю :)

источник

2010-12-29 bretddog

Вы также можете найти полезный вклад из этих популярных вопросов здесь: [Как вам ваши первичные ключи?] (Http://stackoverflow.com/questions/404040/how-do-you-like-your-primary -keys) [Неплохо ли использовать GUID в качестве первичных ключей в MS SQL?] (http://stackoverflow.com/questions/537145/is-it-a-bad-idea-to-use-guids-as -primary-keys-in-ms-sql) – DOK

Преимущество использования GUID primkey в том, что он должен быть уникальным в мире, например, переносить данные из одной базы данных в другую. Значит, вы знаете, что строка уникальна.

Но если речь идет о небольшом db, поэтому я предпочитаю целое число.

Edit:

Если вы используете SQL Server 2005 ++, вы можете также использовать NEWSEQUENTIALID(), это создает GUID, основанный на строке выше.Разрешить проблему с индексом newid() больше нет.

источник

2010-12-29 20:15:13 sv88erik

Это не полностью решает проблему индексирования только одной частью использования кластерного индекса. Он по-прежнему будет создавать индекс, который будет иметь проблемы с производительностью (и максимальный размер хранилища для всех индексов, поскольку они используют PK) по сравнению с int, поскольку он намного шире, лучше всего использовать только GUID, если вы знаете, что будете необходимо перенести данные в другую базу данных в будущем или использовать репликацию. – HLGEM

есть 16 байт против 4 байт, тогда ... 1 миллион записей будет чуть более 11MB – sv88erik

Спасибо! не знал о том, что GUID является «тем» уникальным, но это имеет смысл, и, следовательно, мне, очевидно, ничего не стоит беспокоиться. Он не выйдет из моего компьютера :) – bretddog

Вы должны использовать целое число - это меньше, значит меньше памяти, меньше И.О. (диск и сеть), меньше работы для подключения.

База данных должна обрабатывать проблемы параллелизма, независимо от типа ПК.

источник

2010-12-29 20:08:45 Oded

«Меньше работы, чтобы присоединиться к», что вы в нее вложили? Для вас или SQL Server? Когда жесткие коды Mon присоединяются? – sv88erik

@ sv88erik - меньше работы для сервера. – Oded

Есть ли причина, почему я не должен использовать Integer в качестве первичного ключа для моих таблиц?

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

источник

2010-12-29 20:09:29 kemiller2002

Можете ли вы предоставить доказательства для заявления о том, что guid's make в базе данных намного медленнее? –

Определенно использовать целое число, вы не хотите использовать GUID в кластерном индексе (PK), поскольку это приведет к ненужному фрагменту таблицы.

источник

2010-12-29 20:11:03

ПК не обязательно должны быть кластеризованными индексами – HLGEM

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

Имейте в виду несколько вещей:

Целое является родным размер слова для аппаратного обеспечения. Это примерно так же быстро и просто и легко на компьютере, как и тип данных.
Если вы, возможно, используете GUID, знаете, что они делают для ужасных первичных ключей. Реляционные базы данных вообще (я не могу говорить для всех, но MS SQL - хороший пример) не индексируют GUID хорошо. Там есть взломы, чтобы попытаться сделать больше идентификаторов GUID, ориентированных на индекс, взять их или оставить. Но, как правило, GUID следует избегать как ПК по соображениям производительности.

источник

2010-12-29 20:11:40 David

Это смешно, потому что я вижу, что Microsoft постоянно использует GUID для первичных ключей. Например, Microsoft CRM использует GUID для первичных ключей. Одно из преимуществ GUID заключается в том, что вам не нужно беспокоиться о секвенировании, и невозможно получить ключевое нарушение (если вы каким-либо образом не используете предыдущий ключ). –

@Mystere Man: Ну, это вряд ли когда-нибудь будет иметь ключевое нарушение :) Но ваш вопрос остается, и это то, что я никогда не понимал в отношении некоторых инструментов Microsoft. Их пример использования роли/роли поставщика для ASP.NET - общий пример. Что-то вроде этого может отлично работать для небольших проектов, где это не проблема, но она не будет масштабироваться. – David

Первичный ключ SQL, INT или GUID или ..?

ответ

Смежные вопросы