形势:
varchar(20)
似乎在Teradataand而不是中截断了悄无声息的,以便在遇到超过20个字符长的字符串时展开或抱怨。这有点令人惊讶,因为我预计,要么是自动展开列以适应较大的字符串,比如30个字符,要么是在遇到较大字符串时抛出错误。沉默的截断似乎让我陷入了最糟糕的世界..。
并发症:
对于我的应用程序(原型分析设计),我不知道我将在几个星期的过程中摄取的数据有多大。这似乎排除了使用varchar(N),但最大值除外
问题:
所以现在我有几个选择,并寻求一些指导:
Q1。用户错误?我是否误解了varchar(N)
的一个关键概念?
如果Teradata实际上就是这样处理varchar
字段的,那么
Q2。为什么会有人指定小于varchar(max)
的内容,特别是在预先不清楚需要在字段中存储多少个字符时。
Q3。是否存在允许灵活调整字符串大小的不同数据类型--即真正的可变长度字符串?
如果我还记得,其他SQL方言将varchar(n)
作为字符串的推荐初始大小实现,但允许它根据需要展开以适应抛出的数据字符串的最大长度。Teradata中是否有类似的数据类型?
(注意:由于我正在对表进行原型化,此时我不太关心性能效率,而更关心的是快速但安全的设计,从而使原型得以进步。)
发布于 2012-08-22 18:27:23
我不熟悉任何实现varchar(n)的SQL方言,它的行为与您建议的一样--推荐的初始大小然后让它增长。这将适用于Oracle、Server、MySQL和Postgres。在所有这些数据库中,varchar(n)的行为就像在具有显式强制转换的SELECT语句中的Teradata中所看到的那样。当较长的字符串被放入较短的字符串中时,我不认为有任何原因会导致截断错误。
正如布兰科在他的评论中所指出的,在数据修改步骤中,这种行为是不同的,在这些步骤中,隐式强制转换确实会导致错误。
我不太熟悉Teradata的所有细节。在Server中,varchar(max)和varchar(8000)历来有很大的区别。前者将在单独的数据页上分配,后者将在与数据相同的页面上分配。(这些规则在最近的版本中进行了修改,以便varchars可以从数据页面中溢出。)
换句话说,在使用varchar(max)时可能还有其他考虑因素,包括数据如何存储在页面上,索引是如何构建在页面上的,以及其他考虑因素。
我的建议是,您选择一个相当大的大小,比如说1000左右,然后让应用程序从那里继续。如果您想要真正的灵活性,那么使用varchar(max)。您还应该通过Teradata和/或技术联系人了解声明非常大的字符串存在哪些问题。
发布于 2015-06-30 09:12:48
Teradata的工作模式有两种: Teradata (BT;..)和ANSI(commit;)它们有一个差异列表,其中一个是您在开发过程中遇到的-- Teradata模式允许截断显示数据。相反,ANSI禁止这种截断,因此,您将看到一个错误。为了达到这个目的,只需使用简单的示例:创建表check_exec_mode (str (5));从check_exec_mode中选择*;插入check_exec_mode值('123456');如果您在TMODE(事务模式)=transaction中配置teradata的连接,那么您将得到表中截断的行('12345')。将事务模式更改为ANSI并执行insert语句,将导致“字符串数据的右截断”错误。
https://stackoverflow.com/questions/12083089
复制相似问题