"例如，我想使用相同的字段来存储服装尺寸（" S"，" XL" CHAR值）和CD格式（" DVD"，" BlueRay的CHAR值），如果我分别选择"纺织品"或"媒体"时可以读取为"服装尺寸数据元素名称"或" CD格式数据元素名称"。"

我要 在这里与您先行：您不是第一个想到_the_dynamic_approach的开发人员。 实际上，这个想法是通过各种修改（例如THE_ONE_TRUE_TABLE，KEY_VALUE_TABLE等）反复提出的。

所有这些方法都试图解决（甚至"解决"）感知到的问题 表定义是静态的，并且在运行时进行更改存在一些问题。 拥有一个可以适应任何特殊情况下"项目"的数据存储容器的想法似乎很聪明。 突然之间，应用程序可以"配置"要存储的项目类型，而无需开发人员进行任何交互。

在那里，就可以做到这一点。

长话短说：这对任何玩具数据都很棒。

在表述层中始终具有相同的单个SELECT语句和很少的配置处理确实很容易，以使数据库中的其他几个"共享"列有意义。

>

真正开始吸收的地方是存储实际数据量和种类的时间。

查询开始花费的时间越来越长，因为许多不同类型的数据存储在共享数据库中 列，索引和压缩都无法正常工作。

关于如何读取数据的越来越多的知识（这里的关键字是" schema-on-read"）最终出现在表示层中 的应用程序。 这意味着，对于每一个快速而肮脏的报告和查询，都需要通过它来推送数据，以便能够理解它。

一个人想要使用报告工具的时刻就是 然后需要在报告工具或报告模式中重建整个知识的那一刻。

那时，"可配置的读取模式"方法的简便灵活性就变成了围绕 开发人员的脚踝妨碍了对数据的高效，快速访问，

那么，对于表布局，我的建议是什么？

对于在表中具有许多列的HANA来说，这并不是一个问题 se。 一种方法可能是简单地将表中所有必需的属性放在自己的列中。 取决于围绕插入/更新事务的约束，这可能是一种足够合理的方法。

"项目"的每个子类型可以由同一张表和鲍勃的叔叔的不同投影来表示。

该方法甚至可以通过基于类型的分区和索引进行扩展。

另一种方法是对不同子类型表的经典突破。 当然，这里主要关注的是必需的附加联接操作。

显然，这里的论点是数据模型的"配置"现在不再具有灵活性。

那又如何呢：与其构建表示层来动态解释过于笼统的万能表，不如构建表示层，而是构建将数据写入映射到正确的功能。 列。 这样，表结构中的数据仍然包含获取任何给定对象的正确值所需的所有知识，并支持报告和第三方（即，下一个项目）数据访问。

我从事的项目遵循可配置的"读取模式"方法，并且必须在最后添加的项目阶段之一就是将"灵活"模式转变为表格， 每个类型的架构。 这导致了资源消耗，分析运行时间甚至数据加载时间的大量减少（由于可能的并行化程度更高）。

ps

"灵活表"实际上只能提供帮助 与必须在不先运行ALTER TABLE的情况下将新列添加到表的部分一起使用。 在所有情况下，生成的数据类型几乎都是错误的，并且表结构上没有自动"反射"功能，因此无法推断出哪些列构成了项的一般类型。 我还没有为那些诚实的人找到一个很好的用例，并且相信这是HANA所添加的一项功能，可以帮助上游的单个SAP应用程序。

嗨，亲爱的罗伯特，

感谢您的询问。 我的问题是关于为部门特定目的开发新数据库，并且绝对是标准结构中不可或缺的一部分。 非常感谢。

此问题不适用于SAP HANA动态分层，它是SAP HANA的一种温暖的数据分层技术。

看来，ACDOCA数据表是SAP S/4 HANA Finance专用的表。 您是在问如何使用该表，还是在问如何优化自己的数据库模式的设计？

嗨，亲爱的拉尔斯，

非常感谢重播。 您的话本身就很有意义，但如果是您的经验所致，那么您的话就更有意义了。

祝您新年快乐！