Martin Asked: 2014-10-20 23:17:17 +0800 CST2014-10-20 23:17:17 +0800 CST 2014-10-20 23:17:17 +0800 CST 只有文本字段的数据库 772 我开始研究现有的 SQL Server 数据库系统，其中大部分字段都存储为文本。除了一些 ID，所有字段都是 varchar（电话号码、邮政编码、日期、地址、货币价值等）。 这不是我学习建立数据库的方式。问同事的时候说这样比较容易。将所有字段保留在 varchar 中是不好的做法吗？我怎么能争辩说它应该改变呢？ sql-server database-design 6 个回答 Voted Best Answer Michael Green 2014-10-21T01:47:56+08:002014-10-21T01:47:56+08:00 尺寸是一个考虑因素。Anint最多可以包含四个字节的 -2,147,483,648。Achar将需要 11 个字节来保存相同的值。 有内置函数来操作各种数据类型。 DATEADD()并且DATEDIFF()是两个例子。这对于日期存储为文本是不可能的。不断CAST地来回调用不会产生高效的处理或清晰的代码。 自动验证是全文本方法的另一个优势。您可能认为列包含日期，但没有什么可以阻止有人输入值“2014-13-97”。 对于“真正”数字的列，排序不太可能给出预期的结果。例如，如果一列包含整数“1”到“100”，并且查询按此列排序，则预期结果为 1, 2 .. 10, 11 .. 20, 21 .. 100 然而，实际结果更可能是 1, 10, 100, 11, 12, 2, 20, 21 ... 根据所选的字符表示，日期可能会有类似的问题。同样，类型铸造可以用前面提到的成本解决这个问题。 有时您会发现仅包含数字的字符串。例如国民身份证号码、银行帐号、电话号码等。这些值的共同特征是对它们执行计算没有意义。在其他条件相同的情况下，将它们存储为列可能char()没问题，尤其是当它们具有可选的嵌入字母字符时，但上述注意事项仍然适用。 Dan Guzman 2014-10-21T05:39:32+08:002014-10-21T05:39:32+08:00 您的同事是正确的，简单地不去想它并且将所有内容都存储为 varchar 会更容易。但这在空间要求、性能、查询数据的灵活性以及最重要的是缺乏数据完整性方面付出了巨大的代价。这不仅仅是一次性成本；它在应用程序的生命周期内重复支付。 我建议您遵循最佳实践并使用最适合所存储数据域的数据类型来存储数据，正如您所了解的那样。 Walter Mitty 2014-10-21T03:46:18+08:002014-10-21T03:46:18+08:00 在某些情况下，最好使用某种数字数据类型来表示数字。它的效率更高一些，但这仅仅是个开始。您可以使用 SQL 运算符获得对内置算术的支持，而无需在运行时执行类型转换。类型转换不仅会减慢速度，还会导致大量运行时错误，捕获这些错误需要额外的编程工作。 一般来说，在检索时发现错误的方式中过滤掉坏数据更值得。 区分数字（例如年薪）和数字字符串（例如电话号码）通常是值得的。在 VARCHAR 容器中存储数字字符串通常是一种很好的做法。 Neil McGuigan 2014-10-21T09:15:14+08:002014-10-21T09:15:14+08:00 邮政编码应该存储为文本，因为有些邮政编码以 0 开头（搞砸了格式/排序）并且没有理由对它们进行数学运算。此外，如果要存储全球邮政编码，它们通常包含字母。 电话号码可能用于文本，尤其是在可能有分机的情况下。或者您想存储 1-800-GOT-JUNK 之类的号码。没有理由对电话号码进行数学运算，因此文本可能没问题。 将日期和金额存储为文本是愚蠢的，并且允许无效值并阻止诸如加法和减法之类的操作。 一个包含所有文本字段的表的一个很好的理由是用于 CSV 导入，但这应该只是临时表。 Mohammad Shahnawaz 2014-10-21T00:00:32+08:002014-10-21T00:00:32+08:00 sql中有不同的数据类型来存储数据。如果所有数据都相同，则 varchar 适合存储。 但是以后需要对数据进行操作，功能有限不能。 最好与数据的数据类型一起使用。 jim paul 2016-03-13T08:41:30+08:002016-03-13T08:41:30+08:00 在我漫长的职业生涯中，我的大部分时间都花在了为复杂的业务系统编程的选择/多值数据库上。它们非常简单，我从未见过对这种类型的数据库来说太大或太复杂的业务。无论数据类型如何，记录都是制表符分隔文本的字符串。在编程语言中，文本被转换为日期、时间、数字或保留为文本。查询语言也识别这 4 种基本类型的数据。当我创建关系数据库时，我只使用 varchar、int、date 以及可能的 time 或 datetime。
尺寸是一个考虑因素。An
int最多可以包含四个字节的 -2,147,483,648。Achar将需要 11 个字节来保存相同的值。有内置函数来操作各种数据类型。
DATEADD()并且DATEDIFF()是两个例子。这对于日期存储为文本是不可能的。不断CAST地来回调用不会产生高效的处理或清晰的代码。自动验证是全文本方法的另一个优势。您可能认为列包含日期，但没有什么可以阻止有人输入值“2014-13-97”。
对于“真正”数字的列，排序不太可能给出预期的结果。例如，如果一列包含整数“1”到“100”，并且查询按此列排序，则预期结果为
然而，实际结果更可能是
根据所选的字符表示，日期可能会有类似的问题。同样，类型铸造可以用前面提到的成本解决这个问题。
有时您会发现仅包含数字的字符串。例如国民身份证号码、银行帐号、电话号码等。这些值的共同特征是对它们执行计算没有意义。在其他条件相同的情况下，将它们存储为列可能
char()没问题，尤其是当它们具有可选的嵌入字母字符时，但上述注意事项仍然适用。您的同事是正确的，简单地不去想它并且将所有内容都存储为 varchar 会更容易。但这在空间要求、性能、查询数据的灵活性以及最重要的是缺乏数据完整性方面付出了巨大的代价。这不仅仅是一次性成本；它在应用程序的生命周期内重复支付。
我建议您遵循最佳实践并使用最适合所存储数据域的数据类型来存储数据，正如您所了解的那样。
在某些情况下，最好使用某种数字数据类型来表示数字。它的效率更高一些，但这仅仅是个开始。您可以使用 SQL 运算符获得对内置算术的支持，而无需在运行时执行类型转换。类型转换不仅会减慢速度，还会导致大量运行时错误，捕获这些错误需要额外的编程工作。
一般来说，在检索时发现错误的方式中过滤掉坏数据更值得。
区分数字（例如年薪）和数字字符串（例如电话号码）通常是值得的。在 VARCHAR 容器中存储数字字符串通常是一种很好的做法。
邮政编码应该存储为文本，因为有些邮政编码以 0 开头（搞砸了格式/排序）并且没有理由对它们进行数学运算。此外，如果要存储全球邮政编码，它们通常包含字母。
电话号码可能用于文本，尤其是在可能有分机的情况下。或者您想存储 1-800-GOT-JUNK 之类的号码。没有理由对电话号码进行数学运算，因此文本可能没问题。
将日期和金额存储为文本是愚蠢的，并且允许无效值并阻止诸如加法和减法之类的操作。
一个包含所有文本字段的表的一个很好的理由是用于 CSV 导入，但这应该只是临时表。
sql中有不同的数据类型来存储数据。如果所有数据都相同，则 varchar 适合存储。
但是以后需要对数据进行操作，功能有限不能。
最好与数据的数据类型一起使用。
在我漫长的职业生涯中，我的大部分时间都花在了为复杂的业务系统编程的选择/多值数据库上。它们非常简单，我从未见过对这种类型的数据库来说太大或太复杂的业务。无论数据类型如何，记录都是制表符分隔文本的字符串。在编程语言中，文本被转换为日期、时间、数字或保留为文本。查询语言也识别这 4 种基本类型的数据。当我创建关系数据库时，我只使用 varchar、int、date 以及可能的 time 或 datetime。