曾幾何時，在遙遠的星系中遙遠的地方，我是兩位開發人員之間討論的見證人。主題是如果給最終用戶訪問生產SQL服務器（MS SQL 2008）是一個好主意，以便他們能夠根據自己的數據製作自己的報告。對最終用戶的SQL：優缺點
這是商務人士的要求 - 「我們的客戶想製作自定義報告」。
誰提出這方面的一個傢伙，聲稱：
誰反對這個其他人聲稱：
您認爲如何讓最終用戶訪問SQL？
預先感謝您！
您不僅可以通過將用戶限制爲只讀訪問權限，還可以通過打開query governor cost limit來使某些事情更安全。這將試圖在運行之前對查詢進行一些成本分析，並且如果它們超過了預定義的閾值，它將拒絕運行它們。
甚至比這更好的是有一個克隆的數據庫可用於查詢。這可能與運行生產系統備份的單獨服務器一樣簡單。根據數據所需的「活動」方式，您可以相應地調整備份/恢復間隔。
至於將數據庫暴露給非程序員直接查詢是個好主意，那還取決於用戶是多麼的聰明。他們可以教SQL嗎？簡單的事情並不難。
反對的論證非常薄弱。如果用戶，不能寫sql，你爲什麼在意？有報告編寫工具（Crystal Reports），可以處理很多這樣的工作。
一些使用其他軟件的公司有員工，他們知道如何查詢數據庫，或者他們可以聘請顧問。
您永遠無法進入企業市場，鎖定數據庫訪問。
編輯：一組視圖可以構建到數據庫中，以滿足大多數用戶需求。這樣他們不必擔心複雜的連接。
這完全取決於您的用戶。如果用戶在技術上有能力或有興趣開發這套技能，他們可以減輕程序員的大部分工作量。
一個另一方面，我知道boneheads永遠不會明白規範化的數據結構，以及它們失控的查詢多次崩潰的服務器。
如果你決定爲它去，創造可能的話報告一個單獨的數據庫鏡像。每晚更新一次，以便獲得相當的數據。當然，如果他們有實時報告需求，這並不理想。
給予最終用戶訪問寫自己的查詢對生產數據庫，即使只讀訪問的主要問題是，你的表現會通過地板進入地下二層下降。如果最終用戶可以編寫SQL，他們通常不能很好地寫。在某些時候，他們會發現遊標（如果在MS SQL中）和/或他們會過度考慮他們的連接。他們會拉他們能找到的每張桌子。如果你想讓他們開心，可以在一臺單獨的機器（或有限的虛擬機）上每晚做一個非生產數據庫，並告訴他們自己解決問題。專家提示：也告訴他們你沒有時間去支持它。
我不是反的最終用戶，我不認爲他們是被信任來寫東西查詢類似一種有效的方式。如果您選擇少數您認爲可以信任的人，請嘗試與他們共享密碼，並將他們鎖定。
這取決於部署後誰負責產品。 如果情況很明顯（你在沒有支持的情況下出售代碼），那爲什麼不呢？ 那不是你的問題。
的情況時，你必須照顧一切，並負責運行時間我不會建議這樣做甚至只讀。
您可以使數據庫帳戶安全地避免不必要的更改，但無法避免性能問題。最終用戶可以輕鬆創建一個查詢來鎖定所有表並長時間運行。它不會真的使數據庫崩潰，但用戶會將其視爲崩潰。
如果您確定報告功能可能掛起系統，您可以繼續。
但是，我必須說，我懷疑這種用處。和統計一樣，你必須知道你所要求的正是你想要的，否則結果是沒用的。
最終在實現最終用戶數據分析方面具有商業價值。通過SQL直接訪問是一種方法。
尚未提到一個缺點。默認情況下，SQL Server讀取器將阻止編寫者。這意味着您可能需要啓用快照隔離（或者可能使用數據庫快照或數據庫的只讀副本），否則即使最簡單，最無辜的用戶查詢也可能會削弱您的生產系統。
也許令人驚訝，儘管微軟在7年前推出的快照隔離模式下，它似乎仍然是經常可以看到系統進入生產與它關閉（默認無SI讀取已提交）。因此，在允許用戶訪問您的生產系統之前，您可能需要進行更改並進行一些重新測試和重構。
爲什麼「向最終用戶公開SQL和數據庫結構」是「糟糕的設計」？如果數據庫設計良好，沒有理由隱藏它。 – 2012-04-17 21:48:24
在我的愚見中，DB是一個內部系統功能。最終用戶通常不知道系統是如何工作的，他們不應該知道它;這是一個黑匣子。如果我們將數據庫暴露給最終用戶，我們會公開其內部設計中有價值的部分，但這並不好。恕我直言。 – 2012-04-18 07:59:28