內下一個間隙假設我有下表:查找值
id name base index
0 A 2 0
1 B 2 2
2 C 2 4
3 D 2 6
4 E 2 8
5 F 2 10
所以,索引=鹼基* i,其中i是該行的在一個序列中的位置。
不時,一些行被刪除,例如,如果我刪除名爲C行和d:
id name base index
0 A 2 0
1 B 2 2
4 E 2 8
5 F 2 10
新行後,最後總是被添加,所以下一行是MAX(索引)+ base = 12,但由於刪除的行導致索引列中值之間的差距在一段時間後會成爲問題。如果不是插入最後一個,我將它插入第一個可用缺口中,問題不會發生。
所以,我懷疑有沒有發現第一個可用間隙的問題和MAX(索引)一樣高效,但最有效的解決方案是什麼?也許它夠好。
如果不清楚,我需要找到第一行'a',使得索引值最接近的行大於a.index + a.base。
這意味着對於任何SQL數據庫使用ORM的應用程序,因此它必須是嚴格標準的SQL。
編輯
這纔是真正的表和實際問題簡單化,我期待僅使用基本和索引列的解決方案。涉及在其他表格中添加新列或索引的解決方案對於我的應用程序不實用。
編輯2
看來基本列正在使問題更加複雜,但這不是必需的。這個問題可以簡化爲表所示:
id name index
0 A 0
1 B 1
4 E 4
5 F 5
在哪裏,我需要找到第一行「A」,使得與比a.index + X高指數最低的行。在這種情況下x = 1.
枚舉而不先排序或利用id不是可靠的解決方案,因爲這些可以改變。例如,如果行也是這樣的,則解決方案必須工作:
id name index
0 A 0
23 F 5
45 E 4
90 B 1
我懷疑ORM的查詢語言可以解決任何數據庫的這種問題。大多數ORM迎合共同點,如果沒有窗口函數,這個問題很難解決。 Afaik沒有ORMs抽象了窗口函數,但最能體現的窗口函數最近纔出現在主要的RDBMS中。在Postgresql上,版本8.4(2009);甚至SQL Server 2005都具有窗口功能,因爲er .. 2005,僅在SQL Server 2012上支持LAG和LEAD窗口功能;甚至是運行總計'(SUM OVER())'在SQL Server 2008上不起作用 – 2012-04-23 02:38:17
如果確實總是index = base * i,那麼兩次存儲相同的信息(即數據庫沒有正常化)。您可以即時計算「指數」。 – gcbenison 2012-04-23 02:39:06
@MichaelBuen即使ORM無法處理問題,我也可以使用原始SQL,但它仍然必須與ORM支持的所有數據庫兼容。 – 2012-04-23 13:50:35