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

Question

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

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

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

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

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

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

ВАРИАНТ 1:

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

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

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

ТАК Вопрос Как обрабатывать неизвестный тип данных в одной таблице использует аналогичную идею.

ВАРИАНТ 2:

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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