Oracle表结构

时间:2013-02-20 06:08:25

标签: oracle database-design data-modeling

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

ID  NAME TIMESTAMP PROERTY1 ...... PROPERTY60  

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

ID NAME TIMESTAMP PROPERTYNAME PROPERTYVALUE  

将是一个示例行。

1  xyz  40560 PROPERTY1 34500  

通过这种方式,我将能够解决问题,但桌子的大小会变得更大。在获取数据方面是否会对性能产生任何影响。我是Oracle的新手。我需要你的建议。

1 个答案:

答案 0 :(得分:1)

  

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

这实际上是个问题吗?在较新版本的Oracle中,添加列已获得cheapermore 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为代价节省一些存储空间)。