Managing and Using MySQL: Second Edition

Geekboy(Wizard) writes: "MySQL has been used as a database for many sites and products. The U.S. Census Bureau, Slashdot, Yahoo Finance, and many other high-traffic web sites use MySQL for their database needs. It is a popular choice for databases, as it is GPL'd and thus free from costly licenses. If you need to use it in a proprietary application, you can purchase a non-GPL'd version from MySQL AB." Read on for Geekboy's review of Managing and Using MySQL: Second Edition, which he describes as "the only thing you /need/ to make a usable database." Managing and Using MySQL: Second Edition author George Reese, Randy Jay Yarger and Tim King, with Hugh E. Williams pages 425 publisher O'Reilly & Associates rating 9/10 reviewer Peter Hessler ISBN 0596002114 summary Step by step tutorial to using MySQL, with included tools, and your favorites.

Managing and Using MySQL: 2nd Edition assumes that the reader has a little knowledge of databases, although some of the commands are difficult to get your head around until you have a database to test them on. Sample commands, and output for them are shown in the book, but a sample database isn't shown until chapter 9. MySQL took me through 'MySQL land' with the greatest of ease. Aside from the lack of a test database in the beginning, everything was very well laid out. It started with the basics, and worked up to full implementation and administration.

Part I introduces the reader to MySQL. It begins with a nice history, design elements, features and what you would want to use MySQL with. Nicely detailed instructions for downloading, and installing the current version. Information is provided for Unix, and Windows systems, with examples for FreeBSD 4 and Windows 2000. Basic SQL commands are presented, with sample queries and relevant results.

Part II introduces the reader to tuning, securing and designing the database. Several pitfalls are described, along with instructions for avoiding them. The realm of tuning is divided into application tuning, database tuning, and operating system/hardware tuning. Security is discussed from all aspects, but a database that has security concerns will need extensive testing and evaluation. Database design starts with the design on paper, with both the theoretical, and practical aspects. Once the paper design is drawn out, MySQL assists the reader through the actual making of the database.

Part III describes integrating the database into your favorite programming/scripting language. In the opening paragraph of chapter 12, The C API, the author states: "In this book, we examine several different programming languages: Python, Java, Perl, PHP and C. Among these languages, C is by far the most challenging." The information was presented in a way that readers who are new to C would have small difficulties with, and that intermediate and advanced users would find quite useful. The authors presented enough information, that I was able to write programs that interfaced with MySQL in less than 10 minutes. Perl scripts are presented in the same way. Knowledge of the language you will be integrating MySQL into is necessary, but the book presents and explains the rest of the information.

Part IV is the reference portion of the book. All great books that teach contain a reference section, and this book is no exception. The basic SQL syntax and command set are described, as well as the data types, numeric, string, date, and complex. Operations and functions are explained, as well as their order preference. The PHP API, the C API, and the Python DB-API are also fleshed out in nice detail.

Overall, the authors have an excellent introduction to SQL databases, and MySQL. Full examples are included for each topic, with full explanations. The only things I would change, would be to have a sample database in the beginning of the book, and to have a copy of that database online.

Table of Contents
Part I (Chapters 1 - 4) Introduction
1 MySQL
2 Installation
3 SQL According to MySQL
4 Database Administration
Part II (Chapters 5 - 7) MySQL Administration
5 Performance Turning
6 Security
7 Database Design
Part III (Chapters 8 - 14) MySQL Programming
8 Database Applications
9 Perl
10 Python
11 PHP
12 C API
13 Java
14 Extending MySQL
Part IV (Chapters 15 - 20) MySQL Reference
15 SQL Syntax for MySQL
16 MySQL Data Types
17 Operations and Functions
18 MySQL PHP API Reference
19 C Reference
20 The Python DB-API
Index

You can purchase Managing and Using MySQL: Second Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.

Comments

O'Reilly

[Beatbyte]

I've been reading about 100 pages a night of this book and its awesome. Personally I'm using it for web applications and if anyone of you are doing the same, also pick up Web Database Applications with PHP & MySQL (ISBN: 0-596-00041-3). Complimenting each other in the very best way.

Every time I read an O'Reilly book it reminds me of why they're the only thing in my book case (of the computer nerdish-tech know how sort).

Awesome stuff.

Re:MySQL

[Anonymous Cowrad]

This article isn't about MYSQL, it's about a book about MySQL.

Stored procedures are terribly simple to implement in whatever's driving your database, so there's really no point in bloating MySQL with them.

If you're going to point out the lack of transaction support, have a look at this.

If you're just going for early post E-Z Karma, well done.

Great, now we're going to have a war...

[Wee]

I can hear it now: "MySQL sucks", "It doesn't have triggers|rollbacks|stored procedures|nested selects", "It isn't PostgreSQL|Sybase|Oracle", "It's not a real RDBMS", "It uses a bastardized version of SQL", "It stole my woman", "It owes me money", "It called the Pope bad names", blah blah blah. Guess what? It doesn't have those "features" for a reason! MySQL was meant to be fast and small, that's it. It was meant to fill in the gaps left by mSQL and to drive web sites (quickly). It's a feature-rich, glorified flat file, ok? And it fills its intended role quite well.

You can't even mention MySQL without the know-it-alls coming out of the woodwork. You'd think the mere mention of MySQL offends their sense of personal or national pride or something. If MySQL isn't your taste, doesn't meet your needs, isn't robust enough, whatever, then don't use it. Use PostreSQL or another RDBMS. Why people continue to begrudge other's use of MySQL is beyond me...

-B

Re:Great, now we're going to have a war...

[MattRog]

I would agree to that if it wasn't the de-facto open source DBMS, and if the MySQL marketing-machine didn't *scream* otherwise.

[OT] Can anything get a rating besides 9?

[ajakk]

I thought it was just me at first, but do any books that get a rating that is not 9 get posted? I went to the book section and checked out the most recent reviews. Of the last nine books reviewed, eight of them got a nine, and the other got five stars (out of five I assume). The two book reviews before that (both in the Java meets XP subject) got 7's.

I would like to see someone review a book that isn't very good, and tell us why. It almost seems that these great book reviews are being pushed so someone can make some bucks through an affiliate program.

Re:if only....

[mustangdavis]

Seriosly, stored procedures would be nice, but they would take away MySQL's edge on Postgres .... and that is SPEED!!!!!! I hope they NEVER put in stored procedures!!! It would bloat things too much and make MySQL = Postgres 9or worse) in every regard! MySQL could use nested selects and such (for those times when I'm feeling lazy and want the DB to do all te work for me), but stored procedures would kill MySQL!!!



To everyone concered about stored procedures: GO USE POSTGRES!!!!

To everyone that needs a FAST database:Use MySQL!!

To everyone that has too much money: Go buy Oracle

I hope this ends this silly string of people whining about stored procedures.

I'm not sure which niche MySQL is supposed to fill

[cartman]

I regularly hear the comment the MySQL lacks features on purpose, because it occupies a niche that does not require those features. It is a "lightweight" database and it supposedly fills that role well.

I have never been able to tell which niche MySQL is supposed to occupy. Is there really a niche where it doesn't matter if the database is corrupted? Is there really any niche where it doesn't matter if transactional integrity isn't maintained? MySQL does not provide any recovery functionality!

I can understand the point in lightweight software. But ACID features and transactions are at the very core of what constitutes a database; they are not "bloatware features" like the microsoft paperclip. Having a database without data integrity is like having a word processor which can't save files. It doesn't matter how lightweight it is.

Re:MySQL

[Anonymous Coward]

Have you ever run complex financial reports (i.e. the kind suitable for quarterly filings for publicly traded companies) that span several business units for a company with thousands of employees? Depending on the types of businesses involved, that can be a tremendous amount of data to go through to build those reports. Think retail where you can be as detailed as each of the thousands of daily transactions at each store location; or at best daily logs from each store including IO from the bank accounts for reconciliation, receivings and orders with your numerous suppliers, the list goes on. Many large companies deal with amounts of data in as much of a real time fashion as their IT departments can provide -- to a degree that would have been practically inconceivable just 10 years ago.

When you leave the little league and you're dealing with hundreds of millions of dollars worth of business each month -- not everything can be JOIN'ed. Accounting is a very tricky subject, and you can't always make a single clean query to your database to get the data out right -- no matter how beautiful the design is. Accounting laws change, business practices change, your company enters into completely new lines of business with very different regulations; a whole host of things make providing the data to the accountants a very "fun" job.

Sure, the situation in the post you replied to may not be "common" for your line of work, but that just means you have the luxury of not doing my job (or the guy's who posted it -- I can feel his/her pain). ;) And sometimes, yeah, the database was not designed well, and even though it's not your fault (trust me, work for a large multinational behemoth and you will almost certainly have to support some really brain dead software at some point) you don't have the power to change it -- just the paychecks telling you to deal with it.