哦,所以你堅持一個可怕的數據庫設計,你不能改變......這很糟糕。它應該被分成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
不幸的是,在A的分類奇怪的方式。
我真的建議你說服負責人重新設計數據庫。一些設計人員認爲具有這種結構的表格「靈活」並且「提高性能」,但並非如此:使用這種表格進行實際工作需要非常平常的查詢,其中大多數DBMS 不能優化,因爲它們是從來沒有預料會處理這種暴行。
這樣的表格也打破了關係模型的思想。每個表必須具有一個語句「模板」,例如,CREATE TABLE S (id INTEGER, name TEXT, address TEXT)
可以具有模板「具有ID ID的供應商稱爲NAME並位於ADDRESS」。現在,在這個表中的每一行生成您關於這個世界,當你把它的內容到模板真實的說明:如果S
將包含行(1, "Bob & Co.", "Lime St., 125")
,那麼它會告訴你,「ID爲1:供方被稱爲鮑勃& Co.,位於Lime St.,125「。所有的關係操作:選擇,投影,連接,過濾等都不只是以特定的方式組合表格,不!它們還結合了「模板」,因此您可以說出查詢給出的確切信息。反之亦然,如果你可以通過組合這些「模板」來表達你想要的信息,它幾乎會自動給你一個相應的查詢。
而你必須使用的表格可以與沒有理智的「模板」相關聯。這就是爲什麼你必須編寫無意義的查詢才能獲得有用的信息。請注意,我基本上能猜出結果集的「模板」,
R1 R2 R3 R4
============================
Local 9 3:55 4:50
...
這件事情就像「類型的事件R2是發生在地方R1,開始時間R3和R4時間結束」。我對麼?
老實說,爲什麼不把數據以所需的格式存儲在'tablename'中? –
Hi @joker Hi @joker我有超過150列值,它也是一個非常巨大的表..所以我不能格式化該順序..所以我需要在sqlite查詢和簡單的方法來使用,:) :) – user1099630