我有一个列类型为STRING的SE11表，我想知道它是如何存储在底层DB系统(在本例中为SAP Hana)上的。
我读到只有对LOB的引用实际上保存在类型为STRING的列中，字符串本身保存在表外。这是真的吗?在Hana上也一样吗?我试着RTFM，但是我找不到那个信息。
是否在任何可能的情况下都建议使用特定长度的CHAR ?
免责声明。虽然我为SAP SE工作，但我与SAP HANA的团队或代码无关。下面的信息是在SAP HANA 2 SP02(2.00.024.00.1519806017)中通过试验和错误收集的。它既不可靠，也没有法律约束力，可能会在不通知的情况下发生变化。
好了，现在我们来看一些东西:
-
SAP HANA有一个列存储(=新奇的新事物)和一个行存储(=从其他关系数据库中知道)。两者非常不同。因此，在优化结构时，您应该了解正在处理的存储。
-
ABAP DDIC将透明表中的
STRING列变为NCLOB列，将CHAR列变为NVARCHAR列。 -
ABAP DDIC对于字符串非常特殊:它们不能用作密钥，因为它们超过了255个字符的最大密钥长度。它们还可以防止应用服务器缓冲表，从而增加重复查询的响应时间。这通常是避免使用
STRING而使用CHAR的原因。总而言之，在透明表中添加多个STRING列是没有意义的。 -
SAP HANA确实将LOB存储在表的外部，并且表只保存一个引用。内容的处理类似于文件。它们的
CONTAINER_ID可以从系统视图"SYS"."M_TABLE_LOB_FILES"中收集。相关的系统视图"SYS"."M_TABLE_LOB_STATISTICS"提供了有关已消耗空间的更多详细信息。 -
最近一篇关于混合LOB的博客揭示了另一个有趣的事实:"SAP HANA不会压缩LOB列，无论它是驻留在磁盘还是内存中[…]"。这意味着该列所消耗的磁盘空间与所放入的内容完全相同。这与SAP HANA的其他列存储内容完全不同，后者需要进行大量压缩以优化存储和访问。由此得出的结论也很有趣:"[…]在从数据库写入/读取时，在应用层应用任何可能的压缩算法逻辑(例如gzip)是至关重要的。
-
一般来说——对于我所知道的所有数据库管理系统都是如此——选择变量字符类型是个好主意，因为它们给了系统优化它实际保留的空间的自由。由于SAP的指导方针不鼓励使用
VARCHAR(=非unicode)用于纯ASCII以外的任何内容，因此SAP HANA的明智默认值应该是NVARCHAR(= Unicode-capable)'。