在设计数据库时，在决定nvarchar的大小时，您会考虑哪些决定。
如果我要创建一个地址表，那么我的直觉反应是地址行1是nvarchar（255），就像旧的访问数据库一样。
我发现使用这个让我厌烦旧的'字符串会被截断'。我知道这可以通过限制输入框来防止，但如果用户确实有一个超过255的地址行，那么应该允许这样做。
我应该多大一点我的nvarchar（????）
答案 0 :(得分：3)
我个人不使用nvarchar :-)我总是使用varchar。
但是，我倾向于使用100作为名称，使用1000作为评论。陷阱和处理更长的字符串是客户端可以做的事情，比如通过正则表达式，因此SQL只获取它期望的数据。
您可以避免截断错误参数化调用，例如通过存储过程。 如果参数定义为varchar（200），比如说，如果你发送＆gt;那么截断就会静默发生。 200.仅对INSERT或UPDATE语句抛出截断错误：使用参数不会发生。
SQL Server的255“限制”回到6.5，因为vachar限制为255. SQL Server 7.0 +更改为8000并添加了对unicode的支持
编辑：
为什么我不使用nvarchar：双内存占用，双索引大小，双磁盘大小，根本不需要它。我在一家在全球设有办事处的大型瑞士公司工作，所以我不是狭隘的。
此处还讨论了：varchar vs nvarchar performance
进一步反思，我建议客户端开发人员使用unicode，但作为开发人员DBA，我会关注性能和效率......
答案 1 :(得分：3)
我的建议：让它们和你真正需要它们一样大。
E.g。对于邮政编码列，10-20个字符肯定就足够了。同上一个电话号码。电子邮件可能更长，50-100个字符。名字 - 嗯，我通常会得到50个字符，同名的名字。如果你真的需要，你可以随时轻松地扩展领域 - 这根本不是一件大事。
让所有varchar / nvarchar字段尽可能大都没有意义。毕竟，SQL Server页面是固定的，每行限制为8060字节。拥有10个NVARCHAR（4000）字段只是在寻找麻烦......（因为如果你真的试图用太多的数据填充它们，SQL Server会对你嗤之以鼻。）
如果您真的需要一个非常大的字段，请使用NVARCHAR / VARCHAR（MAX） - 这些存储在您的页面中，只要它们适合，并且如果它们太大则将被发送到“溢出”存储。
NVARCHAR与VARCHAR：这真的归结为你真的需要“异国情调”的角色，比如日语，中文或其他非ASCII风格的角色吗？在欧洲，甚至一些东欧角色也不能用VARCHAR字段代表（他们将被剥夺他们的hachek（？拼写？）。西欧语言（英语，德语，法语等）都得到了很好的服务。 VARCHAR。
但是：NVARCHAR确实在磁盘和SQL Server内存中使用了两倍的空间。如果你真的需要它，你需要它 - 但你真的？ :-)这取决于你。
马克
答案 2 :(得分：0)
这取决于该字段代表什么。如果我正在做一个快速原型，我会保留默认值255.对于任何类似注释等我可能会把它放到1000.
我唯一能让它变小的方法就是我肯定知道siez，邮政编码或NI编号等等。
答案 3 :(得分：0)
对于需要具有某些约束的列（如姓名，电子邮件，地址等），您应该设置相当高的最大长度。例如，超过50个字符的名字似乎有点可疑，超过该大小的输入可能包含更多只是名字的名字。但是对于数据库的初始设计，请采用合理的大小并将其加倍。因此对于名字，将其设置为100（如果100是“合理的大小”，则设置为200）。然后将应用程序投入生产，让用户玩耍足够长的时间来收集数据，然后检查实际的max(len(FirstName))。那里有任何可疑的价值观吗？超过50个字符？找出那里的内容，看看它是否真的是名字。如果不是，输入表格可能需要更好的解释/验证。
做同样的评论;最初将它们设置为nvharchar(max)。然后返回，当您的数据库增长到足以让您开始优化性能时。获取注释的最大长度，加倍，并且您的列具有良好的最大长度。