Проектные решения таблицы для большого количества строк?
У меня есть приложение, которое отправляет данные на основе взаимодействия с пользователем (не ввод данных пользователем). Отправленными данными могло быть Целое число, Строка, Дата или булево значение. Существует 140 ключей. Мы можем добраться где угодно от 1 пары значения ключа до всех 140 за один раз.
Мы хотим сохранить, почти будет только использовать 20 из 140 ключей в рамках приложения. Остающееся будет использоваться для журнала аудита позже - таким образом, мы все еще должны будем сохранить их.
Эти данные используются приложением для решения, куда пользователь должен пойти так, это должно получить доступ к записи студенческим идентификатором и вытянуть эти приблизительно 20 опций в миллисекундах. Могли быть миллиарды строк данных (это - обновление существующего приложения с более чем 20 000 пользователей), таким образом, производительность очень важна. Пользователь генерирует новую строку каждый раз, когда они получают доступ к приложению.
ДАННЫЕ В КАЧЕСТВЕ ПРИМЕРА:
Score:1
ID:3212
IsLast:False
Action:Completed
У меня есть 2 идеи о том, как сделать это и ищущий некоторую справку, на которой является лучшим или третья опция лучший выбор.
ОПЦИЯ 1:
Моя первая идея состоит в том, чтобы использовать столбец для значения, поскольку строка затем имеет справочную таблицу возможных типов данных для использования, когда значение должно быть Брошено для использования.
value | dataType
-----------------------
"1" | int
"Completed" | string
В то время как отправляемые данные не являются пользователем, сгенерированным, я знаю, что должен быть глюк где-нибудь в этом методе. Единственная причина того, чтобы сделать это состоит в том, что мы не знаем то, какой key:pair будет отправлен (за пределами даты и идентификатора) и старающийся избегать больше, чем несколько столбцов.
ТАКИМ ОБРАЗОМ, Вопрос, Как Обработать Неизвестный Тип данных в одной Таблице, использует подобную идею.
ОПЦИЯ 2:
Другое решение состоит в том, чтобы иметь 140 столбцов - один для каждого ключа. Однако сгенерированный объем данных является очень большим (миллиарды строк) так, чтобы вызов этих данных не был достаточно быстр - я не думаю.
Технические детали: Это использует SQL Server 2008 - не R2 с DotNet C# и Reporting Services.
Я пропускаю что-то здесь - что лучший способ состоит в том, чтобы составить эту таблицу для производительности?
3 ответа
Сегментируйте данные по вертикали. Поместите 20 ключей, необходимых для управления навигацией, в одну таблицу, все 20 в одну строку, с PK, который идентифицирует взаимодействие с пользователем (скажем, Callit, InteractionId ). Поместите остальные 120 значений в другую таблицу с составным первичным ключом на основе PK первой таблицы ( InteractionId плюс KeyTypeId , определяющее, какое из 120 возможных пар значений ключа значение для. Сохраните все значения во второй таблице в виде строк. В третьей таблице поиска с именем, скажем, KeyTypes , сохраните KeyTypeId , KeyTypeName , и KeyValueDataType , чтобы ваш код знал, как преобразовать строковое значение для правильного вывода его в виде строки, даты и времени, целого числа, десятичного значения или чего-то еще ...
Первая таблица будет будут доступны гораздо чаще, и поэтому он содержит только те значения, к которым навигационная функция приложения нуждается в более частом доступе, делая строки более узкими, что позволяет больше строк на страницу и минимизирует дисковые операции ввода-вывода. количество строк меньше (~ 1/20 от большего), минимизируя глубину поиска индекса это нужно будет выполнять для каждого доступа.
Другая таблица со всеми остальными 120 парами "ключ-значение" будет использоваться не так часто, поэтому ее структуру, вероятно, можно оптимизировать для логической простоты, а не для производительности.
На самом деле, вы можете объединить предложения, предложенные до сих пор:
Создайте таблицу с 20 ключами, необходимыми для управления навигацией, плюс один столбец для первичного ключа, плюс один столбец, который является типом данных XML. для хранения остальных возможных данных. Затем вы можете создать DTD, который обрабатывает типы данных для каждого ключа, а также ограничения для определенных ключей по мере необходимости.
Проверить обе идеи достаточно просто, но вариант 1 кажется мне более предпочтительным. РСУБД типа SQL Server предпочитают длинные, узкие таблицы (т.е. меньше столбцов, но много строк).
Я не буду продолжать, потому что, похоже, Чарльз опередил меня, предложив вполне разумное предложение.