Question

我有一个存储小范围状态值的场景（N / 0 - 无访问，P / 1 - 部分，F / 2 - 完整，O / 3 - 其他）。 SQL Server中的正确字段类型是什么（与EF 6.x结合使用？

根据我的理解，这些选项中的每一个都有自己的优点和后退（尽管这不是一个完整的集合 - 可能有人可以添加以使其完整）。在更好的系统方面（具有性能和空间的平衡），正确的选择是什么。可能我们需要派生两个选项，一个用于具有几千个记录的表，另一个用于具有许多记录的表。

CHAR（1）：

(+) uses less space on DB

(-) costly while performing comparison if not default collation
(-) converted to string with EF and comparison takes a lot

TINYINT / SMALLINT

(+) uses less space on DB
(+) performs better in comparisons (in DB and code)

(-) when used with EF, explicit conversion needed in code
(-) may lead to confusions unless documented and understood clearly (the order)

内部

(+) uses default type system and no conversions required
(+) performs better in comparisons and indexes

(-) uses more space
(-) may lead to confusion

修改

对于Int类型，我尝试使用枚举来解决使用问题：

    public enum StatusValues
    {
        NoAccess = 0,
        Partial = 1,
        Full = 2,
        Other = 3
    }

    public StatusValues StatusValue
    {
        get { return (StatusValues)Status.Value; }
        set { Status = (int)value; }
    }

Answer 1

除非空间绝对溢价，否则通常您将始终使用对应于系统自动生成的主键类型的默认大小和类型。在SQL Server中，{{3}除非你在同一张表中处理超过20亿条记录。

如果您使用int，任何人都不会感到困惑。如果您决定使用查找表获取状态值，那么这将是他们期望的数据类型。

Answer 2

对我而言，这听起来像是在担心正确的数据类型。我怀疑无论你选择哪种方案，这都会对你的宏观方案产生切实的影响。

实体框架支持使用枚举，并且使用枚举可以指定基础类型（int16,32,64，byte等）。使用枚举将为您提供可读的代码，同时对空间友好。

由于您的数据在0到3的范围内，因此我建议选择基础大小为byte的枚举。

Answer 3

通常越小越好。但是你必须允许增长，所以16位int是最好的。还要考虑处理器中的字节对齐和总线宽度，而32或64位int可能会执行相同的操作。显然，较小的尺寸与SQL有所不同。我认为大多数用户习惯在EF中输入类型，因此这不应该是一个主要问题。使用枚举使代码更易读，文档更容易找到...对于每个枚举值N，P，O，F等，枚举默认为Int，所以使用它很容易理解

与EF一起使用时，INT与TinyInt对比SQL（1）

3 个答案: