哦,所以你被困在一个糟糕的数据库设计中,你不允许改变......这很糟糕。它应该被分成 4 个表(至少)。无论如何,在这种特殊情况下,这是一种方法。
我假设第一个查询相当于:
SELECT id, F1, F2, F3, F4, F5, F6
FROM tablename
WHERE id IN (101,102,1,18)
所以,你可以像这样进行转置/旋转/任何实际调用的操作:
SELECT
MAX(CASE WHEN id=101 THEN F1 END) R1,
MAX(CASE WHEN id=102 THEN F1 END) R2,
MAX(CASE WHEN id=1 THEN F1 END) R3,
MAX(CASE WHEN id=18 THEN F1 END) R4
FROM tablename
UNION
SELECT
MAX(CASE WHEN id=101 THEN F2 END) R1,
MAX(CASE WHEN id=102 THEN F2 END) R2,
MAX(CASE WHEN id=1 THEN F2 END) R3,
MAX(CASE WHEN id=18 THEN F2 END) R4
FROM tablename
UNION
SELECT
MAX(CASE WHEN id=101 THEN F3 END) R1,
MAX(CASE WHEN id=102 THEN F3 END) R2,
MAX(CASE WHEN id=1 THEN F3 END) R3,
MAX(CASE WHEN id=18 THEN F3 END) R4
FROM tablename
UNION
SELECT
MAX(CASE WHEN id=101 THEN F4 END) R1,
MAX(CASE WHEN id=102 THEN F4 END) R2,
MAX(CASE WHEN id=1 THEN F4 END) R3,
MAX(CASE WHEN id=18 THEN F4 END) R4
FROM tablename
UNION
SELECT
MAX(CASE WHEN id=101 THEN F5 END) R1,
MAX(CASE WHEN id=102 THEN F5 END) R2,
MAX(CASE WHEN id=1 THEN F5 END) R3,
MAX(CASE WHEN id=18 THEN F5 END) R4
FROM tablename
UNION
SELECT
MAX(CASE WHEN id=101 THEN F6 END) R1,
MAX(CASE WHEN id=102 THEN F6 END) R2,
MAX(CASE WHEN id=1 THEN F6 END) R3,
MAX(CASE WHEN id=18 THEN F6 END) R4
FROM tablename
不幸的是,它以一种奇怪的方式排序。
我真的建议你说服负责人重新设计数据库。一些设计人员认为拥有这种结构的表是“灵活的”并且“提高了性能”,但事实并非如此:使用此类表进行实际工作需要非常重要的查询,而大多数 DBMS无法优化因为从来没有人指望他们会面对这样的暴行。
这样的表也打破了关系模型的理念。每个表必须有一个语句“模板”,例如,CREATE TABLE S (id INTEGER, name TEXT, address TEXT)
可以有模板“具有 id ID 的供应商称为 NAME,位于 ADDRESS”。现在,该表中的每一行都会产生关于世界的真实陈述当您将其内容放入模板时:如果S
将包含一行(1, "Bob & Co.", "Lime St., 125")
,那么它会告诉您“ID 为 1 的供应商名为 Bob & Co.,位于 Lime St., 125”。
所有关系操作:选择、投影、连接、过滤等,不只是以特定方式组合表,不!它们还结合了“模板”,因此您可以说出查询为您提供的确切信息。反之亦然,如果你能通过组合这些“模板”来表达你想要什么信息,它几乎会自动给你一个相应的查询。
并且您必须使用的表可以与任何健全的“模板”相关联。这就是为什么你必须编写无意义的查询才能得到有用的东西。请注意,我基本上可以猜测结果集的“模板”,
R1 R2 R3 R4
============================
Local 9 3:55 4:50
...
这类似于“R2 类型的事件在地点 R1 发生,从时间 R3 开始并在时间 R4 结束”。我对么?