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