字典 table 列中的字符串类型
String type in dictionary table column
我有一个 SE11 table，其中有一列类型为 STRING，我想知道它是如何存储在底层数据库系统（在本例中为 SAP Hana）的。
我读到只有对 LOB 的引用实际上保存在类型为 STRING 的列中，而字符串本身保存在 table 之外。这是真的吗？在 Hana 上也一样吗？我尝试使用 RTFM，但找不到该信息。
通常建议尽可能使用特定长度的 CHAR 吗？
Disclaimer. Although I work for SAP SE, I am not related to SAP HANA's teams or code. The info below was collected by trial and error in an SAP HANA 2 SP02 (2.00.024.00.1519806017). It is neither dependable, nor legally binding, and may be subject to future change without notice.
好了，说完了，我们来看一些东西：
SAP HANA 有一个列存储（= 奇特的新事物）和一个行存储（= 从其他关系数据库中得知）。两者 非常 不同。因此，在优化您的结构时，您应该了解您正在处理的商店。
ABAP DDIC 将透明 table 中的 STRING 列变为 NCLOB 列，并将 CHAR 变为 NVARCHAR。
ABAP DDIC 对于字符串非常特殊：它们不能用作键，因为它们超过了 255 个字符的最大键长度。它们还可以防止应用程序服务器缓冲 table，从而增加重复查询的响应时间。仅此一项通常就是避免使用 STRING 并使用 CHAR 的原因。总之，可以说将多个 STRING 列添加到透明 table.
SAP HANA 确实将 LOB 存储在 table 之外，而 table 仅包含一个引用。内容的处理方式类似于文件。他们的 CONTAINER_ID 可以从 system view "SYS"."M_TABLE_LOB_FILES". The related system view "SYS"."M_TABLE_LOB_STATISTICS" 中收集到，为您提供有关消耗的 space.
（相当）最近的 blog on hybrid LOBs 揭示了另一个有趣的事实："As SAP HANA will not compress LOB columns regardless of whether it resides in disk or in-memory [...]"。这意味着列将消耗与您放入的内容一样多的磁盘 space。这与 SAP HANA 的列存储内容的其余部分完全不同，后者大量提交压缩以优化存储和访问。得出的结论也很有趣："[...] 任何可能的压缩算法逻辑（例如 gzip）都必须应用于来自数据库的 writing/reading 上的应用程序层"。 =51=].
通常 - 我知道的所有数据库管理系统都是如此 - 最好选择 variable 字符类型，因为它们赋予系统自由优化它实际保留的space。由于 SAP's guidelines discourage using VARCHAR (= non-Unicode) for anything other than pure ASCII，因此 SAP HANA 的合理默认值应该是 NVARCHAR (= Unicode-capable)'.
我有一个 SE11 table，其中有一列类型为 STRING，我想知道它是如何存储在底层数据库系统（在本例中为 SAP Hana）的。
我读到只有对 LOB 的引用实际上保存在类型为 STRING 的列中，而字符串本身保存在 table 之外。这是真的吗？在 Hana 上也一样吗？我尝试使用 RTFM，但找不到该信息。
通常建议尽可能使用特定长度的 CHAR 吗？
Disclaimer. Although I work for SAP SE, I am not related to SAP HANA's teams or code. The info below was collected by trial and error in an SAP HANA 2 SP02 (2.00.024.00.1519806017). It is neither dependable, nor legally binding, and may be subject to future change without notice.
好了，说完了，我们来看一些东西：
SAP HANA 有一个列存储（= 奇特的新事物）和一个行存储（= 从其他关系数据库中得知）。两者 非常 不同。因此，在优化您的结构时，您应该了解您正在处理的商店。
ABAP DDIC 将透明 table 中的
STRING列变为NCLOB列，并将CHAR变为NVARCHAR。ABAP DDIC 对于字符串非常特殊：它们不能用作键，因为它们超过了 255 个字符的最大键长度。它们还可以防止应用程序服务器缓冲 table，从而增加重复查询的响应时间。仅此一项通常就是避免使用
STRING并使用CHAR的原因。总之，可以说将多个STRING列添加到透明 table. 是没有意义的
SAP HANA 确实将 LOB 存储在 table 之外，而 table 仅包含一个引用。内容的处理方式类似于文件。他们的
CONTAINER_ID可以从 system view"SYS"."M_TABLE_LOB_FILES". The related system view"SYS"."M_TABLE_LOB_STATISTICS"中收集到，为您提供有关消耗的 space. 的更多详细信息
（相当）最近的 blog on hybrid LOBs 揭示了另一个有趣的事实："As SAP HANA will not compress LOB columns regardless of whether it resides in disk or in-memory [...]"。这意味着列将消耗与您放入的内容一样多的磁盘 space。这与 SAP HANA 的列存储内容的其余部分完全不同，后者大量提交压缩以优化存储和访问。得出的结论也很有趣："[...] 任何可能的压缩算法逻辑（例如 gzip）都必须应用于来自数据库的 writing/reading 上的应用程序层"。 =51=].
通常 - 我知道的所有数据库管理系统都是如此 - 最好选择 variable 字符类型，因为它们赋予系统自由优化它实际保留的space。由于 SAP's guidelines discourage using
VARCHAR(= non-Unicode) for anything other than pure ASCII，因此 SAP HANA 的合理默认值应该是NVARCHAR(= Unicode-capable)'.