How to learn database management system on own?

Question

I want to learn database management system on my own,would you like to suggest me some tips

Answer 1

Try to do some simple applications using databases in your favorite programming language. Learn by doing. And when you get a problem, read the DBMS-documentation and learn.

Answer 2

http://video.stoimen.com/2009/04/12/zend-framework-zend_db-tutorial/ perhaps

Answer 3

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...

Answer 4

Don't try what others have suggested to "learn by doing".

That is monkey-style learning.

Human intelligence/knowledge has gone far beyond the point where for the most specimens of the species, it is still possible/productive to "learn by making mistakes".

Trust me, if you just go down the "learn-exclusively-by-doing" path, the only thing you will end up doing is repeating the same mistakes that millions have already made before you.

The only thing suggested in the other answers here that I can second, is "buy a good book". But "being a good book" does mean that it should give a thorough coverage of the theory. Otherwise you are likely to end up building database applications like the Romans built their aquaducts : by overdoing certain things "just to be on the safe side".

(That is exactly what those Roman engineers did when they built those monuments that often still stand to this very day, in the absence of any knowledge/understanding of things such as gravity and the strenght of concrete spannings : they threw in a few dozens of extra bricks, without really knowing precisely whether they were really needed or not. But their world wasn't as economically competitive as ours.)

Answer 5

I too suggest you get a good book (or more, performance tuning is so complex a subject, it usually is covered in a separate book) on one of the major databases (whichever one you choose to learn first).

Subjects you need to learn are (at a minimum):

Querying including the use of joins (if you do not thoroughly understand joins, you can't do anything except the simplest of queries or you may get a result set that is incorrect. You can't learn too much about joins.

If data is to have meaning, you must understand how to tell if the results you are producing are the correct results.

Normalization - if you don't understand normalization, you cannot design an effective relational database. Learn also about primary and foreign keys. Do not ever design a database table without a way to uniquely identify a record.

Set theory - you have to learn to think in terms of manipulating groups of records not looping through records one at a time.

Performance - if you can't get results out in a timely manner, no one will use your software. Design in databases should consider performance carefully as databases as not so easy to refactor when they perform badly and there are many techiniques that are known to be faster than other techniques that produce the same result. You should learn what these are and not use the poorly performing ones because you find them easier to understand.

Data integrity - if you can't rely on the data to be correct, you do not have a useful database. You should know how to ensure that data has the correct values and relationships to other data. This also includes using the correct data type (Store dates as a datetime or date data type for instance).

Security - including protecting against both SQL injection attacks and possible internal fraud.

Constraints and triggers and stored procs and user-defined functions.

Finally, do not use object-oriented thinking in database design. Relational databases often use tools and techniques that you would not use in Object-oriented programming. It is a a different subject and thus subject to different rules and constraints.

Answer 6

Get a good Modeling and Design book before you do anything else.

Answer 7

I'm not a big fan of learning without an actual application to which it's applied.

Books on Modeling and Design are all well and good, but all of those suggestions need to be placed in the context of an application.

I have seen my share of "horrible" data models that work fine for the application. While there's a purity in having a "good design", the simple truth is that not everything needs a "good design". Or, better said, a "good design" for one application may be completely different than one for another.

Many simple applications perform fine with "stupid", "dumb", "bad" designs.

A lot of learning happens from doing the wrong thing.

To paraphrase Thomas Edison, "Progress, I've made lots of progress. I know a thousand things that don't work."

A lot of things are easier to learn when they're being applied in the "real world", and then judged against that metric of whether or not it's working or not vs simply holding it up to something read in a book, but unapplied.

The benefit of "good design" is that it works well with the "Code has Momentum" meme, specifically that a bad design, once entrenched, is difficult to refactor or remove and replace with a good design, so you want to start with a good design up front.

That said, as a corollary, especially if you follow blindly many books on modeling and architecture, you end up with simple applications that are terrible over engineered. With a lot of unnecessary code for circumstances that simply do not, and will not, exist in the application.

The game is finding the balance between "the perfect" solution, and the "workable solution".

So, read all the books you like, but also apply it to something of value to you, and then fix your errors as you grow. Not everyone should start at ground zero, you want to "stand on the shoulder of giants", but it's important to understand, also, the paths the giants took in the first place to better appreciate why, and in what situations, they advocate their choices.