Первичный ключ при хранении большого количества данных в течение короткого периода времени - PullRequest
Новая
       10

Первичный ключ при хранении большого количества данных в течение короткого периода времени

1 голос
/ 25 августа 2009

У меня есть сомнения относительно того, как создать таблицу для временного хранения сообщений об ошибках.

  1. Много вставок и удалений
  2. GUID в качестве внешнего ключа, который, вероятно, будет оставлен внешним подключенным
  3. Простое поле nvarchar для ErrorMessage

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

Спасибо

Ответы [ 2 ]

2 голосов
/ 25 августа 2009

Я бы не согласился с Джеем - посмотрите Ким Трипп Дебаты по кластерным индексам продолжаются .

Помимо прочего, она говорит, что наличие хорошего первичного / кластерного ключа (в столбце INT IDENTITY - NOT GUID) фактически ускорит вставку и удаление.

Таким образом, даже если вы используете вашу таблицу только в течение короткого периода времени, было бы целесообразно иметь столбец TableID INT IDENTITY(1,1) PRIMARY KEY, чтобы получить хороший, быстрый первичный ключ и кластеризованный индекс, и как можно меньше других индексов (поскольку это наверняка замедлит вставки).

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

Если вы загружаете много данных (например, десять тысяч строк одновременно), вы также можете подумать об отбрасывании этого индекса перед загрузкой и воссоздании его после загрузки данных (что, вероятно, приведет к Быть быстрее, чем иметь его постоянно), но опять же: это зависит от объема загружаемых данных и от того, как часто.

Марк

0 голосов
/ 25 августа 2009

Я бы поместил индекс в поле внешнего идентификатора GUID, потому что вы будете искать ошибки на основе этого. Что касается первичного ключа. Вы не упомянули требование, которое вызывает потребность в первичном ключе. И это просто добавит некоторые дополнительные издержки. Однако вам, вероятно, потребуется выполнить сортировку, и для этого вам понадобится числовое поле или поле даты. Я предлагаю просто добавить числовое поле в таблицу, чтобы вы могли сортировать на основе сообщений об ошибках заказа были созданы. Но вам, вероятно, не нужно делать это поле основным, так как данные не сохраняются долго.

...