Good "introductory" book on RDB/SQL?
-
I currently don't "use nor need to use" databases much beyond very basic stuff, but I do think that a basic knowledge of the field may be a good idea as a dev. Since TDWTF seems to have a quite large DB-oriented user base (probably because of Alex), I turn to you for inquiries about a good book on DBs, RDBMS, SQL, and all that kind of stuff.
What I don't want: to be a DBA
What I'd like: a good book that gets up from virtually no DB knowledge (I think it'd be a good idea for me to redo everything from ground up, so consider that there is no current knowledge of the field at all).
I don't mind learning the theories behind DBs (it would actually be a nice thing), I don't mind more hands-on stuff either.
Any suggestion? (I seem to remember a fairly good /. of " The Art of SQL", but it was a slashdot review so...)
-
[quote user="masklinn"]
I currently don't "use nor need to use" databases much beyond very basic stuff, but I do think that a basic knowledge of the field may be a good idea as a dev. Since TDWTF seems to have a quite large DB-oriented user base (probably because of Alex), I turn to you for inquiries about a good book on DBs, RDBMS, SQL, and all that kind of stuff.
[/quote]
More likely its because they are everywhere. Any place you have datum related to other data, there's a good chance there is some RDBMS driving it (or should be IMO). Its good that you want to learn database stuff since it will open up many more opportunities for you.
What I don't want: to be a DBA
Me neither, but in the Microsoft world it is common to have dba/developer roles. In the Oracle/DB2 realm that's rare. The basic concepts are useful though, just like a basic understanding of networks/operating systems are valuable for developers.
What I'd like: a good book that gets up from virtually no DB knowledge (I think it'd be a good idea for me to redo everything from ground up, so consider that there is no current knowledge of the field at all).
I don't mind learning the theories behind DBs (it would actually be a nice thing), I don't mind more hands-on stuff either.
Any suggestion? (I seem to remember a fairly good /. of " The Art of SQL", but it was a slashdot review so...)
That's a little more tricky since the database field is very large. You have the high level relational models, set theory, ER diagrams etc. SQL is just one small part of the puzzle. On top of that you have the various levels of normalization and the difference between transactional systems vs warehouse/decision support systems.
For general database theory, I'd recommend the following
Inside Relational Databases by Mark Whithorn
For SQL itself just play around with various databases. Each database has enough syntactic differences that you'll need it anyways. The basic selects, updates, and inserts will be similiar enough, but variables, cursors, autonumbering etc will be different.
From my experience, I never truly understood databases and relational theory until I became involved with building my first datawarehouse. For those, anything from Bill Inmon or Ralph Kimball is a good bet, although Kimball is more popular and the approach I took. Kimball's articles and books do a good job at describing the issues with transactional systems and how datawarehouses resolve them. I personally love the warehousing aspect of databases, because I honestly believe the one system fits all is a pipe dream. Warehousing is all about turning data from disparate systems into truly valuable information. One thing to note is that once you go down the warehousing road, you need to throw out all your transactional system preconceptions out, otherwise you will fail.
I'm one for learning from doing. I can read all the books out there but it doesn't sink in until I do it. Coming up with a transactional pet project would be a good start.
-
Careful. Learning from doing is normally an excellent idea. However, SQL is a weird animal. Most people build fully functional "pet" systems and still make every mistake in the book. The fact that the system works fine only reinforces the bad techniques.
I would concentrate on reports first. Get familiar with the Northwind sample that comes with all of Microsoft's products and try to get some results from it. After getting a good handle on querying, work on designing a "pet" project. After basic design, then worry about the stuff that 90% of the devs out there get wrong -- database integrity, locking, and optimization.
-
The obvious answer (for the theory side) is "An Introduction to Database Systems" by Chris Date. At risk of just repeating another post, it's nice to have a 'toy' schema like Northwind to play with.
-
[quote user="jsmith"]
Careful. Learning from doing is normally an excellent idea. However, SQL is a weird animal. Most people build fully functional "pet" systems and still make every mistake in the book. The fact that the system works fine only reinforces the bad techniques.
I would concentrate on reports first. Get familiar with the Northwind sample that comes with all of Microsoft's products and try to get some results from it. After getting a good handle on querying, work on designing a "pet" project. After basic design, then worry about the stuff that 90% of the devs out there get wrong -- database integrity, locking, and optimization.
[/quote]
Good catch on relying on entirely learning from doing. The pet project generally doesn't need to deal with the problems associated with multi-user environments (concurrency and locking). IMO, learning from doing is good for the basics as far as how do joins work, whats the difference of wheres/having clauses, etc.. As soon as you graduate to more complex scenarios such as transactions and multi-user settings, you need to either do a lot of reading/research or work with an experienced mentor.
-
My DB use has been limited to simple tasks, and I've never had the chance/displeasure of working with a proper RDBMS. However, inspired by this post, I went and dug up my college DB class book. I don't remember making it too far into the book when I took the class, but looking at it now it does cover a huge range of quite interesting topics. I'm not going to make any recommendations, however, because I just don't know enough about the topic. I just wanted to say that I'm glad that I picked up the book again, and that I'm looking forward to learning some more about advanced SQL and DB internals.
FWIW, the book we used is "Database Management Systems" by Ramakrishnan and Gehrke, published by McGraw Hill.
