2010-11-03 61 views
0

目前我們公司在Lotus Notes中使用升級數據庫。我們的升級數據庫處理L1-L3支持無法解決的問題,因此升級爲開發。該數據庫由整個公司使用,因此包含許多部門(硬件,固件,軟件)和產品。每個部門和產品都具有幫助調試特定客戶問題所需的特定信息。最佳工作流管理軟件/體系結構問題

最近我們在Lotus Notes數據庫方面遇到了很多麻煩,我在尋找其他選項。作爲一家公司,我們也將在未來從Lotus Notes移開。我想知道其他人使用什麼樣的工作流管理軟件來處理這樣的事情?

我一直在環顧四周,並沒有發現任何看起來完全有希望的東西,所以我一直在考慮如何在需要時提供一個主題。我目前的規劃路徑是具有完全動態的表單,這些表單存儲在數據庫中,當某人在表單中移動時,根據他們所做的選擇添加其他輸入。我知道這樣做很難做到正確,並且不會在將來添加產品和部門時混淆人。那麼另一個問題是,您會遇到上述設計中的哪些重大缺陷,以及需要注意什麼?如果有人在遇到任何問題之前已經在家裏推出了系統?

回答

2

我不知道任何事情可以處理你的問題,儘管這樣的任務必須有現成的解決方案。

如果您考慮Roll Your Own,我會建議您查看一下CouchDB,因爲它與Lotus Notes有很多相似之處,並且它們的功能大大增強了整個體驗。

http://couchdb.apache.org

http://en.wikipedia.org/wiki/CouchDB

你需要得到了它的速度,但因爲你熟悉的Lotus Notes,應該是輕鬆的學習曲線。

希望這會有所幫助。

-1

我一直在四處尋找,並沒有發現任何看起來完全是有前途的,所以我一直在盤算着如何homeroll一個在需要時

更努力。沒有冒犯的意思!

從架構的角度來看,我的第一個問題是'我們真的需要打造''嗎?建築軟件是不平凡的,特別是你會保持加班。

目前尚不清楚您的功能要求或現有技術標準是什麼,但兩者都會影響市場上哪些選項最適合您。那麼當然你有支持方面,許可等

我想說你需要制定一個相關的評估標準清單,並評估任何可能的候選COTS解決方案,你可以找到(開源也可能是一個選項)以及自定義構建;您需要根據一套嚴格的標準進行評估,並計算TCO(總體擁有成本)。是的,TCO可能聽起來像營銷宣傳/商業流行語 - 但在一天結束時,這是你必須做的事情(除非你是百萬富翁而金錢不成問題)。

做你以後的事情的工具很常見 - 因此我最初的(並且確實有些輕浮)響應。

+0

這裏可以幫助您,爲什麼要花費數小時搜索時間,這可能是一個更快,更明智的解決方案。 – WeNeedAnswers 2010-11-03 01:28:40

+2

WeNeedAnswers恰當地命名以發表評論。 – 2010-11-03 01:34:11

+0

我的回答集中在'考慮如何歸位'方面,我認爲這個階段是有效的 - 我(錯誤地?)給人的印象是帕特里克可能很快就會走這條路。我注意到@WeNeedAnswers也包含了一個評論。 – 2010-11-03 02:28:15

1

什麼樣的工作流管理軟件,其他人都在使用來處理這樣的事情?

  • 在工作中,我們必須使用一種稱爲疑難雜症的系統的人,我只是用Google搜索,並不能找到它(!),我沒有在工作,所以不能輕易地獲得更多的信息。
  • 主要的LOB工作流程由一箇舊的傳統主框架系統提供(不要去那裏!)。
  • 幾年前,我參與了在.Net中構建主要工作流系統 - 我們使用K2 Workflow(當前產品名稱爲'BlackPearl')作爲核心工作流系統。 K2非常強大,非常適合.Net/Microsoft環境,並且(至少在理論上)它將與SharePoint集成。

我目前的規劃路徑是擁有完全動態的形式...你會用上面的設計遇到什麼大的錯誤?

不是一個陷阱 - 但管理數據將是一個挑戰。擁有動態表單可能意味着數據庫物理設計方面的幾件事情之一:

  • 表結構反映了表單結構;向表單添加字段意味着向DB添加一列;並添加新表單意味着向數據庫添加新表格。如果表格不會有太大的改變,那麼這可能是可以的,他們越難以維護。
  • 半通用表結構:一些常見的列,然後是一些通用的列,如FormField1FormField2等。這將更易於管理,並且您可以實現自動化,以便用戶可以自行提供字段。不足之處是你正在處理數量有限的列/表格模式。對此的更改將非常具有挑戰性。

在上述兩種情況下,物理數據結構都與邏輯數據結構緊密匹配。其中一個關鍵問題是,爲了讓您的應用程序自動創建額外的列,需要該應用程序對系統擁有更大的安全權限 - 所以您不會希望在任何公共互聯網上都這樣做。或者:

  • 有一個'窄'表,其中字段值存儲更像鍵值對。

這種方法將支持一種解決方案,讓用戶自行提供字段和表單,並且沒有限制。缺點是報告要困難得多,而且會變慢。您可以通過將「易失性」事務數據遷移到專爲報告設計的數據庫來解決這個問題。

這種數據庫設計常用的術語是'NoSql Database',CouchDB(由@WeNeedAnswers建議)就是一個例子。

一個相關的陷阱(如果你允許用戶自行提供表單/域)是管理數據和它的質量;你不希望人們使用不同的術語來表達同一個事物,或者同一個術語意味着多個事物。