1

我想从这样的垂直数据库布局传输数据：

---------------------
| 身份证 | 类型 | 价值 |
---------------------
| 1 | 10 | 111 |
---------------------
| 1 | 14 | 222 |
---------------------
| 2 | 10 | 333 |
---------------------
| 2 | 25 | 第444章
---------------------

到水平的：

---------------------------------
| 身份证 | 10 型 | 14 型 | 25 型 |
---------------------------------
| 1 | 111 | 222 | |
---------------------------------
| 2 | 333 | | 第444章
---------------------------------

创建布局不是问题，但数据库相当大，有数百万个条目，如果花费太多时间，查询就会被取消。

如何有效地做到这一点（这样查询就不会被取消）。

4

3 回答 3

0

将其分解成更小的块，不要将整个事物包装在单个事务中。首先，创建表，然后将旧表中的分组插入到新表中。例如，按 ID 范围插入足够小的块，这样就不会压倒数据库的日志并花费太长时间。

于 2009-07-01T15:43:03.537 回答
0 
with t as
(
select 1 as ID, 10 as type, 111 as Value from dual
union
select 1, 14, 222 from dual
union
select 2, 10, 333 from dual
union
select 2, 25, 444 from dual
)
select ID,
max(case when type = 10 then Value else null end) as Type10,
max(case when type = 14 then Value else null end) as Type14,
max(case when type = 25 then Value else null end) as Type25
from t
group by id

返回您想要的，我认为这是更好的方法。注意 max 函数只是在这里执行 group by 子句，任何组函数都可以在这里使用（如 sum、min ...）

于 2009-07-01T15:46:04.107 回答
0

垂直表——也称为实体-属性-值反模式——总是成为一个问题，有时在它付诸实践后不久。如果您还没有这样做，请查看 Joe Celko 对这种策略的看法，您会看到更多证明这种方法有多麻烦的证据。我会停在那里，因为你是知道来这个网站的聪明人，而不是在你的数据库中实施 EAV 表的有罪但善意的一方。

处理这种类型的表的选项并不漂亮，而且，正如您所说，随着生产查询所需的数据量的增长，它们会变得更糟/更慢。

  1. 构建一个未记录并保留已提交行的已声明全局临时表 (DGTT)，并使用它来暂存 EAV 表内容的水平版本。DGTT 非常适合这种数据挖掘，因为它们不会产生任何日志记录开销。

  2. 如前面的建议所示，使用传统的 CASE 和 MAX() 分组。问题是每次在您的 EAV 表中引入新的 TYPE 时查询都会发生变化。

  3. 使用 DB2 的 SQL-XML 发布特性将垂直数据转换为 XML。这是一个适用于您提供的表名和列名的示例：

WITH t(id, type, value) as (
VALUES (1,10,111), (1,14,222), (2,10,333), (2,25,444)
)

SELECT
XMLSERIALIZE( CONTENT
XMLELEMENT(NAME "outer",
    XMLATTRIBUTES(id AS "id"),
        XMLAGG(XMLELEMENT(NAME attr ,
            XMLATTRIBUTES(type as "typeid"), value) ORDER BY type)
) AS VARCHAR(1024)
) 
FROM t as t group by id;

SQL-XML 方法的好处是，由 EAV 表处理的任何新值都不需要重写对值进行透视的 SQL。

于 2009-07-02T06:29:45.880 回答