我有一个SE11表，其中列为STRING，我想知道它是如何存储在底层数据库系统上的（本例中为SAP Hana）。
我读到只有对LOB的引用实际上保存在类型为STRING的列中，并且字符串本身保存在表外。这是真的，它在Hana上是否也一样？我尝试过RTFM，但我找不到这些信息。
通常建议尽可能使用具有特定长度的CHAR吗？
答案 0 :(得分：1)
免责声明。虽然我在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可以从system view "SYS"."M_TABLE_LOB_FILES"收集。相关的system view "SYS"."M_TABLE_LOB_STATISTICS"为您提供了有关消耗空间的更多详细信息。
A（相当）最近的blog on hybrid LOBs揭示了另一个有趣的事实：“因为SAP HANA不会压缩LOB列，无论它是驻留在磁盘还是内存中[...]” 。这意味着该列将占用与您放入的内容完全相同的磁盘空间。这与SAP HANA的其他列存储内容完全不同，后者大量提交压缩以优化存储和访问。得出的结论也值得注意：“[...]在数据库”的写入/读取时，应用层应用任何可能的压缩算法逻辑（例如gzip）是至关重要的。
一般而言 - 对于我所知道的所有数据库管理系统都是如此 - 优先选择变量字符类型是一个好主意，因为它们可以让系统自由地优化实际预留的空间。因此，SAP's guidelines discourage using VARCHAR (= non-Unicode) for anything other than pure ASCII，SAP HANA的合理默认值应为NVARCHAR（=支持Unicode）。