關係數據庫應用程序

6

最好的開始方法是找出「用戶故事」（或「用例」） - 但「故事」方法往往非常有效，並開始將股東拖入共享的故事敘述......） ;最重要的是，將數據庫模式設計爲您可以找到的最佳規範化想法，以滿足用戶故事的所有數據層需求。

第三，您可以在架構頂部繪製諸如視圖之類的圖層;第四，可選的，可能存在於數據庫中的觸發器和存儲過程，以確保更高層次的一致性和易用性（但是，不管DBA如何強烈推動這些過程，都不會接受他們保證它們是必須：它們不是 - 如果你的存儲層在規範化方面設計得很好，可能有用的視圖在頂層，非存儲層功能可以總是駐留在其他地方，這是一個方便性和性能問題，而不是邏輯一致性，完整性，正確性）。

我認爲業務層和用戶體驗層應該到來。我意識到這是一個有爭議的立場，但我的觀點是，用戶故事（以及隨之而來的隱含的商業規則）已經告訴你很多關於商業和用戶層的信息 - 所以，「相對來說 - - 敏捷性和「擁抱變化！」應該總是有規則的;-)數據存儲層是業務的下一個階段，並且提煉（「深入」）更高層可以並且應該到來。

來源

2009-09-06 03:27:39

+0

第二種方法！這聽起來像你設計的「表」太早。您應該首先專注於用戶交互，然後設計應用程序以支持這些操作，並僅支持這些操作。從表格開始，您通常會在用戶的屏幕上看到大量刺激且基本無用的工件以及不合理且不合邏輯的對話步驟。 – 2009-09-08 08:29:49

1

一個良好的開端將是熟悉Multitier architecture

然後你設計你的表示層。

在你的業務邏輯層實現所有邏輯

最後，你實現你的數據訪問層。

來源

2009-08-31 08:54:43

2

當你到達數據庫層時，你需要通過存儲過程來處理數據庫訪問。這將有助於爲您提供針對SQL注入攻擊的額外保護，並且可以更輕鬆地將邏輯更改推送到數據庫層。

來源

2009-08-31 08:58:43 mrdenny

+1

只需提及 - 必須非常小心地使用存儲過程。有時候，人們會帶走太多的業務邏輯到sql server中，這可能會在未來擴大規模。 – 2009-08-31 09:11:21

+1

我建議參數而不是存儲過程，但它們都有助於防範SQL注入。正如Svetlozar Angelov提到的，您可以將您放入存儲過程的業務邏輯帶走。 – Dusty 2009-09-02 18:50:43

+0

使用參數化查詢而不是存儲過程的問題是，如果有人確實進入SQL Server，他們現在可以訪問所有表並可以轉儲數據。存儲過程擺脫了這個問題。 – mrdenny 2009-09-03 01:09:35

2

要記住的最重要的事情是，你的第一次，也是最有可能的第二次設計數據庫的第三次嘗試在某種程度上是錯誤的。這聽起來可能是負面的，甚至可能會有點莽撞，（當然更多的是「敏捷」的軟件設計理念），但要牢記這一點很重要。

當然，您仍然需要徹底地進行分析，嘗試一次實現一個功能，但嘗試讓所有圖層都首先運行。這樣，當規格發生變化並且您更好地理解問題時，您不必做很多返工。一個你有很多數據加載到系統中，改變事情變得越來越困難。

這種方法的主要優點是您可以快速找到設計破裂的位置，而您沒有正確分隔設計圖層。我發現非常有用的一個技巧是同時執行sqllite和mysql版本，因此可以在兩者之間進行無縫切換。因爲兩者使用不同的SQL重音，所以它會突出顯示圖層之間的耦合太緊的地方。

來源

2009-09-02 13:42:40

2

如果大多數用戶與數據交互，則可以使用表單透視進行設計。

用戶輸入需要什麼形式？
輸出報告需要什麼格式？

確定後，使用表單將決定需要在幕後進行編碼的業務邏輯。您將接受輸入，創建一組處理它們的過程或方法，並輸出必要的內容。一旦你知道了輸入和輸出，你將能夠輕鬆設計必要的功能。

來源

2009-09-02 18:46:34

1

嘗試設置一個更具生產力的原型，然後使用C++，例如Ruby，Python甚至PHP。

當原型工作正常時，你看到你的數據模型沒問題，而且你的查詢太慢，那麼你可以開始使用C++。

但是，由於您的問題表明您有更多的選擇，那麼數據，在這種情況下，腳本語言的速度應該足夠了。

來源

2009-09-06 09:32:38 Lothar

2

問題的範圍非常廣泛。你期待我告訴該怎麼做。我只能做好講述如何做事情的工作。使用Hibernate/Spring進行調查。由於你的大部分操作看起來像查詢數據庫，冬眠應該有所幫助。確保表格已被充分索引，以便您的查詢在基於索引字段進行篩選時運行得更快。具有挑戰性的任務是設計你的數據庫層，這將是你的應用程序和數據庫之間的粘合劑。設計你的數據庫層足夠通用，以便它可以建立基於你傳遞給它的參數的查詢。然後繼續開發上述表示層。逐層開發應用程序有助於解決分佈邏輯與表示邏輯的分離問題。在開發數據庫層時，假設不僅僅是您的表示層，而是任何客戶端都可以調用它。這將幫助您設計可擴展和適應新需求的應用程序。所以底線：從DB，DB整合層，控制器和最後一個表示層開始。

來源

2009-09-07 13:04:49 Cshah

2

爲了討論的目的，我假定您正在使用一個沒有預先存在的數據庫的啓動應用程序。如果這是錯誤的，我可能會稍微移動步驟的順序。

1 - 瞭解宇宙

首先，你要得到什麼是圍繞你，讓你能真正理解你正在試圖解決的問題意識。

用戶故事或用例往往是一個很好的起點。從用戶將嘗試執行的任務開始，評估它們可能的頻率是一個很好的起點。我喜歡從屏幕上的實物模型開始，無論是否有時間與用戶交流，我發現擁有一個屏幕給我們的團隊提供了一個非常有限的爭論點。
此球體中還存在其他哪些工具？這些天來，我覺得用戶從來不使用一個工具，他們互換很多。您需要知道用戶使用的其他工具的兩個主要內容：
（1） - 與您的工具一起，它們將用作過程的一部分？考慮直接輸入/輸出的需求 - 他們可能想要剪切/複製/粘貼什麼？您可以使用哪些工具爲特定的格式提供文件上傳/下載功能，它們與您的工具一起使用哪些工具，您可能希望與之共享術語，佈局，顏色編碼，圖標或其他GUI元素。特別關注工具的邊緣 - 我在最近的一個項目中遇到的一個真實問題是模擬以前工具的數據庫。事實證明，我們有大規模的數據庫轉變，我們可能會更好地開始新的。
（2）您要更換什麼（如果有的話）或與之競爭？偷走好東西，傾倒和改善壞東西。詢問用戶總是最好的。如果你至少不能理解管理倡議是重要的 - 這個工具是否取代了一個可怕的遺留工具？這可能是舊的，但也有可能是一個真正的功能，有保持業務這些年的工具...

在這個階段，我發現，事情真的是糊狀的 - 有一些屏幕截圖，一些寫作，一些模式或ICD - 但不是一個真正膠凝的線索。

2 - 邏輯實體

或者至少這是什麼OO書調用它。

我並不關心我在這個任務中看到的所有文字 - 但是我發現任何給定的系統，我都有一張真實的圖表，我反覆繪製。它通常大約是3-10盒，並且希望少於連接它們的指數級大量的線。 W

越早可以得到該圖表越好。

對於我來說，如果它是UML，數據庫邏輯模型，較舊的東西或餐巾背面（只要餐巾被塑料包裹並懸掛在每個人都可以看到的地方），這對我無關緊要。

越早可以使此圖正確越好。

完成圖表後，您可以開始研究可能更爲官方的工作。

我認爲這是一個雞蛋問題，關於您是從數據開始，還是從您的屏幕和業務邏輯開始。我知道你確實想要優化數據庫大小和可搜索性......但是如何在沒有屏幕和界面的情況下確切地知道你的數據庫需要什麼？

在實踐中，我認爲這是一個不斷攪動的循環。你在任何地方都做一點，然後你全部改變。

即使您沒有做正式的敏捷生命週期，我認爲您最好打賭的是將設計視爲敏捷 - 在您真正感覺它是「正確」之前，需要多次重複和爭論。

來源

2009-09-08 17:59:04 bethlakshmi

關係數據庫應用程序

回答

相關問題