Поиск в базе данных по уникальному столбцу: длинная строка или много int или long?

Question

Я не уверен, с какой базой данных я буду работать (более вероятно, с SQL Server Express), поэтому я не знаю, имеет ли это значение (или такая большая разница), чтобы иметь значение.

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

public class FooBar
{
    public GridItem[,]  Items { get; set; } //This is a 5x4 grid
}

public enum GridItem
{
    a = 0,
    b,
    c
}

Сначала я представлял каждый GridItem в виде двоичного файла из 2 символов (A =00, B = 01, C = 10 - я не думаю, что это утомило мое приложение так сильно, что строило строку из массива), что дало мне строку из 40 символов.Я могу найти эту строку в базе данных, чтобы соответствовать, но это заставило меня задуматься.Является ли более эффективным оставить каждый GridItem как Int32 (или Int64) и выполнить поиск в базе данных, чтобы убедиться, что все столбцы (GItem00, GItem01, ... GItem54) соответствуют их соответствующей строке / столбцу GridItem.Я думаю, что Int32 против Int64, вероятно, будет иметь отношение к процессору, так что это не так уж важно.В основном, если скорость - это мое беспокойство № 1 (не хранение), которое лучше ... выплюнуть строку из 80 символов или сохранить 20 различных Int32 в базу данных и выполнить поиск по этим столбцам?

Или есть что-то?даже лучше, например, сериализовать объект в двоичный файл и каким-то образом найти подходящий шарик?На самом деле я не специалист по базам данных, поэтому понятия не имею.

Answer 1

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

Когда система сохраняет данные в виде 40-байтовых символов и на них есть индекс, индекс будет настолько коротким, насколько этого хватит, чтобы различить точно запись данных. Например:

0101101.... => 010(3-byte index)
0111111.... => 011(3-byte index)

Иными словами, когда система сохраняет данные в виде 8-байтового (Int64) целого числа и в нем есть индекс, индекс должен составлять ровно 8 байт на запись.

В общей теории баз данных, чем меньше используется памяти, тем выше производительность запросов .

Если ваших данных достаточно для того, чтобы базе данных понадобилось все символы (40-байтовые символы) для индексации записи, размер индекса в некоторых записях будет 40-байтовым. И 8-байтовый целочисленный индекс, как объяснено, все еще остается в 8 байтах, однако данные растут.

В приведенной выше теории есть предварительное условие: сопоставляемые данные должны занимать лишь небольшую часть от всех.

Существует важный фактор, который необходимо учитывать при работе с индексами: вам нужно 20 индексов (логически), чтобы ускорить стратегию 20 Int32. Действительно, для стратегии из 80 символов и для отдельной стратегии Int64 необходим только один индекс.

---

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

Мы предполагаем, что 40-байтовые (символьные) данные сохраняются как 40 байт на запись, каждая страница в SQL Server может содержать 8 КБ * 1024/40 = 204 записи.

Для 8-байтовых (Int64) данных с 8 байтами на запись каждая страница в SQL Server может содержать 8K * 1024/8 = 1024 записи.

Если у вас есть 20000 записей, базе данных необходимо 20000/204 = 99 операций ввода-вывода для выполнения FTS и 20000/1024 = 20 операций ввода-вывода для другой.

Чем меньше требуется ввода-вывода, тем выше производительность.

Answer 2

Если я правильно понимаю ваш вопрос, вы хотите сопоставить целые экземпляры FooBar (или его двоичное представление) в базе данных? Сетка 5x4 = 20 элементов, 2 бита каждый = 40 бит = 5 байт => столбец Int64. Вы не можете получить что-то быстрее, удовлетворяя ваши требования.

Answer 3

Перечисления не очень полезны для этого, если вы знаете, какой индекс вы хотите, просто получите доступ к данным там.Также после Foo [,] вы должны указать имя переменной, вы не можете использовать имя перечисления там.