面向大型分析的SQL腳本庫的設計模式？

我正在編寫大量的SQL腳本以供大量人員共享，他們通常會通過稍微爲其特定目的編輯腳本來處理腳本，然後使用修改後的腳本生成數據集以供進一步分析。面向大型分析的SQL腳本庫的設計模式？

我一直在努力構建和組織這樣的圖書館。我想要更多的結構，而不僅僅是一個包含諸如「signups_and_spend_by_week.sql」之類的長文件列表的文件夾。我看到基本上有兩個相互關聯的問題：

參數化。像日期和樣本大小等事情相對容易拉出並變成變量，但是改變查詢性質的參數又如何呢？比如說將左連接變爲內連接？（a）評論這些可能性是否明智，（b）創建兩個版本（因此創建嚴重的DRY問題），或者（c）用更高級的編程語言來包裝查詢，這些語言可以更容易地表示這些類型例如，
```
q = "SELECT * FROM plants" 
    if want_all: 
     q = _q + "LEFT JOIN fruits ON fruits.plant_id = plants.id" 
    else: 
     q = _q + "INNER JOIN fruit ON fruits.plant_id = plants.id"  

    run_query(q) 
```
幹。我發現相同的模式不斷出現，爲更復雜的查詢創建了相似或相同的視圖作爲中間步驟。我的想法是將這些可重複使用的數據分離出來，並根據需要調用它們。但是，我擔心這會在整個庫中創建依賴關係，並且對「基本」查詢的看似無害的更改可能會無意中破壞別人的查詢。除了紀律和良好的文檔/規則之外，他們可能會做出一些妥協，例如自動化測試？

2012-02-27 John Horton

這看起來像一個問題，不應該以純技術方式處理。

基本上，您將提供其他人可以精煉的SQL基礎。你的一些基本的SQL將會有錯誤，在某些情況下運行緩慢，解決不存在的問題，現場發現......並且它們將被改進，改變，忽略，讚揚......

很難預見哪種方式最適合你和你的同事。至少我沒有想法。

我建議你首先啓動非常基本的，非常簡單的：帶有SQL腳本的目錄，賦予文件有意義的名稱。 - 允許人們看着他們，使用他們，改變他們，從他們中派生出來，評論他們，爲他們的用途給予積分，...... - 與所有參與者頻繁會面。 - 試着找出什麼效果很好，你的團隊需要什麼，什麼東西根本不起作用，...... - 只有當你作爲一個團隊，開始清楚地看到你需要什麼工具來支持你正在做，開始思考和設計一個系統來支持你的需求。只有將腳本存儲在數據庫中，如果仍然有意義的話。

現在不要開始設計，你可能會扔掉80％，而你留下的20％將會放棄那些花了這麼多時間嘗試提供有用的東西的人的感受羣組。

對我來說，這是一個真正的SCRUM方法效果最好的情況：沒有人清楚地看到它應該如何構建最佳狀況。溝通，試圖解決問題的短暫衝刺，交互性，改變那些按計劃未能奏效的事情，......這些對我來說似乎是這個項目的關鍵詞和短語。

讓它成長吧，不要以爲你現在可以琢磨怎麼樣。我寫了這個假設，它對你來說是清楚的，因爲它對我來說是如何發展的，如果你清楚地看到它會是什麼樣子，並且之前做過，我的評論將離開。）

來源

2012-02-27 15:04:12 Wim

我的一些想法：

獨立應用與：

-tags for scripts marking 
-search functionality (Google like) 
-scripts verifications (with metadata) 
-script runner with GUI for parameters entry

腳本：

一些元語言在SQL是必須的，但它仍然將是一個DSL，所有缺點。所以我會嘗試以極簡主義的精神建立你的DSL。我的建議是DSL的無懈可擊的風格：評論中的所有元信息，控制語句也是如此。事情是這樣的：

/* 
%%Parameters: 
    %%StartDate:Date:Please enter date for blah blah blah 
    %%EndDate:Date:And enter date for blah blah blah 

%%Verions: 
    %%AllProducts:Defalt 
    %%Friuts:Optional 
*/ 

SELECT * FROM plants 

--%%Version:AllProducts 
    LEFT JOIN fruits ON fruits.plant_id = plants.id 
--%%EndOfVersion 

--%%Version:Fruits 
-- INNER JOIN fruit ON fruits.plant_id = plants.id 
--%%EndOfVersion 

WHERE 
    StartDate >= %%StartDate AND 
    EndDate <= %%EndDate

幹：這是非常主觀的，但我會recoment不建立標基礎設施，incuding機制等IMO還有比利潤更多的成本。

來源

2012-02-27 12:03:53 Radek

面向大型分析的SQL腳本庫的設計模式？

回答

相關問題