Дизайн таблицы базы данных для резервирования - PullRequest
0 голосов
/ 21 июня 2011

(с SQL Server 2008) У меня есть большая таблица (~ 50M записей), которая полностью нормализована.Существует 4 основных столбца, и в одном из них есть только три возможные записи - A, B и C. Проблема в том, что часто существует большая избыточность для этого столбца.То есть может быть много записей со значением A, а затем много повторяющихся записей, которые идентичны во всех отношениях, за исключением значения B (и / или C).Такое резервирование не всегда происходит, но достаточно часто, чтобы значительно увеличить количество записей, и я хочу от него избавиться.

Моя идея состоит в том, что вместо A, B, C можно выбирать столбец,Я думал о создании 3-битных столбцов с названиями A, B, C. Затем, в случае вышеупомянутых избыточностей для этих значений, мне не нужно создавать повторяющиеся записи, а вместо этого просто иметь одну запись и затем отмечать A,B и / или C столбцы по мере необходимости.

Это кажется неортодоксальным, поэтому я подумал, что увижу, что думают эксперты.Одна вещь состоит в том, что для этой таблицы будет три разных ограничения уникальности, каждое из которых включает в себя все остальные первичные ключи плюс один из трех столбцов флага.один из других PK - это столбец даты.Так, например, может быть 1000 записей разных дат с записью A, а затем еще 1000 записей с теми же датами (и другие идентичные столбцы), но с записью B. Таким образом, даже при наличии только трех вариантов все еще может быть многоизбыточности.

Ответы [ 5 ]

1 голос
/ 21 июня 2011

Вы не можете иметь «много повторяющихся записей, которые идентичны во всех отношениях», за исключением 4-го столбца в PK, который принимает один из A ИЛИ B или C. Это значит для меня, что у вас есть не более 3 строк (более остальные 3 столбца PK), дифференцированные либо по A, либо по B, либо по C

Это означает, что у вас должно быть одно уникальное ограничение из-за этого.

Я бы сделал ничего на основании этого, а также

  • строка с A - это другая строка с C
  • только 50 миллионов
  • все просто (без дополнительных таблиц или необычных битовых столбцов)
  • нет заявленных проблем с производительностью (пока вы не добавите дополнительные таблицы или необычные битовые столбцы)
  • у вас есть четкая нормализованная схема

Редактировать:

Ваша избыточность отсутствует в столбце ABC. Умножение строк вызвано datetime.

Можете ли вы изменить дату и время на smalldatetime и таким образом подавить почти дубликаты? например, разрешить с точностью до минуты не 3,33 миллисекунды? Или для SQL Server 2008 используйте datetime2 и выберите ваше разрешение

0 голосов
/ 21 июня 2011

Большинство баз данных в любом случае выделяет минимальное количество наиболее эффективных единиц обработки для каждого поля, поэтому их именование битовыми полями будет только разницей в метаданных.Но распаковка битов в слова в любом случае просто накладные расходы.Вы могли бы также использовать, вероятно, целые числа.И я почти уверен, что Sql Server не индексирует битовые поля - количество элементов 2 мало помогает.

50M записей?Небольшое число по большинству учетных записей.

Вы пытались количественно оценить накладные расходы, которые вы пытаетесь уменьшить?Если ничего другого, вы не собираетесь добавлять работу для увеличения сложности.

Я бы долго думал, прежде чем увеличивать сложность.

В противном случае это действительно стабильный дизайн, и выесть дополнительное время?

0 голосов
/ 21 июня 2011

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

Table1 (исходная таблица)
----------------------
PriKey1 (PK для Table1)
Col1
Col2

Table2 (новая таблица)
------------------
PriKey2 (ПК для таблицы 2)
PriKey1 (от FK до таблицы1)
A
B
C

0 голосов
/ 21 июня 2011

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

Битовые поля по своей природе не очень избирательны. Чтобы получить хорошую избирательность, вам нужно создать индекс покрытия для всех 3 полей, а затем включить все 3 в свои предложения WHERE, чтобы получить оптимальный поиск.

0 голосов
/ 21 июня 2011

Лично я бы так не поступил, я бы создал другую таблицу, в которой были бы A, B, or C и RecordID.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...