使用ASP.NET或Sharepoint

我們有一個項目即將爲美國政府機構規模。數據包含在Oracle數據庫中，包含約150萬行，全部文檔。需要創建將這些文檔鏈接到特定記錄的記錄。這是一個多對多的場景。因爲它是政府機構，所以這些文件和記錄中的每一個都必須包含許可指定。此外，有了這些，必須有可以查看或編輯或甚至不能查看這些特定編碼文檔的組。使用ASP.NET或Sharepoint

我知道這可以在各種頁面中使用ASP.NET方法完成，並使用C＃代碼和JavaScript和/或jQuery控制，但是，我的問題是，這是否更適合Sharepoint項目？

來源

2013-12-20 Dean.DePue

如果想法是維護Oracle中的所有文檔，並且SharePoint目前尚未用於其他事情，我認爲部署SharePoint不會有好處。添加SharePoint本身並不是一項簡單的任務，按照您描述項目的方式，在我看來，它會增加很多額外的工作，並且很難證明許可成本。 –

來自專門研究SharePoint的人員，我爲您的特定要求而努力。它會勝過你提到的許多事情，但關注我的是你提到的多對多關係以及文檔加載。

SharePoint是而不是擅長關係數據。查找列並不真正計數，並且很多時候您最終都會執行一些非常骯髒的事情，以使SharePoint成爲關係數據庫。

150萬個文檔意味着您需要非常認真地規劃這些文檔在SharePoint中的存儲方式。如果只是簡單地將這些全部內容轉儲到一個文檔庫中的單個站點，那麼您將很快違反軟件邊界。這並不是說它不被支持 - 只有關於如何存儲/使用許多文檔而不會導致性能下降的最佳實踐。有了這些文檔，如果要求它們存在於一個站點下，那麼您可能會開始考慮實施遠程blob存儲，這是額外的物流/許可。

的SharePoint 是在版本控制，文檔鎖定，信息管理策略，工作流（有一些TLC）的合作非常好，搜索，分類等

坦率地說，這個問題太複雜，給出一個明確的回答在這個網站上。在SharePoint中它絕對是「可行的」，許多SharePoint的現成功能正好是您系統當前使用方式的好處。但是，如果您在自定義Web應用程序中擁有通過這種方式授予的細粒度控件類型，那麼您的其他一些要求實現起來就不那麼痛苦了。

您需要聘請專門研究這兩種實踐（asp.net和SharePoint）的供應商，讓他們徹底評估這兩種選擇。對您的要求與當前狀態以及兩種選擇進行差距分析將是有益的。

來源

2013-12-20 18:30:03 zincorp

這取決於。這裏有很多其他的變量。是否有AD環境？該環境是否適合您描述的安全計劃？

你必須留在Oracle嗎？

這些文件需要發生什麼樣的陰謀？這些檢索/讀取類型操作還是您還在編輯？版本控制？允許用戶創建自己的文件夾結構？

考慮到Oracle的後端，使用本土C＃方法最有可能會更好。但是，這又取決於上述的答案。

來源

2013-12-20 17:28:13

我忽略提及整個過程是在前一段時間用Oracle表單編寫的，這就是爲什麼DB。文檔正在分組，編輯，編輯，鎖定和打印。 –

使用ASP.NET或Sharepoint

回答

相關問題