視圖中的日期範圍 - 這是正常的嗎？

我最近開始在一家擁有巨大「企業級」應用程序的公司工作。在我上一份工作中，我設計了數據庫，但在這裏我們有一個我不屬於的整個數據庫架構部門。視圖中的日期範圍 - 這是正常的嗎？

他們的數據庫中的一個奇怪的事情是，他們有一堆視圖，而不是讓用戶提供他們想看到的日期範圍，而是用一個（全局臨時）表「TMP_PARM_RANG」加入一個開始和結束日期。每次主應用程序開始處理請求時，第一件事情就是「DELETE FROM TMP_PARM_RANG;」然後插入它。

這似乎是一種奇怪的做事方式，並不是很安全，但這裏的其他人似乎都可以。這是正常的，還是我的不安有效？

更新我應該提到他們使用事務和每客戶端鎖，因此它可以防範大多數併發問題。此外，如果不是數百個視圖，則幾乎都有數十個取決於TMP_PARM_RANG的視圖。

來源

2009-01-07 Paul Tomblin

這是什麼意思的'意見'在這裏？在我的網頁開發中。背景是指代碼本身保存在模型和控制器中的HTML文件。 – 2009-01-07 16:27:27

我的意思是在SQL意義上的「意見」。這就是我使用SQL標籤的原因。 – 2009-01-07 16:31:07

我理解正確嗎？

有這樣一個觀點：

SELECT * FROM some_table, tmp_parm_rang 
    WHERE some_table.date_column BETWEEN tmp_parm_rang.start_date AND tmp_parm_rang.end_date;

然後，在一些前端用戶輸入的日期範圍，和應用程序執行以下操作：

從 TMP_PARM_RANG
插入一個新行到 TMP_PARM_RANG與用戶的值
選擇所有來自第e查看

我想知道TMP_PARM_RANG的更改是提交還是回滾，如果是的話？它是臨時表還是普通表？基本上，根據這些問題的答案，對於多個用戶並行執行的過程可能並不安全。人們希望，如果情況如此，他們已經發現並解決了這個問題，但是誰知道呢？

即使它是以線程安全的方式完成的，爲簡單查詢操作對數據庫進行更改也沒有多大意義。這些DELETE和INSERT正在生成重做/撤銷（或者非Oracle數據庫中的等價物），這是完全不必要的。

實現相同的目標將是執行這個查詢，用戶的輸入綁定到查詢參數的簡單和更正常的方式：

SELECT * FROM some_table WHERE some_table.date_column BETWEEN ? AND ?;

來源

2009-01-07 16:32:26

就我個人而言，我猜這將是一個非常奇怪的發生。從你所說的兩個方法同時調用這個過程可能會非常有趣。

通常日期範圍是作爲視圖上的過濾器完成的，而不是由存儲在其他表中的外部值驅動的。

我可以看到的唯一理由是，如果存在一個多步驟的過程，那麼這個過程一次只能執行一次，而多個操作需要多個存儲過程。

來源

2009-01-07 16:23:31

他們是否還添加了一個 - 在應用程序中爲主鍵生成下一個唯一值？

似乎共享狀態的概念沒有涵蓋這些人，或共享狀態的原因沒有我們。

來源

2009-01-07 16:26:49

我還沒有發現它們是如何分配主鍵的，但是數據庫中沒有像我預期的那樣的序列。 – 2009-01-07 16:28:13

這聽起來像一個很奇怪的算法給我。我想知道它是如何處理併發的 - 是否包含在事務中？

對我來說聽起來像某人只是不知道如何編寫他們的WHERE子句。

來源

2009-01-07 16:27:25

此表必須有一些商業原因。我看到硬編碼的日期實際上是分區視圖，他們使用日期作爲分區字段。我還看到，像處理夏令時一樣的桌子，想象一個返回在DST期間發生的所有活動的視圖。而且這些東西都不會刪除並插入到表格中......這只是奇怪的

因此，無論是需要挖掘出來的更深層的原因，還是當時看起來像是好主意，但爲什麼這樣做已經失去了作爲部落的知識。

來源

2009-01-07 16:27:30 JoshBerke

如果數據庫是oracle，它可能是一個全局臨時表;每個會話都會看到它自己的表格版本，插入/刪除操作不會影響其他用戶。

來源

2009-01-07 16:28:18 William

的意見可能被用作臨時表。在SQL Server中，我們可以使用表變量或臨時表（＃/ ##）來達到此目的。儘管專家不建議創建視圖，但我爲SSRS項目創建了很多視圖，因爲我正在處理的表格不互相引用（認真對待NO FK的表格）。我必須解決數據庫設計中的解決方法缺陷;這就是爲什麼我使用很多觀點。

來源

2009-01-07 16:56:14 MarlonRibunal

我想它會讓他們支持多個範圍。例如，他們可以返回2008年1月1日至1/1/2009以及1/1/2006和1/1/2007之間的所有日期，以比較2006年的數據和2008年的數據。你不能用一對綁定參數來做到這一點。另外，我不知道甲骨文是如何對查詢進行查詢計劃緩存的，但也許它與此有關？將日期列作爲視圖的一部分進行檢查時，服務器可以緩存總是假定日期將被檢查的計劃。

這裏只是拋出一些猜測:)

而且，你寫到：

我應該指出，他們使用交易和每客戶端鎖，因此它防範的最大併發問題。

雖然這可能會防止由於併發造成的數據一致性問題，但它在由於併發性而導致的性能問題時會受到傷害。

來源

2009-01-07 16:58:11

由於您在這裏使用了全局臨時表GTT方法，因此該方法對於多用戶系統來說當然是安全的，因此在那裏沒有問題。如果這是Oracle，那麼我想要檢查系統是否正在使用適當的動態採樣級別，以便適當地加入GTT，或者調用DBMS_STATS來提供GTT的統計信息。

來源

2009-01-07 18:12:43

視圖中的日期範圍 - 這是正常的嗎？

回答

相關問題