2017-01-16 49 views
4

背景:工作流網站 - 後端設計諮詢

我開始設計師/設計一個新的網站,將跟蹤的項目量的工作流程。每個項目將分配給他們的階段(規劃,實施,實施後,關閉等...)。每個階段包含不同的任務等

可能有人會問,「這聽起來非常相似的其他工作流管理軟件(WMS)已經存在,爲什麼不利用呢?

除這個站點像其他WMS工具一樣跟蹤每個階段,它也需要直接從頁面直接與其他系統(不同域)和軟件(API/WMI)進行交互。它將允許我們的管理員維護Active Directory GPO,確保新計算機使用正確的設置正確初始化,監視遠程計算機上的SQL數據庫保真度等等。對於那些認爲這對問題很重要的人......我目前正計劃使用.NET構建網站。

許多人都知道,項目和標準在商業世界中快速變化。因此,我期待着讓這個網站在每個階段和任務方面儘可能動態和快速變化。例如,員工可能需要執行前面未定義的每個項目的附加任務。然後,我們需要能夠快速更改所有當前打開的項目條目,並且所有新項目都會將新項目添加到清單中。

問:

在大家的經驗,你有沒有發現什麼是存儲大量需要新的數據頻繁更改數據的最佳方式?

最初的想法:

SQL /數據庫存儲:

優點:

  • 輕鬆存儲大量數據。
  • 通過主鍵和外鍵鏈接項目/階段/任務的能力
  • 後端的存儲過程將有助於操縱數據庫並允許更改查詢而無需重新編譯站點。 (!大加

缺點:

  • 新清單上的項目會導致需要在每個表中創建新列。
  • 每個任務的複雜性可能會導致加入大量表格。
  • 創建新列後,每個存儲過程都需要修改以確保新列包含在其操作中。

XML/YAML /任何標記語言

優點:

  • 從 「奮力向前」 變化的角度來看操控自如。
  • 輕鬆地可以在每個任務階段下創建一個新的「節點」,可以更新網頁。

缺點:

  • 將數據保存到文件具有高揮發性(文件可以被刪除,並且沒有數據恢復)。
  • 用戶嘗試同時訪問文件時可能遇到的問題會引發錯誤(需要在代碼中構建「鎖」以讀取/處理文件數據)。

最終意見:

我傾向於SQL /數據庫存儲,但沒有看到更改設計/架構是一個快速的壯舉。如果有任何數據存儲方法可能會更適合解決方案,請告訴我。

謝謝大家。

+0

我認爲SQL Server會非常適合你。它有一個很好的GUI和許多不同的工具。至於升級它就像在最新版本上備份和恢復數據庫一樣簡單。我已經使用了Oracle,Postrgres,Teradata等幾個不同的系統;到目前爲止,SQL Server是我最喜歡的易於瀏覽和互聯網上的大量文檔。 –

+0

@WesPalmer謝謝Wes。我一直在這樣傾斜。它看起來不會有任何簡單的解決方案來解決快速變化的環境。每個路由在需要添加時都需要後端和前端更改。 –

回答

2

需要更多的細節來向你推薦一些特定的存儲空間。但是,從你的描述的一個項目看起來像許多屬性像這樣子項的文件:

{ 
"id": 43233, 
"name": "MyProject", 
"created": "02/01/2017", 
"owner": { 
"id": 32132, 
"name": "John Smith" 
} 
"tasks": [ 
{ 
    "id": 43243, 
    "name": "Task1", 
    "priority": "high", 
    "status": "new" 
}, 
{ 
    "id": 43253, 
    "name": "Task2", 
    "priority": "low", 
    "status": "done" 
} 
]} 

文檔數據庫可以是更適合你,如果你的應用程序並不需要進行跨項目有很多要求和主要與一個項目合作。像MongoDB,CouchDB,Azure Document DB等文檔數據庫對數據模式的限制較少,並且通常比SQL數據庫擴展得更好。

因此,您可以更輕鬆地更改項目對象模式添加新屬性。檢索項目對象也會容易得多 - 您不需要執行大量的SQL連接就可以「構建」項目。

關於性能:這取決於你將如何使用數據庫。對於上面的例子中,你將有:

  1. 要創建項目 - 一個插入到文檔DB VS 4個插件(項目業主,2個任務)到SQL
  2. 爲了得到項目 - 一個讀VS一個非常複雜的選擇與連接。更復雜的項目對象會有更多的選擇語句。
  3. 但是,如果您需要獲取應用程序項目或通過某些條件過濾的任務,SQL將更加方便,並且顯然具有更好的性能。
+2

您的假設是正確的,您在上面指定的層次結構看起來像我設想的設計。我之前沒有看過文檔數據庫。快速搜索後,它看起來很有希望,但根據您的經驗,查詢文檔數據庫與關係數據庫的速度如何? –

+1

我在答案中添加了一些通用性能比較SQL db vs文檔。更多細節我想你可以在這裏例子http://stackoverflow.com/questions/5186707/why-is-mongodb-so-fast –

+1

經過多一點研究後,文檔數據庫可能不是正確的路要走。從我的閱讀中可以看出,很難從文檔數據庫收集報告。 MongoDB提供的工具有助於提供良好的報告嗎? –