sql-server - 你的 Nvarchar() 有多大

Question

在设计数据库时，在决定 nvarchar 应该有多大时，您会考虑哪些决定。

如果我要制作地址表，我的直觉反应是地址行 1 是 nvarchar(255)，就像旧的访问数据库一样。

我发现使用它让我对旧的“字符串将被截断”感到困扰。我知道可以通过限制输入框来防止这种情况，但如果用户确实有一个超过 255 的地址行，则应该允许这样做。

我应该使我的 nvarchar 多大（？？？？？？）

Answer 1

我的建议：让它们和你真正需要的一样大。

例如，对于邮政编码列，10-20 个字符就足够了。电话号码同上。电子邮件可能更长，50-100 个字符。姓名 - 好吧，我通常使用 50 个字符，名字也是如此。如果您真的需要，您可以随时轻松地扩展字段 - 这根本不是一项大工程。

使所有 varchar/nvarchar 字段尽可能大是没有意义的。毕竟，SQL Server 页面是固定的，并且限制为每行 8060 字节。拥有 10 个 NVARCHAR(4000) 字段只是自找麻烦......（因为如果你真的试图用太多数据填充它们，SQL Server 会向你吐槽）。

如果您真的需要一个非常大的字段，请使用 NVARCHAR/VARCHAR(MAX) - 只要它们适合，它们就会存储在您的页面中，如果它们变得太大，它们将被发送到“溢出”存储。

NVARCHAR vs. VARCHAR：这真的归结为你真的需要“外来”字符，比如日文、中文或其他非 ASCII 风格的字符吗？在欧洲，即使是一些东欧字符也不能再用 VARCHAR 字段表示（它们将被剥夺哈希（？拼写？）。西欧语言（英语、德语、法语等）都很好地服务于VARCHAR。

但是：NVARCHAR 确实使用了两倍的空间 - 在磁盘和 SQL Server 内存中 - 在任何时候。如果你真的需要它，你需要它——但你真的需要吗？：-） 由你决定。

马克

Answer 2

我个人不使用 nvarchar :-) 我总是使用 varchar。

但是，我倾向于使用 100 作为名称，使用 1000 作为评论。捕获和处理更长的字符串是客户端可以做的事情，比如通过正则表达式，所以 SQL 只获取它期望的数据。

您可以通过参数化调用来避免截断错误，例如通过存储过程。例如，如果参数定义为 varchar(200)，那么如果您发送 > 200，则截断会静默发生。截断错误仅针对 INSERT 或 UPDATE 语句引发：使用参数不会发生。

SQL Server 的 255“限制”回到 6.5，因为 vachar 被限制为 255。SQL Server 7.0 + 更改为 8000 并添加了对 unicode 的支持

编辑：

为什么我不使用 nvarchar：双倍内存占用、双倍索引大小、双倍磁盘大小，根本不需要它。我为一家在全球设有办事处的大型瑞士公司工作，所以我不会狭隘。

还在这里讨论：varchar vs nvarchar 性能

进一步思考，我建议 unicode 吸引客户开发人员，但作为开发人员 DBA，我专注于性能和效率......

Answer 3

这取决于该字段代表什么。如果我正在做一个快速原型，我会保留 255 的默认值。对于评论等任何内容，我可能会将其设置为 1000。

我真正缩小它的唯一方法是在我肯定知道大小、邮政编码或 NI 编号等的事情上。

Answer 4

对于您需要对其进行某些限制的列（例如名称、电子邮件、地址等），您应该设置一个相当高的最大长度。例如，超过 50 个字符的名字似乎有点可疑，超过该大小的输入可能包含的不仅仅是名字。但是对于数据库的初始设计，采用合理的大小并将其加倍。因此，对于名字，将其设置为 100（如果 100 是您的“合理大小”，则设置为 200）。然后将应用程序投入生产，让用户玩足够长的时间来收集数据，然后检查实际的max(len(FirstName)). 那里有任何可疑的值吗？超过50个字符？找出里面有什么，看看它是否真的是名字。如果不是，输入表单可能需要更好的解释/验证。

对评论做同样的事情；将它们设置为nvharchar(max)最初。然后在您的数据库增长到足以开始优化性能时回来。取评论的最大长度，将其加倍，您的专栏就有一个很好的最大长度。