Варианты дизайна стола для большого количества строк?

Question

У меня есть приложение, которое отправляет данные на основе пользовательского взаимодействия (а не ввода пользователем). Отправленные данные могут быть целыми, строковыми, датскими или логическими значениями. Есть 140 ключей. Мы можем получить от одной ключевой пары значений всего 140 за раз.

Мы хотим хранить все, но будем использовать только 20 из 140 ключей в приложении. Оставшиеся будут использоваться для контрольного журнала позже - так что нам все равно нужно их хранить.

Эти данные используются приложением для определения того, куда должен идти пользователь, поэтому ему необходимо получить доступ к записи по идентификатору студента и вытащить 20 или около того параметров в миллисекундах. Могут быть миллиарды строк данных (это обновление существующего приложения с более чем 20 000 пользователей), поэтому производительность имеет решающее значение. Пользователь генерирует новую строку при каждом обращении к приложению.

ПРИМЕР ДАННЫЕ:

Score:1 
ID:3212 
IsLast:False 
Action:Completed 

У меня есть 2 идеи о том, как это сделать, и ищут некоторую помощь, на которых лучше всего или третий вариант является лучшим выбором.

ВАРИАНТ 1:

Моей первая идея состоит в том, чтобы использовать столбец для значения в виде строки, то есть справочная таблица возможных типов данных для использования, когда значение должно быть Cast для использования.

value  | dataType 
----------------------- 
"1"   | int 
"Completed" | string 

В то время как отправляемые данные не созданы пользователем, я знаю, что в этом методе должна быть какая-либо информация. Единственная причина для этого состоит в том, что мы не знаем, какой ключ: пара будет отправлена ​​(вне даты и id) и пытается избежать более нескольких столбцов.

В этом вопросе How to Handle Unknown Data Type in one Table использует аналогичную идею.

ВАРИАНТ 2:

Другое решение, чтобы иметь 140 столбцов - по одному для каждого ключа. Однако объем генерируемых данных очень велик (миллиарды строк), так что вызов этих данных будет не достаточно быстрым - я не думаю.

Технические данные: Использование SQL Server 2008 - не R2 с DotNet C# и службами Reporting Services.

Я что-то пропустил - как лучше всего создать эту таблицу для производительности?

Answer 1

Вертикально сегментируйте свои данные. Поместите 20 ключей, которые необходимы для навигационного управления в одной таблице, все 20 в одной строке, с ПК, которая идентифицирует пользовательское взаимодействие (Callit say, InteractionId). Поместите остальные 120 значений в другую таблицу с составным Первичным ключом, основанным на PK первой таблицы (InteractionId, плюс KeyTypeId, определяющий, какая из 120 возможных пар значений ключа это значение. Храните все значения в этой второй таблице как строки. В третьей таблице поиска, называемой, например, KeyTypes, сохраните KeyTypeId, KeyTypeName и KeyValueDataType, чтобы ваш код знал, как отличать строковое значение, чтобы выводить его правильно как строку, datetime, целое число или десятичное значение или что-то еще ...

Доступ к первой таблице будет выполняться гораздо чаще, и поэтому он содержит только те значения, для которых требуется более частый доступ к навигационной функциональности приложения, тем самым сужая ряды, что позволяет больше строк на странице и сводит к минимуму диск IO. Помещение всех 20 значений в одну строку будет содержать меньший счетчик строк (~ 1/20 по величине), минимизируя глубину индекса, который необходимо будет выполнить для каждого доступа.

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

Answer 2

Ну, это должно быть достаточно простым, чтобы протестировать обе идеи, но вариант на вариант 1 выглядит мне обособленным. РСУБД, такие как SQL Server, предпочитают длинные узкие таблицы (т. Е. Меньшее количество столбцов, но много строк).

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

Answer 3

На самом деле, вы могли бы объединить предложения предлагали до сих пор:

Создать таблицу с 20 ключами, необходимыми для навигационного контроля, плюс один столбец для первичного ключа, плюс один столбец, который представляет собой тип данных XML для хранения остальные возможные данные. Затем вы можете создать DTD, который обрабатывает типы данных для каждого ключа, а также ограничения на определенные клавиши по мере необходимости.