SQL 原型(prototype)设计 : facing silent truncation of data using varchar(N) -- any better alternatives? (Teradata)

Question

情况:

varchar(20) 似乎在 Teradata 中静默截断并且在遇到长度超过 20 个字符的字符串时不展开或提示。 . 这有点令人惊讶，因为我预计要么自动扩展列以适应更大的字符串，比如 30 个字符，要么在遇到更大的字符串时抛出错误。无声截断似乎让我感到最糟糕......

并发症:

对于我的应用程序(原型(prototype)分析设计)，我事先不知道在几周内我将摄取的数据量有多大。这似乎排除了使用 varchar(N) 的可能性，除了 max

问题:

所以现在我有几个选择，并且正在寻找一些指导:

Q1。用户错误？我是否误解了关于 varchar(N) 的一个关键概念？

如果这实际上是 Teradata 处理 varchar 字段的方式，那么

Q2。为什么有人会指定小于 varchar(max) 的任何内容，尤其是当事先不清楚字段中可能需要存储多少个字符时。

Q3。是否有允许灵活调整字符串大小的不同数据类型——即真正的可变长度字符串？

如果我记得，其他 SQL 方言将 varchar(n) 实现为字符串的推荐初始大小，但允许它根据需要扩展以适应抛出的数据字符串的最大长度。是Teradata 中有类似的数据类型吗？

(注意:由于我正在对表进行原型(prototype)设计，所以此时我不太关心性能效率；更关心允许原型(prototype)进行的快速但安全的设计。)

Answer 1

我不熟悉任何实现 varchar(n) 的 SQL 方言，该 varchar(n) 的行为与您建议的一样——推荐的初始大小，然后让它增长。这适用于 Oracle、SQL Server、MySQL 和 Postgres。在所有这些数据库中，varchar(n) 的行为与您在 Teradata 中看到的带有显式转换的 SELECT 语句中的行为非常相似。当将较长的字符串放入较短的字符串时，我认为不会导致截断错误。

正如 Branko 在他的评论中指出的那样，行为在数据修改步骤中是不同的，其中隐式转换确实会导致错误。

我不熟悉 Teradata 的所有细节。在 SQL Server 中，varchar(max) 和 varchar(8000) 之间历来存在天壤之别。前者将分配在单独的数据页上，后者将分配在与数据相同的页面上。 (这些规则在较新的版本中已被修改，因此 varchars 可以溢出数据页。)

换句话说，在使用 varchar(max) 时可能还有其他考虑因素，包括数据如何存储在页面上、索引如何建立在页面上，以及可能还有其他考虑因素。

我的建议是您选择一个相当大的大小，比如 1000 左右，然后让应用程序从那里继续。如果您想要真正的灵 active ，请使用 varchar(max)。您还应该通过 Teradata 文档和/或技术联系人调查声明非常大的字符串的问题。