[NA] Intro to databases book recommendation?

CJones

Final Approach
Joined
Mar 14, 2005
Messages
5,802
Location
Jawjuh
Display Name

Display name:
uHaveNoIdea
A coworker wants to learn databases and simple SQL. She wants to learn via a book. Does anybody have a suggestion for a good "nothing to simple SQL" type book? When I say "nothing" I mean, that I did a 5-minute crash course on where the "relational" part of "relational database" comes from by walking through a simple existing ERD.

Bonus points if it has step-by-step walk-through for installing server, creating database, populating database.

Double bonus points if it has simple walk-through for connecting that database to Excel and/or PHP.

I'm really fighting doing a hands-on teaching class on this one and would prefer to give them a book and let them teach themselves.
 
Codd and Date - Relational Database theory

Re: Install - Which RDBMS? Oracle, Sybase, Ingres, Postgres, Informix, mySQL, SQL Server, Paradox, dBaseIII, Foxbase...

:D yeah, kidding a little but you really kind of tossed out two different scenarios - Relational Database theory and Structured Query Language vs "now let's pick one and work with it."

Pick Oracle, download personal Oracle, a quick google search for SQL for Dummies, then odbc connection to Excel (or more technically correct, Excel ODBC for Oracle add-in)
 
Codd and Date - Relational Database theory

Re: Install - Which RDBMS? Oracle, Sybase, Ingres, Postgres, Informix, mySQL, SQL Server, Paradox, dBaseIII, Foxbase...

:D yeah, kidding a little but you really kind of tossed out two different scenarios - Relational Database theory and Structured Query Language vs "now let's pick one and work with it."

Pick Oracle, download personal Oracle, a quick google search for SQL for Dummies, then odbc connection to Excel (or more technically correct, Excel ODBC for Oracle add-in)

Yeah.. "I" know how to do it. But I don't have time to sit and explain it all to this other group, so I want a book to do it for me. :)

I agree - flavor/version choice is an entirely different discussion, so I made that one for them - you will use MySQL.

I just need to get them up to speed enough that they know enough to Google their way through what they are wanting to do. This won't be enterprise-level database structure.

I guess it would probably be two different books: (1) database theory - understanding what you want to store and why and (2) how to actually perform the crud operations (SQL) in a database.

So, what TWO books would be suggested for these topics?
 
I still stand by my 1st recommendation - it's the college textbook I used way back when ... but google shows me I must not recall the title quite correctly.
not even sure if this is right but looks close (book is home on the shelf - I am not)
http://bookboon.com/en/an-introduction-to-relational-database-theory-ebook
maybe this one?
http://www.amazon.com/The-Relational-Model-Database-Management/dp/0201141922


this looks basic yet at first glance, relatively complete
http://www.deeptraining.com/litwin/dbdesign/fundamentalsofrelationaldatabasedesign.aspx

re: mySQL - I haven't used it ... intended to for years, but Oracle is keeping me more than busy since I drew my first ERD to implement a system in release 5
 
20% of the knowledge can take you 80% of the way if you're just a programmatic SQL consumer and not a DBA.

http://www.forkosh.com/sqltut.pdf

^^ was always one of my favorite primers to hand people. 25% of that primer can make anyone an instant destroyer of data with the basic CRUD commands. :D
 
Thanks for the help, folks. I think I have enough to get them started down the path that they can at least Google their way into trouble.
 
RDBMS for dummies.

Replace RDBMS with whatever server you are planning on using. Seriously, the For Dummies books rule.
 
I would suggest SQLite for the database as it requires basically no setup and doesn't involve a running server process. You can get them running without all the adminy stuff.
 
I would suggest SQLite for the database as it requires basically no setup and doesn't involve a running server process. You can get them running without all the adminy stuff.

There is much it does very poorly though.
 
Codd and Date - Relational Database theory

Re: Install - Which RDBMS? Oracle, Sybase, Ingres, Postgres, Informix, mySQL, SQL Server, Paradox, dBaseIII, Foxbase...

:D yeah, kidding a little but you really kind of tossed out two different scenarios - Relational Database theory and Structured Query Language vs "now let's pick one and work with it."

Pick Oracle, download personal Oracle, a quick google search for SQL for Dummies, then odbc connection to Excel (or more technically correct, Excel ODBC for Oracle add-in)

I would never recommend Codd or Date to beginners trying to learn on their own. And the books I believe you're thinking of are

CJ Date, "An Introduction to Database Systems, Vol 1, 5th Ed", 1990. Then, of course, are the Jeff Ullman texts "Principles of Database Systems". Both may be far too theoretical for self-study. Ullman because he spends an enormous amount of time using set theory to explain relational databases, and Date because (sorry for the pun) it's dated.

As you pointed out, there's really 2 questions - 1) learning to program SQL and 2) learning to be a DBA. If the folks in question are familiar with installing either *nix or Windows, then installing Oracle Express or SQL lite shouldn't be a problem.

On the other hand, I'm available to do on-site consulting for both SQL and DBA for Oracle, MySQL and SQLServer. Very reasonable rates. I've been teaching SQL and database design for more than 10 years at local universities and such. Be delighted for the business since I was recently laid off from a DB gig with a Government organization.
 
Here's a review of "Head First SQL: Your Brain on SQL -- A Learner's Guide" from Amazon. I find that the Head Start books from O'Reilly are generally very good. It's a bit dated (2007), but nowhere near as much so as Date! :) There is an appendix on how to install MySQL.

Before I talk about Head First SQL, let me tell you about other database books I have used in the classroom. I teach an enterprise databases sequence (DBs I and II) at a tribal college in Montana. On the course evaluations for this sequence, students have a common complaint: "Liked the class. Hated the book.", "The book was painful to read.", "Please get a different book!"

Each year my colleagues and I are on the watch for a better, more engaging database book. We have tried three books over the past five years, but the difference between those books is like the difference between shades of grey. In the classroom, most of my time is spent mediating the daunting abstractness of those books or breaking down huge lumps of difficult technical material written in plodding and pedantic prose. This year a spot of color showed up: Head First SQL!

I discovered Head First SQL too late to use it as the primary text for my Fall quarter DBs class, but I liked it so much, I added it as an optional textbook for the quarter and told my students it would be the main textbook for the Winter quarter. I did so because the energy of the class was waning rapidly, and the book I had originally chosen was not helping. I needed to add some excitement to homework and lectures. Within two days of using Head First SQL, the classroom became a far more engaging environment.

I compiled this list for anyone interested in learning databases and SQL, especially anyone who teaches it.

Eleven Things I like about Head First SQL:

1. The book starts where my students start. The first questions my students have are questions of relevance: Why do I want to know this? What have I done before that's like this? What will this material add to my career and my life? Head First SQL starts by ushering the student through those questions: What is a database? Who cares about databases? What will a database do for me?

2. My students are able to read SQL, think SQL, and write SQL after the first chapter. Head First SQL starts students on the command-line, the same command-line professional database administrators use during 80-95% of their workday. My students start out with good command-line habits like using a DESCRIBE statement to view database structure and columns before writing a SELECT statement that references those columns.

3. The book invites my students to make mistakes and anticipates the most common mistakes I see students make. On quizzes, students who've dug into the book don't make those mistakes again.

4. The book's sequence of topics fits the way I teach and the way my students learn: queries come before design and theory. Head First SQL does not set out to be a comprehensive database design book, but it does an excellent job of immersing the learner in the critical thinking that goes into database design and table design strategy. I applaud Lynn Beighley and the Head First Team. They have laid an excellent foundation for the learner to smoothly transition into abstract database design concepts such as normalization, primary and foreign keys, entity-relationship diagrams (ERDs), and E.F. Codd's 12 principles of relational design.

5. Students don't read the book. They work the book. They play the book. They do the book.

6. Like Socrates, Head First SQL pushes my class and I to ask deeper questions about data, information, table design, normalization. Three different times during fall quarter, we had substantive arguments about which data types to use for certain columns. To hear my students using critical thinking and applying it to table design strategy is rewarding.

7. Like a guide, an outfitter, a trusted companion, HF SQL walks beside the student. The books I have used before talk down to students, talk over their heads, or just plain pontificate.

8. Theater in a database classroom? Yes. My students and I act out things like "Confessions of a NULL" -- fun, mysterious, memorable -- a great way to turn an abstract concept into a concrete and palpable one.

9. At conferences, committee meetings, training seminars, my colleagues and I talk about student engagement and the new "three Rs": rigor, relationships, and relevance. Using Head First SQL in my classroom changed my class noticeably, and I attribute that change to Head First's focus on those three Rs. My students started showing up early for class, spent more time in the lab outside of class, and performed far better on quizzes.

10. My quizzes and tests consist of sample tables and data. The open-ended questions on those tests ask students to write SQL to solve problems--a daunting task but the best way to assess whether students really "get" the concepts. In the past, students scores have ranged from 10% to 87%. A score of 92% was rare. A score of 95% almost unattainable. With Head First SQL, that range increased to between 70% and 98%. If that's not proof of Head First SQL's effectiveness, I don't know what is.

11. You will laugh your [body part here] off! And be warned: no matter what body part you substitute into the brackets, you will laugh several other body parts off as well.

I highly recommend this book to anyone teaching or learning SQL, relational database design, or MySQL.
 
I would never recommend Codd or Date to beginners trying to learn on their own. And the books I believe you're thinking of are

CJ Date, "An Introduction to Database Systems, Vol 1, 5th Ed", 1990. Then, of course, are the Jeff Ullman texts "Principles of Database Systems". Both may be far too theoretical for self-study. Ullman because he spends an enormous amount of time using set theory to explain relational databases, and Date because (sorry for the pun) it's dated.

Sorry, 1990 would be way too recent for the book I recalled. :D (altho I'm quite sure it IS printed on paper and not parchment nor stone) Guess I need to take a peek at the bookshelf when I get home. I loaned it out a time or two to folks who wanted to understand database design and got good feedback ... but they were already IT types, altho 3gl code toads...
 
Maybe I'm being cynical, but why would anyone need to read a book to learn the basics of SQL? Trial and error would do just fine, along with examining someone else's queries.

Tell 'em to start with simple one liners, then progress to T-SQL if that's their end state.

The rest is mostly theory and bs, which is only really useful to the architects and DBAs.
 
Maybe I'm being cynical, but why would anyone need to read a book to learn the basics of SQL? Trial and error would do just fine, along with examining someone else's queries.

Tell 'em to start with simple one liners, then progress to T-SQL if that's their end state.

The rest is mostly theory and bs, which is only really useful to the architects and DBAs.

I'm with you on the SQL.
RDB, not so much. There are a lot of people who *think* they can design databases ... :eek:
 
Maybe I'm being cynical, but why would anyone need to read a book to learn the basics of SQL? Trial and error would do just fine, along with examining someone else's queries.

Tell 'em to start with simple one liners, then progress to T-SQL if that's their end state.

The rest is mostly theory and bs, which is only really useful to the architects and DBAs.

That's what I thought at first, until I started talking to one of them. They have no clue how to install a database sever, how to create a database, what data they want to track, how they want to interface with the database, NOTHING. That's why I am being very hands-off on this one - so I don't end up doing the whole dang project myself.
 
That's what I thought at first, until I started talking to one of them. They have no clue how to install a database sever, how to create a database, what data they want to track, how they want to interface with the database, NOTHING. That's why I am being very hands-off on this one - so I don't end up doing the whole dang project myself.

You know you're going to wind up doing it. It always works that way.
 
Maybe I'm being cynical, but why would anyone need to read a book to learn the basics of SQL? Trial and error would do just fine, along with examining someone else's queries.

Tell 'em to start with simple one liners, then progress to T-SQL if that's their end state.

The rest is mostly theory and bs, which is only really useful to the architects and DBAs.
That is why most programmers are horrible at writing queries or designing a relational database. Because they think the theory is bs. The theory matters when the whole engine is built on that theory and the data should be as well.
 
That is why most programmers are horrible at writing queries or designing a relational database. Because they think the theory is bs. The theory matters when the whole engine is built on that theory and the data should be as well.

I wouldn't call someone who writes SQL queries a "programmer," (nor would I call someone who creates websites in pure HTML) but your point is taken.

If you need to write a report, however, knowing the difference between DML and DDL is overkill.

Now, if you're the one normalizing the database, optimizing queries, creating sprocs and elaborate stuff that the DBA or an architect should be doing, you should know the theory, otherwise you create a tangled mess that just makes things worse.
 
I wouldn't call someone who writes SQL queries a "programmer," (nor would I call someone who creates websites in pure HTML) but your point is taken.

If you need to write a report, however, knowing the difference between DML and DDL is overkill.

Now, if you're the one normalizing the database, optimizing queries, creating sprocs and elaborate stuff that the DBA or an architect should be doing, you should know the theory, otherwise you create a tangled mess that just makes things worse.
And it sounds to me like that is exactly what they will be doing. So having at least a basic understanding of that would be a good thing. Of course, if it's slow, they can always throw more hardware at it. If they have deadlocks or inconsistent data, OTOH, ...
 
And it sounds to me like that is exactly what they will be doing. So having at least a basic understanding of that would be a good thing. Of course, if it's slow, they can always throw more hardware at it. If they have deadlocks or inconsistent data, OTOH, ...


Pfffft... If they actually get a MySQL server up and running and are able to read/write ANYTHING to that database, that will be quite the accomplishment for that group. They are light years away from worrying about hardware and other high-volume, transactional type constraints.

Unfortunately, their boss has seen some of the more advanced things that my group has done and thinks that "Well, we should do THAT!", not realizing that it has several years worth of research and failed attempts to get to where we are now. BUT, he put it in their annual goals to have something up and running by October. :mad2:
 
Maybe I'm being cynical, but why would anyone need to read a book to learn the basics of SQL? Trial and error would do just fine, along with examining someone else's queries.

Tell 'em to start with simple one liners, then progress to T-SQL if that's their end state.

The rest is mostly theory and bs, which is only really useful to the architects and DBAs.

Mostly so they don't do a SELECT ALL FROM * on my damned Production system during the business day. LOL!
 
Mostly so they don't do a SELECT ALL FROM * on my damned Production system during the business day. LOL!


Really? My worst noob fear involves UPDATE table with no filter criteria or limit threshold. Let them select all they like, but updates give me the chills.
 
Really? My worst noob fear involves UPDATE table with no filter criteria or limit threshold. Let them select all they like, but updates give me the chills.
Actually, any modifications. UPDATE, DELETE, TRUNC. Heck, even a simple INSERT can introduce data inconsistencies that will cause problems! Generally, don't give users accounts that have any data modification rights, including calling stored procedures, until you know they understand the ramifications and at least appear as if they'll be responsible. A horrendous query can be killed if it is causing performance issues.
 
Really? My worst noob fear involves UPDATE table with no filter criteria or limit threshold. Let them select all they like, but updates give me the chills.

My best mistake:

DELETE FROM table
WHERE blahblahblah.


I selected "DELETE FROM table" but did not select the WHERE clause. Then I hit F5 in SSMS. Deleted everything. From production. That was fun.

I'm man enough to admit that it was my mistake.
 
My best mistake:

DELETE FROM table
WHERE blahblahblah.


I selected "DELETE FROM table" but did not select the WHERE clause. Then I hit F5 in SSMS. Deleted everything. From production. That was fun.

I'm man enough to admit that it was my mistake.
Your problem was having autocommit turned on!

Autocommit. Just say no!
 
Really? My worst noob fear involves UPDATE table with no filter criteria or limit threshold. Let them select all they like, but updates give me the chills.

They aren't allowed that much access. :)

All that "adminy stuff" as someone called it .. up there somewhere... :)
 
I like MYSQL for this exact reason - i-am-a-dummy is fantastic.
 
Go to coursera.com and search for "Database" - there is an awesome archived Database theory course that may have another "live" session here soon. It smokes any book you can find, has great videos and teaches you everything you need to know.

Once you complete that, you can take some of the big data coursera.com courses and dominate the market..

I'm a DBA for my day job..

oh yeah, and subscribe to safaribooks.com - having all those books online for a few bucks a month is certainly the best tool anyone can ask for.
 
Back
Top