起初我是这么想的，但后来又想了想。这样做会影响性能，但同样地，它也可以作为一种文档形式来了解字段的实际大小。当数据库位于更大的生态系统中时，它确实会强制执行。在我看来，关键是要在合理的范围内宽容。

ok, here's my feelings simply on the issue of business and data layer logic. It depends, if your DB is a shared resource between systems that share business logic then of course it seems a natural place to enforce such logic, but its not the BEST way to do it, the BEST way is to provide an API, this allows the interaction to be tested and keeps business logic where it belongs, it keeps systems decoupled, it keeps your tiers within a system decoupled. If however your database is supposed to be serving only one application, then lets get AGILE in thinking, what's true now? design for now. If and when such access is needed, provide an API to that data.

显然，这只是理想情况，如果您正在使用现有系统，那么您可能需要至少在短期内以不同的方式进行操作。

如果一行中的所有数据(对于所有列)不会合理地占用8000或更少的字符，那么数据层的设计应该强制执行这一点。

数据库引擎可以更有效地将所有内容排除在blob存储之外。限制行越小越好。一页中可以塞进的行越多越好。当数据库必须访问更少的页面时，它的性能会更好。

当你知道字段将在一个固定的范围内时，这不是一个好主意——例如5到10个字符。我想我只会在不确定长度的情况下使用max。例如，电话号码永远不会超过一定数量的字符。

你能诚实地说，你不确定表中每个字段的大约长度要求吗?

我确实明白你的意思——有些字段我肯定会考虑使用varchar(max)。

有趣的是，MSDN文档总结得很好:

的大小时使用varchar 列数据条目变化很大。 的大小时使用varchar(max) 列数据条目变化很大， 大小可能超过8000字节。

关于这个问题有一个有趣的讨论。

如上所述，这主要是存储和性能之间的权衡。至少在大多数情况下是这样。

然而，在选择n/varchar(Max)而不是n/varchar(n)时，至少还有一个其他因素需要考虑。数据是否将被索引(例如，一个姓氏)?因为MAX定义被认为是LOB，所以任何定义为MAX的东西都不能用于索引。如果没有索引，在WHERE子句中涉及数据作为谓词的任何查找都将被迫进行全表扫描，这是您可以获得的数据查找的最差性能。

一个不使用max或文本字段的原因是，你不能执行在线索引重建，即REBUILD WITH online = ON，即使与SQL Server企业版。

这是一个公平的问题，他除了明显的……

缺点包括:

性能影响 查询优化器使用字段大小来确定最有效的执行计划

“1。数据库扩展和页面的空间分配是灵活的。因此，当使用update向字段添加信息时，如果新数据比之前插入的数据长，数据库就必须创建一个指针。这样，数据库文件将变得碎片化=从索引到删除、更新和插入，几乎所有方面的性能都较低。” http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx

集成影响——其他系统很难知道如何与您的数据库集成 不可预测的数据增长 可能的安全问题，例如占用所有磁盘空间可能导致系统崩溃

这里有一篇好文章: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html