数据库在唯一列上搜索：长字符串还是许多 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 可能与处理器有关，所以这没什么大不了的。基本上，如果速度是我的第一要务（而不是存储），哪个更好......吐出 80 个字符串或将 20 个不同的 Int32 存储到数据库中并在这些列上搜索？

或者，是否有更好的东西，例如将对象序列化为二进制文件并以某种方式能够搜索匹配的 blob？我不是一个真正的数据库专家，所以我不知道。

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 中的每个页面可以容纳 8K * 1024 / 40 = 204 条记录。

对于每条记录 8 字节的 8 字节（Int64）数据，SQL Server 中的每个页面可以容纳 8K * 1024 / 8 = 1024 条记录。

如果您有 20000 条记录，则数据库需要 20000 / 204 = 99 个 I/O 来执行 FTS，而另一条记录则需要 20000 / 1024 = 20 个 I/O。

需要的 I/O 越少，获得的性能就越高。

Answer 2

枚举对此不太有用，如果您知道想要哪个索引号，只需访问那里的数据即可。另外，在 Foo[,] 之后，您应该指定变量名称，不能在那里使用枚举名称。

Answer 3

如果我正确理解你的问题，你想匹配数据库中 FooBar 的整个实例（或其二进制表示形式）？
5x4 网格 = 20 个项目，每个 2 位 = 40 位 = 5 个字节 => Int64 列。您无法更快地获得满足您要求的任何东西。