Oracle 表结构答案

【问题标题】：Oracle Table structureOracle 表结构
【发布时间】：2013-02-22 00:59:08
【问题描述】：

我在 Oracle 数据库中有一个包含 60 列的表。以下是表结构。

ID  NAME TIMESTAMP PROERTY1 ...... PROPERTY60

这个表会有很多行。表的大小将以 GB 为单位。但是表结构的问题是，将来如果我必须添加一个新属性，我必须更改架构。为避免这种情况，我想将表结构更改为以下。

ID NAME TIMESTAMP PROPERTYNAME PROPERTYVALUE

将是一个示例行。

1  xyz  40560 PROPERTY1 34500

通过这种方式我将能够解决问题，但表格的大小会变大。在获取数据方面是否会对性能产生任何影响。我是甲骨文的新手。我需要你的建议。

【问题讨论】：

为什么必须更改架构才能将新的属性列添加到表中？
假设我将来要支持“PROPERTY61”，在这种情况下，如果我采用第一种方法，我必须更改架构。
这接近于名为 EAV Entity, Attribute, Value 的方案。由于各种原因，这通常是一个坏主意。这不会阻止人们使用它，但它变得非常难以查询，甚至更难以确保数据是自洽的。
ALTER TABLE ADD COLUMN ... 变化不大，对吧？如果程序员不使用SELECT *你以后应该没有问题。
当我说“重大更改”时，我指的是应用程序代码更改和升级工作。

标签： oracle database-design data-modeling

【解决方案1】：

如果我必须添加新属性，我必须更改架构

这真的有问题吗？在较新版本的 Oracle 中添加列已获得 cheaper 和 more convenient。

但是如果您仍然需要使系统动态化，从某种意义上说您不必为新属性执行 DDL，那么以下简单的EAV 实现可能是一个好的开始：

CREATE TABLE FOO (
    FOO_ID INT PRIMARY KEY
    -- Other fields...
);

CREATE TABLE FOO_PROPERTY (
    FOO_ID INT REFERENCES FOO (FOO_ID),
    NAME VARCHAR(50),
    VALUE VARCHAR(50) NOT NULL,
    CONSTRAINT FOO_PROPERTY_PK PRIMARY KEY (FOO_ID, NAME)
) ORGANIZATION INDEX;

注意ORGANIZATION INDEX：整个表只是一棵大B-Tree，根本没有表堆。属于同一个 FOO_ID 的属性在物理上存储得很近，因此检索已知 FOO_ID 的所有属性将很便宜（但不如所有属性都在同一行中时便宜）。

您可能还想考虑是否适合：

在 FOO_PROPERTY 中添加更多索引（例如，用于搜索属性名称或值）。请注意索引组织表中二级索引的额外成本。
切换 FOO_PROPERTY PK 中的列顺序 - 如果您主要搜索属性名称并且很少检索给定 FOO_ID 的所有属性。这也将使index compression 可行，因为索引的前沿现在是相对较宽的字符串（而不是窄整数）。
对 VALUE 使用不同的类型（例如RAW，甚至in-line BLOB/CLOB，这可能会影响性能，但也可能提供额外的灵活性）。或者，您甚至可以为每种可能的值类型创建一个单独的表，而不是将所有内容都填充到一个字符串中。
单独的属性“声明”到它自己的表。此表将有两个键：除了字符串 NAME，它还将具有整数 PROPERTY_ID，然后可以将其用作 FOO_PROPERTY 中的 FK 而不是 NAME（节省一些存储空间，但代价是更多的 JOIN）。

【讨论】：