Лучший формат первичного ключа для большой таблицы

Question

Я разрабатываю приложение asp.net, в котором есть потенциально большие таблицы данных. Я хотел бы знать, что было бы лучшим способом определить первичный ключ. Я знаю, что это было задано раньше, но поскольку это для конкретной ситуации, я думаю, что вопрос действительно.

Я использую Entity Framework 4 в базе данных SQL Server 2008.

Каковы возможности для определения первичного ключа, принимая во внимание следующее:

1. Существует реальная возможность того, что с течением времени количество записей превысит 32 битную границу, поэтому автоматическое приращение целочисленное будет не возможно.
2. Невозможно определить первичный ключ в комбинации других столбцов в таблице.
3. Для обеспечения синхронизации данных идентификатор, созданный приложением, был бы предпочтительнее, чем идентификатор базы данных. Кроме того, в EF это означало бы дополнительный переход к базе данных для получения вновь созданного идентификатора.
4. Для производительности вставки предпочтительным будет последовательный ключ.
5. Я рассматриваю требования к пространству для (последовательного) направления вниз.
6. Для строковых идентификаторов предпочтительной является нечувствительность к регистру.

Я уже разработал собственный алгоритм, который генерирует часть datetime и случайную часть, преобразованную в шестнадцатеричное строковое представление. Это оставляет меня чуть короче, чем руководство. Я все еще мог преобразовать его в base64, но это будет идти против элемента nr 6.

Спасибо за ваши предложения.

Answer 1

Возможно, вы сохранили свой ключ как BIGINT (8-байтовое целое число).

BIGINT работает точно так же, как INT, и может использоваться в автоинкрементном столбце идентичности таким же образом.

Answer 2

Я бы использовал последовательный GUID в вашем случае.

• это суррогатный ключ
• это приложение генерируется, поэтому нет необходимости, чтобы получить базу данных не генерируется идентификатор после вставки
• он является последовательным и хорошо работать с кластерными индексами
• , если вы можете переполнить 32-битные ключи вам, вероятно, придется использовать в любом случае 64-битные ключи (кроме того, вам удастся создать и использовать 48-битные ключи или что-то в этом роде), то для 128-битных GUID требуется всего лишь дважды пространство
• строки-суррогатные ключи для меня несколько неестественны и я не вижу никаких преимуществ по ключам GUID

Answer 3

Вот пара мыслей.

• Учитывайте тип данных binary размером 5 или 6 байт.
• Не упускайте из виду преимущества partitioned tables, особенно для больших столов.
• Сохраните оставшиеся столбцы как можно меньше.Иногда это может помочь star schema.

К сожалению, вы не можете создавать столбцы идентификации двоичных данных. Но вы можете использовать стратегию вставки max(Id)+1. Я не знаком с инфраструктурой сущности .NET, но должен быть способ получить ключ в той же поездке. В прошлом я видел документацию, объясняющую, как сопоставлять объекты с хранимыми процедурами и извлекать из них ключи, но у меня нет каких-либо особенностей.