有问题的字符串是（烹饪）食谱的描述字段，最大长度应该是 99% 的用户永远不会遇到的。nvarchar(4000) 似乎限制太多了。
SQL 表中的一列甚至是合适的位置吗？在这样的字段中存储如此（可能）大的值感觉不合适，但也许不是？
不确定这是否重要，但 .NET 3.5 很可能会使用 LINQ2SQL。
编辑：使用 VS Express 数据库资源管理器创建表，它告诉我 4000 是 nvarchar 的最大大小（似乎没有将 varchar 列为选项）。这只是 SQLCE 的一个限制，并表明我必须研究其他东西吗？
如果这确实是 SQLCE 的限制，是否有人有其他建议？对于一个宠物项目，我必须是免费的，最好是易于设置（最好对我和最终用户来说，但更重要的是它易于为最终用户设置）。数据库将是本地的，并且性能不是太大的问题。
你对现有的食谱做过研究吗？varchar(4000) 会给你大约 400-500 个单词，我很确定在我拥有的许多食谱中没有多少食谱的描述比这更长。
VarBinary 将为您提供 8000 个字节，但如果您要使用 varbinary 在描述字段中进行任何搜索，则可能需要强制转换或其他会导致性能下降的操作。
最后，虽然我不是特别喜欢这样，但您可以将描述规范化到另一个表中，这将允许您设置一对多关系并使配方具有多个描述部分，您可以在界面中重新组合这些部分.
不一定推荐，但提供，因为他们突然想到：
如果文本在存储后很少更改，您可以考虑创建一个存储“行”文本的新表，例如：
recipe_id integer,
line_number integer,
line_text nvarchar(80)
或者，如果您不需要搜索食谱的文本，那么简单的压缩算法怎么样？霍夫曼编码在文本上相当有效，而且 CPU 密集度不高。
另一种方法是将文本保存为文件，数据库仅存储文件名。
ntext is your best bet as it can store half a million characters, if that's too small this could be combined with other solutions such as splitting up the row could be used.
https://technet.microsoft.com/en-us/library/ms172424.aspx
You should keep in mind that there's a max database size of 4GB with SQL compact, so migrating to a different database type might be preferable if you intend on storing a lot of these records.
大多数 SQL 数据库都足够聪明，可以自动为大型 VARCHARS 和 TEXT 列执行此操作。与其在创建行时为大列分配空间，不如以这样一种方式存储每一行的数据，以便它只占用比实际内容稍多的空间（而不是最大大小）。
我从未使用过 SQL CE，但看看它是否支持 VARCHAR(MAX) 数据大小。基本上，它在 800K 行大小限制范围之外存储大量文本（最多 2GB），但也允许您使用 '=' 和其他 WHERE 子句运算符（仅支持 LIKE 的 TEXT 数据类型）。