相关疑难解决方法(0)

假设在某个随机表中，您有一个名为status的列。它的实际值将是enabled或disabled。

此列的数据类型是 int/bool（1 或零）还是ENUM与值为enabledand一起使用更好disabled？有什么优点或缺点？

假设您有 4 个或 10 个甚至更多，而不仅仅是两个有效状态？随着所需值数量的增加，优势和劣势会向一侧倾斜还是向另一侧倾斜？

我无法确切地弄清楚如何为何时何地在数据库中使用查找表设置良好的边界。我看过的大多数资料都说我永远不会有太多，但在某些时候，似乎数据库会被分解成很多部分，虽然它可能是有效的，但它不再是可管理的。这是我正在使用的一个综合示例：

假设我有一个名为 Employees 的表：

ID  LName   FName   Gender  Position
1   Doe     John    Male    Manager
2   Doe     Jane    Female  Sales
3   Smith   John    Male    Sales

假设数据更复杂并且包含数百行。我看到可以移动到查找表的最明显的事情是位置。我可以创建一个名为 Positions 的表，并将 Positions 表中的外键粘贴到 Position 列中的 Employees 表中。

ID  Position
1   Manager
2   Sales

但是，在信息变得无法管理之前，我能在多大程度上继续将信息分解为更小的查找表？我可以创建一个性别表，并在单独的查找表中将 1 对应于男性，而 2 对应于女性。我什至可以将 LNames 和 FNames 放入表中。所有“John”条目都替换为指向 FName 表的外键 1，该表表示 ID 为 1 对应于 John。但是，如果您像这样深入这个兔子洞，那么您的 Employees 表就会变成一堆外键：

ID  LName   FName   Gender  Position
1   1       1       1       1
2   1       2       2       2
3   2       1       1       2

虽然这对于服务器处理来说可能更有效也可能不会更有效，但这对于可能试图维护它的普通人来说肯定是不可读的，并且使应用程序开发人员试图访问它变得更加困难。所以，我真正的问题是多远太远了？是否有此类事情的“最佳实践”或某处的一套好的指导方针？我在网上找不到任何信息可以为我遇到的这个特定问题确定一套好的、有用的指导方针。数据库设计对我来说是老生常谈了，但 GOOD …

表格或Type字段的最佳设计是什么？换句话说，鉴于此架构：intchar(1)

create table Car
(
    Name varchar(100) not null,
    Description varchar(100) not null,
    VehType .... not null
)

VehType成为 anint或 a是否更有效（在性能方面）char(1)？假设你有五种类型的汽车，你应该使用递增值 0 -> 4，还是类型的字符（比如；'v'、's'、'c'、't'、'm'）？

如果不止于此，我将使用单独的 Type 表并具有外键关系，但我认为没有必要这样做。

我注意到sys.objects目录视图为type字段使用了一个字符。有什么原因吗？我是否只是在稀薄的空气中抓住了它，这是我更舒服的吗？