2009-04-19 22 views
3

我不確定這個問題是否有意義。但是我知道mysql的所有基本CRUD命令。可能多一些(外鍵等)。但是有太多的書籍寫在mysql/dbms上。我可以寫出體面的查詢,並獲得我想要的所有結果。也許他們不是最高效的,但它是有效的。那是因爲我的應用程序還沒有Facebook,所以我不得不擔心優化。或者我?高級MySQL我是否錯過了這一點?

我在這裏錯過了什麼?我還應該知道什麼?

非常感謝。

回答

5

我還應該做什麼知道?關係理論的

  • 更深入的瞭解,所以你寫出更好的SQL。我目前正在享受「SQL and Relational Theory」,這是世界頂尖的關係模型專家C. J. Date的新書。

  • 執行和監督security - SQL注入肯定,但OWASPSANS.org或書籍涵蓋像其他問題 「19 Deadly Sins of Software Security。」這是一個非特定於SQL的廣泛話題,但我認爲每個軟件開發者都有責任去學習這些東西。

  • 性能測量和monitoring - 如何知道何時達到所在的位置需要學習優化技術?

  • I18N, L10N, character sets

  • 數據庫維護和恢復 - backups, repair

  • Replication,clusteringproxying

  • 部署和升級技術 - 如何在不中斷服務的情況下將更改應用到正在運行的應用程序或站點。

  • 編寫可與多個RDBMS品牌一起使用的或多或少的可移植SQL。至少要了解如果需要支持另一個品牌,需要重新編寫的內容。

  • 如何以及何時採用對象關係映射框架。

  • 如何以及何時採用non-relational databases。 SQL是最好的通用數據管理範例,但還有其他更專門用於特定任務的技術。

0

如果您足夠了解要做什麼需要做的事情,那麼您現在知道了足夠的。然而,C.J. Date的Introduction to Database Systems是由該領域先驅(以及其他類型的數據庫系統)編寫的關係數據庫的傑出討論。

1

無論如何你應該擔心優化imho。當然如果現在你只有10個人在使用你的應用程序,這不是問題,但是在將來如果用戶羣增長的話,重寫數據庫結構確實是一種「痛苦」,特別是如果在你的代碼中正在使用沒有數據庫抽象的原始查詢。

1

高級MySQL可能不僅僅是爲查詢操作編寫查詢。有時您需要進行優化或各種維護過程,這些過程需要熟悉您正在使用的DBMS的相關知識。如果您處理中小型應用程序,您可能不會擔心查詢的性能以及數據庫設計的穩健性和效率,但對於高度可擴展的應用程序,所有這些都是您必須考慮的因素。

1

很好地瞭解CRUD語法。我建議你不要再去理解關係設計,主鍵和候選鍵,索引等。這些是對所有關係數據庫都有意義的主題,而不僅僅是MySQL。

0

一般來說,有大量的mysql和其他RDBMS系統的功能人們不知道。這很好,因爲你可以很好地獲得一部分功能,但要處理難題或成爲一名優秀的DBA,需要學習大量的東西。當人們談論數據庫上的Advanced X時,這就是所謂的事物類型。

要回答你的問題,找出其他什麼功能和工具都不是壞主意。你可能會找到更好的方法來解決你自己的問題,併爲解決別人的問題培養一套更好的技能。我也完全同意其他答案,建議你提高對高層次主題的瞭解,知道如何使好的分貝設計非常重要。

6

不成熟的優化是萬惡之源。專注於設計適當和合乎邏輯的數據庫結構並正確編制索引,這將使您走得更遠。修改寫得不好的查詢總比修改設計不良的數據庫結構容易。

在我看來,使用您擁有的查詢並在需要優化時進行優化。查詢的內容是什麼,而不是集中於使它們安全(請參閱sql注入)。

+0

我同意數據庫設計和結構比查詢優化重要得多 - 而且通常設計糟糕的數據庫意味着查詢無法優化(至少以一種有意義的方式......)。 – BrynJ 2009-04-19 16:35:00

+1

你忘了說「學習正常形式」。 – Kalium 2009-04-19 18:18:29

1

數據庫不僅僅是「放置東西的地方」。一旦你意識到這一點,你將開始充分利用它們的潛力。

0

哦,現在我明白了(問題)。我以爲你的意思是「結合'高級'和'MySQL'的意義何在?」。:-)

如果您必須使用MySQL來完成您的工作,那麼您最好逐步深入瞭解它,尤其是缺點和疑難雜症,以及其他人在工作時可能會對事情做出假設實際上並沒有解決問題。

現在,我的「巨魔」:如果這只是你,請使用一些更強大的東西。我不是MicroSoft的粉絲,但他們的確使用SQL Server的啓動成本相當低,假設你正在使用Windows。更好的是,如果你正在使用* nix服務器,你可以試試PostgreSQL。他們對於正確實現ROLLBACK,事務隔離,外鍵參照完整性,視圖,函數(也稱爲存儲過程)等古怪的小東西已經相當嚴肅了很多年。 MySQL已經改進了多年,但仍然(恕我直言)有點不成熟。 2000年左右,我對它的印象是「xBASE的可靠性與SQL界面的輕鬆性」。 (我不是SQL語言本身的粉絲 - 也許我只是太老了,不能真正熱身爲「唯一可行的方法」)

0

我避免MySQL像一個壞的流感錯誤,但我可以在這裏添加一些見解。 MySQL的「高級」部分將涉及的一個領域是自定義。

一般來說,SQL一般都涉及到MySQL並不是開箱即用,或者可以自定義的。我們公司使用完整的存儲過程實現和地理空間查詢作爲兩個示例。

高級將涉及良好的定製技能,並體驗添加和使用自定義或加載項。任何使MySQL成爲更多企業的東西。

相關問題