使用複雜的SQL Server數據庫模式

我有一個數據庫，我必須保持與SQL Server 2005的兼容性，我一直在考慮如何降低複雜性並處理性能問題。使用複雜的SQL Server數據庫模式

我的數據庫是像大多數其他的和充滿了數據，這是一個很大的數據，並有很多的查詢在裏面。我有許多存儲過程已經發展（一段時間以來）以滿足業務需求。這很好，但我遇到了性能問題，我的查詢變得越來越複雜，難以管理。乍看之下，我不認爲我的數據模型有什麼問題，也沒有荒謬的規範化（我們已經對一些東西進行了非規範化處理），但是我發現自己無法編寫和運行這些快速查詢爲我的Web界面AJAX查詢提供動力，因爲所有的約束似乎都是隨意存在的。

所以，我想過這個問題，我想我要整理我的數據庫中環。讓我解釋。

基本上，在最內環，你會發現最專業的組數據。這些表格完全非規範化，並通過聚合來自外部環的數據構建而成，以確保特定的查詢運行速度非常快。
最外圈最理想的是「啞」，基本上只是一個真正的不好的地方放東西。
外部和內部之間基本上是您的概念模型，這些從其他環拉或推到內環，這是您的數據清理，並確保它是正確的。
的數據只能從外圈流向的內環。
我不想使用觸發器來保持不同的響鈴一致，而是我有一個服務和工作，聽，輪詢和定期運行，以確保最終的一致性，跨董事會。

現在，這是我尋求建議，希望從經驗豐富的數據庫人員獲得一些輸入。我相信我能以這種方式從我的數據庫中獲得更多。這將使我能夠在不同階段解決複雜性和性能問題。也許有一個共同的名字爲我正在做什麼，或者這是NoSQL運動的全部內容，但我不知道，這個想法對我有吸引力，但如果我在那裏的方式，很想聽聽這件事之前，我犯了一個錯誤......

來源

2011-10-14 John Leidegren

如果你想要速度和最終一致性，NoSQL解決方案可能是更好的選擇。這聽起來像一個使用SQL Server的自己的nosql解決方案，這似乎是一個壞主意。 – JNK

看你的語言年輕人 –

@JNK - 讓我們說跳船和放棄SQL Server不會發生。此外，我並不滿意SQL Server做事情的方式，對待正確的方式，完成任務。從長遠來看，NoSQL可能是正確的選擇，但我還沒有... –

你需要一個初學者第二篇到數據庫中。認真。將其拆分爲OLTP和OLAP部分 - 數據倉庫是按順序排列的。擺脫存儲過程。然後意識到你的「很多odata」可能是其他人的「數據笑話」 - 我的系統應該擴展到大約60tb的數據量（即60.000） - 我們的初始硬件有21.000G。

您的系統sonds像你混淆了一個正常的數據庫（OLTP）與數據倉庫。拆分它們 - 這不會工作。拆分他們也在硬件。這是完全標準 - 關於數據倉庫的geta書。

來源

2011-10-14 17:51:49 TomTom

IBM紅皮書有設計和構建數據倉庫的免費下載標題。請參閱http://stackoverflow.com/questions/6178330/design-logical-model-of-datawarehouse-fact-tables-and-dimensions-table/6178657#6178657 –

我需要對數據倉庫（OLTP和OLAP）進行介紹，不知道我需要一本關於數據庫的初學者書籍。謝謝你指出，雖然。我的問題與任何問題一樣真實，並不意味着我必須一路走下去，擴展到數據結核，我們實際上沒有任何大的工作負載只是大量的數據，複雜性和緩慢的查詢，但在它之前真的成爲一個問題，我正在研究如何挽回這種情況。 –

那又如何？對不起 - 大量的數據+緩慢的queires =更好的hwardware +標準方法。 – TomTom

雖然我基本上@ TomTom的答案達成一致，我想這句話不同：你已經基本上開發的數據倉庫的概念（或數據集市，是特定的）你自己。購買一本關於數據倉庫的書是一個好主意，參加關於該主題的研討會或一系列課程甚至更好。你顯然已經認真思考過這個問題，當你瞭解最佳實踐和已經開發的不同方法時，這對你會很好。

來源

2011-10-14 21:51:35

使用複雜的SQL Server數據庫模式

回答

相關問題