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个字节=＆gt; Int64专栏。你无法更快地满足你的要求。

数据库搜索唯一列：长字符串或许多int或long？

3 个答案: