2010-01-19 55 views

回答

1

試着用你最喜歡的編程語言做一些使用數據庫的簡單應用程序。通過實踐學習。當你遇到問題時,閱讀DBMS文檔並學習。

2
 
1) choose a target database, Oracle, MySQL, MS SQL... 
2) buy a good book, 
3) participate discussion in community. 
0) of course, setup an env to play around... 
+1

在開始做之前,您需要在THEORY上找到一本好書!您可以瞭解每種RDBMS實現的具體情況,但如果沒有良好的信息設計和建模基礎,這樣做會讓您感覺不好。 – 2010-01-19 20:32:40

3

不要別人怎麼建議 「邊幹邊學」。

這是猴子式的學習。

人類智力/知識已經遠遠超出了對於大多數物種標本而言,「通過犯錯學習」仍然是可能的/有成效的。

相信我,如果你只是走下「專心學習」的道路,你最終會做的唯一事情就是重複幾百萬人在你面前犯的同樣的錯誤。

在這裏,我可以第二個其他答案建議的唯一事情是「買一本好書」。但是「成爲一本好書」的確意味着它應該全面涵蓋理論。否則,你很可能最終建立像羅馬人建造他們的aquaducts一樣的數據庫應用程序:過度某些事情「只是爲了安全起見」。 (這正是那些羅馬工程師在建造那些通常仍然存在於今天的紀念碑時所完成的工作,因爲沒有任何對重力和混凝土跨度等事物的認識/理解:他們投入幾十塊多餘的磚塊,但並不真正知道它們是否真的需要它們,但它們的世界並不像我們的那樣具有經濟競爭力。)

1

我也建議你拿一本好書(或更多,性能調整是一個非常複雜的主題,它通常在一個單獨的書中介紹)在一個主要數據庫上(無論你選擇哪一個首先學習)。你需要學習

主題是(至少):

查詢包括使用的連接(如果你不完全理解加入,你不能做任何事情,除了最簡單的查詢,否則你可能得到結果集是不正確。你不能對聯接如果數據具有意義學習太多。

,你必須瞭解如何判斷你是生產的結果是正確的結果。

正常化 - 如果你不理解規範化,你不能設計一個有效的關係數據庫ry和外鍵。千萬不要設計一個數據庫表,沒有辦法唯一標識一條記錄。

集合論 - 你必須學會​​如何操縱記錄組而不是循環記錄。

性能 - 如果無法及時獲得結果,則沒有人會使用您的軟件。數據庫中的設計應仔細考慮性能,因爲數據庫在執行不良時不容易重構,而且有許多技術比其他技術能夠產生相同的結果更快。你應該知道這些是什麼,而不是使用表現不佳的人,因爲你發現他們更容易理解。

數據完整性 - 如果你不能依賴數據是正確的,你沒有一個有用的數據庫。您應該知道如何確保數據與其他數據具有正確的值和關係。這還包括使用正確的數據類型(例如,存儲日期作爲日期時間或日期數據類型)。

安全性 - 包括防止SQL注入攻擊和可能的內部欺詐。

約束和觸發器以及存儲過程和用戶​​定義的函數。

最後,在數據庫設計中不要使用面向對象的思想。關係數據庫通常使用您在面向對象編程中不會使用的工具和技術。這是一個不同的主題,因此受到不同的規則和限制。

3

我不是一個沒有一個真正的應用程序應用它的學習的忠實粉絲。

關於建模和設計的書籍都很好,但所有這些建議都需要放在應用程序的上下文中。

我已經看到了我的「可怕」數據模型的份額,可以很好地適用於應用程序。雖然有一個「好設計」的純潔性,但簡單的事實是,並非所有事情都需要「好設計」。或者,更好地說,對於一個應用程序的「優秀設計」可能與另一個應用程序完全不同。

很多簡單的應用程序在「愚蠢」,「笨」,「壞」設計中表現良好。

很多學習都是從做錯事情發生的。

爲了解釋托馬斯愛迪生,「進步,我取得了很多進展,我知道有一千件事情不起作用。」

很多東西在「現實世界」中應用時都比較容易學習,然後根據該標準判斷它是否正常工作,而不是簡單地將其固定在書中讀取的東西上,但未應用。

「優秀設計」的好處是它可以很好地與「代碼有動量」模型配合使用,具體而言,一個糟糕的設計一旦根深蒂固,難以重構或移除並用一個好的設計替代,所以你想要先從一個好的設計開始。這就是說,作爲一個必然結果,特別是如果你盲目地追隨許多關於建模和體系結構的書籍,你最終會遇到一些簡單的應用程序,這些應用程序在工程設計上是非常糟糕的。對於在應用程序中根本不存在或不存在的情況,有許多不必要的代碼。

遊戲在「完美」解決方案和「可行解決方案」之間找到了平衡點。

因此,閱讀您喜歡的所有書籍,並將其應用於對您有價值的東西,然後在您成長的過程中修復錯誤。不是每個人都應該從零開始,你想要「站在巨人的肩膀上」,但重要的是要理解巨人們首先要了解的原因,以便更好地理解爲什麼以及在什麼情況下他們提倡他們選擇。