情况：
varchar(20)似乎在Teradata中 默默地截断 ，并且在遇到长度超过20个字符的字符串时 不会 扩展或抱怨…这有点令人惊讶，因为我希望自动扩展列以适应较大的字符串（例如30个字符），或者如果遇到较大的字符串，将引发一个错误。无声的截断似乎使我在所有世界中都变得最糟糕了。
varchar(20)
并发症：
对于我的应用程序（原型分析设计），我事先不知道我将在几周的时间内提取多少数据。这似乎排除了使用varchar（N），除了max
问题：
所以现在我有一些选择，并且正在寻找一些指导：
Q1。用户错误？我是否误解了一个关键概念varchar(N)？
varchar(N)
如果实际上这是Teradata处理varchar字段的方式，那么
varchar
Q2。为什么有人会指定比varchar(max)特别少的东西，尤其是在事先不清楚的情况下，可能需要在字段中存储多少个字符。
varchar(max)
Q3。是否存在允许灵活调整字符串大小的不同数据类型-即真正的 可变 长度字符串？
如果我还记得的话，其他SQL方言将实现varchar(n)为字符串的建议初始大小，但允许其根据需要扩展以适合所抛出的数据字符串的最大长度。Teradata中是否有类似的数据类型？
varchar(n)
（注意：由于我正在制作表格原型，因此我现在不太关心性能效率；更多地关注使原型得以发展的快速但安全的设计。）
我对实现varchar（n）的SQL方言并不熟悉，该行为的行为符合您的建议-建议使用初始大小，然后让其增长。这将适用于Oracle，SQL Server，MySQL和Postgres。在所有这些数据库中，varchar（n）的行为几乎与您在具有显式强制转换的SELECT语句中在Teradata中的行为一样。我不认为将较长的字符串放入较短的字符串会导致截断错误。
正如Branko在评论中指出的那样，行为在数据修改步骤中是不同的，其中隐式强制转换确实会导致错误。
我对Teradata的所有细节都不熟悉。在SQL Server中，从历史上看，varchar（max）和varchar（8000）之间存在很大的差异。前者将分配在单独的数据页面上，后者将与数据分配在同一页面上。（规则已在最新版本中进行了修改，因此varchars可能会溢出数据页面。）
换句话说，使用varchar（max）时可能还有其他考虑因素，包括数据如何存储在页面上，如何在页面上建立索引以及其他考虑因素。
我的建议是，您选择一个相当大的大小（例如1000左右），然后让应用程序从那里继续。如果要获得真正的灵活性，请使用varchar（max）。您还应该通过Teradata文档和/或技术联系来调查声明非常大的字符串存在的问题。
