使用这么多varchar字段有合理的理由吗？ （MS SQL DB）

Question

我正在从旧的基于IBM Universe的系统迁移到新的企业级数据信息管理系统，并在此过程中学习数据库设计。

我看了一下新系统的后端数据库结构（它是一个MS SQL DB，大约有100个表），并且发现一些非常奇怪的东西。但我不知道我的缺乏经验是否是我认为的原因，这只是标准做法，或者这些奇怪的事实只是糟糕的数据库/应用程序设计。

例如：

• 某些日期字段为varchar（20）
• 存储度量的字段为varchar（50），而不是像小数和枚举那样存储度量单位
• ISBN 10＆amp; 13个数字字段是varchar（50）
• 一些查找ID外键是varchar（100），即使实际的查找表主键是int
• 有些字段是varchar（0）
• 用于存储月份和附件的其他单独字段一年，每个都是varchar（250） - 我不知道什么样的设计决定一年最多需要250个字符，除非他们真的对他们的Y2K合规性过度，或决定使用秒自从Universe开始以存储日期时间

还有很多其他人。数据库看起来是一半以上的varchar字段。

我还应该提到数据库中的所有varchar字段实际上都是 n -varchar - 所以它都是unicode，甚至是只存储数字的字段。

在某些情况下，使用如此多的varchar字段可能是最佳选择吗？（灵活性......可能......？）< / p>

Answer 1

看起来很奇怪，但这实际上取决于数据的使用方式。使用varchar可能有很好的理由。如果不需要使用条件中的字段或执行计算，则使用varchar可以让用户更自由地执行他们想要的操作。

例如，在房地产中，房屋的价格似乎应该是数字。但是，许多代理商希望显示诸如“打电话定价”，“低价300”等短语（尽管我们为搜索保留了单独的数字价格字段）。

我建议查看这些字段是如何用来确定它们是否应该是varchar的。如果你看到很多从varchar到它应该是的类型的转换，那么varchar可能不是正确的选择。

Answer 2

  

某些日期字段为varchar（20）

这件事总会让你在将来遇到麻烦，现在你可以有无效的日期，然后就不能做正常的日期算术。

  

一些查找ID外键是   varchar（100），即使是实际的   查找表主键是int

这很糟糕，因为当你加入时你会得到转换，这会让它变得更慢

将小数存储为小数...迟早会得到不良数据然后它将成为GIGO（Garbage In Garbage Out）的经典案例

同样使用nvarchar来存储数字是疯了，你只需要将存储这些数字所需的存储量增加一倍，这样每页存储的行数就会减少，如果使用了常规的varchars，你需要更多的IO来恢复相同的行数或整数

Answer 3

其中一些显然是问题，尤其是“作为文本的日期”和“与其相关密钥的数据类型不匹配的外键”。

“ISBN 10＆amp; 13号码字段为varchar（50）”并不十分清晰。当然，它可以将它存储为BIGINT，但是使用CHAR（10）或CHAR（13）有一些好的参数:(即使它使用稍多的存储空间.Varchar（50）显然有点过分）< / p>

1. 您是否需要使用此数字进行数学运算？ （无）
2. 你会经常“漂亮地格式化”吗？ （00-0000-00-0或其他东西。它更容易对字符串执行格式化操作）
3. 您是否需要进行LIKE比较？转换（varchar（13），ISBN）LIKE'％123％'非常难看。

因此，根据具体使用方式的不同，我不会有使用CHAR的问题。实际上，如果大量的行没有ISBN（存储量减少），你可以说VARCHAR（13）会有意义。

Answer 4

不。如果是我的话，我会改变它。你知道是谁做出了这些决定吗？如果他们还在你身边，你可以问他们。