ОЧЕНЬ огромная База данных SQL: Как схема должна быть похожей?

Чтобы ответить на ваш вопрос о необходимости первичного ключа - используя только информацию, которую вы указали в вопросе:

На основе схемы вашей таблицы вы также можете оставить его там. Если вы удалите этот столбец идентификаторов, вы также удалите свой кластерный индекс. Значение кластеризованного индекса (4 байта) сохраняется как указатель в каждой строке некластеризованного индекса. Удалив этот кластерный индекс, вы оставите таблицу в виде кучи, а SQL создаст 8-байтовый RID (идентификатор строки) для каждой строки в таблице и вместо этого будет использовать его в качестве указателя в некластеризованном индексе. Итак, в вашем случае, основываясь на схеме, которую вы указали в вопросе, вы потенциально можете УВЕЛИЧИТЬ размер своих некластеризованных индексов и, в конце концов, замедлить их.

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

Вы должны решить для каждого столбца, предлагает ли индекс повышение производительности для ваших запросов, и если это гарантирует влияние на производительность вставки / обновления и использование дискового пространства.

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

Что ж, вы можете разбить таблицу на более мелкие, если, например, hs (X) и ppot (X) должны вырасти выше девяти.

Вот что у вас есть:

[hand_id] [int] IDENTITY(1,1) NOT NULL,
    [flop_index] [smallint] NULL,
    [hand_index] [smallint] NULL,
    [hs1] [real] NULL,
    [ppot1] [real] NULL,
    etc...

Вы можете разбить его на 2 таблицы (может быть, на 3, если вам нужно)

Table hand: (EXAMPLE)
[hand_id] [int] IDENTITY(1,1) NOT NULL,
    [flop_index] [smallint] NULL,
    [hand_index] [smallint] NULL


Table hs_ppot (EXAMPLE)
[hand_id] [int] IDENTITY(1,1) NOT NULL,
[hs] [real] NULL,
    [ppot] [real] NULL

Затем вы можете ссылаться на hand_id в каждой таблице.

Кстати, что такое hs и ppot?

От того, как вы делаете свои индексы и примкей, зависит. Если вы просто хотите проанализировать данные и уверены, что последующие команды DML будут только SELECT (без INSERT), тогда удаление PK должно быть нормальным. Фактически, столбец hand_id является столбцом IDENTITY (автоинкремент), что означает, что SQL Server все равно управляет этим значением (фактически, вы не можете вставлять значения в этот столбец, не создавая дополнительных проблем с переключением режима IDENTITY_INSERT до того, как начало ваших операторов INSERT, IIRC).

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

Если в будущем возникнет необходимость в интеллектуальном анализе данных, рассмотрите возможность использования Microsoft SSAS (Analysis Services).

ОБНОВЛЕНИЕ: прочитав ответ Майо, я согласен с тем, что индексы (чисто для скорости, не принудительное применение ограничений) рекомендуется для последующих запросов (напомним, что индексы ускоряют операции чтения, но обычно заставляют вставки / обновления занимать больше времени). Поскольку ваша цель - выполнить одну массовую вставку с последующими запросами SELECT, вы можете выполнить массовую вставку, а затем добавить необходимые индексы в свою базу данных по столбцам, которые являются вероятными кандидатами в ваши запросы.

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

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

Если вы хотите составить таблицу для каждой возможной комбинации холдема, я бы сделал отдельные таблицы для pocketCards (pocketID, pCardID1, pCardID2), flopCards (flopID, fCardID1, fCardID2, fCardID3), а затем таблицу для TurnAndRiver ( turnAndRiverID, turnCardID, riverCardID). Затем таблица рук с (handID, pocketID, flopID, turnAndRiverID, handScore).

HandScore представляет собой вычисленное поле, вычисленное из таблицы или функции скалярного значения.

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

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

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

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

Обновление

В ответ на изменение OP: Похоже, вы используете неправильный инструмент для этой задачи. Какая польза от наличия данных в базе данных, если вы всегда собираетесь выбирать один и тот же набор записей? Изучите другие варианты (например, плоский XML-файл или статический DataSet в вашем коде). Это сэкономит вам время подключения и накладные расходы на запуск сервера для статических данных.