database - 什么时候应该使用 Oracle 的索引组织表？或者，我什么时候不应该这样做？

Question

索引组织表 (IOT) 是存储在索引结构中的表。而表存储堆中是无组织的，物联网中的数据按主键存储和排序(数据是索引)。 IOT 的行为就像“常规”表，您可以使用相同的 SQL 来访问它们。

适当的关系数据库中的每个表都应该有一个主键...如果我的数据库中的每个表都有一个主键，我应该始终使用索引组织表吗？

我猜答案是否定的，那么什么时候索引组织表不是最好的选择？

Answer 1

基本上，索引组织表是没有表的索引。我们可以在 USER_TABLES 中找到一个表对象，但它只是对基础索引的引用。索引结构与表的投影匹配。因此，如果您有一个表，其列由主键和至多一个其他列组成，那么您可能有一个 INDEX ORGANIZED 候选者。

索引组织表的主要用例是几乎总是通过其主键访问的表，我们总是希望检索其所有列。实际上，索引组织表最有可能是引用数据、代码查找事务。应用程序表几乎总是堆组织的。

语法允许 IOT 有多个非键列。有时这是正确的。但这也表明我们可能需要重新考虑我们的设计决策。当然，如果我们发现自己考虑在非主键列上需要额外的索引，那么我们可能最好使用常规堆表。因此，由于大多数表可能需要额外的索引，因此大多数表不适合 IOT。

---

回到这个答案，我看到该线程中的其他几个响应建议将交集表作为 IOT 的合适候选者。这似乎是合理的，因为交集表通常有一个与候选键匹配的投影:STUDENTS_CLASSES 可能只有 (STUDENT_ID, CLASS_ID) 的投影。

我不认为这是铸铁的。交叉表通常有一个技术键(即 STUDENT_CLASS_ID)。它们也可能有非键列(像 START_DATE、END_DATE 这样的元数据列很常见)。也没有普遍的访问路径——我们想找到所有类的学生，就像我们想找到一个学生正在上的所有类(class)一样——所以我们需要一个索引策略，它同样支持这两者。并不是说交集表不是 IOT 的用例。只是它们不会自动如此。