MySQL Cookbook

chuck

贡献于2012-07-04

字数:0 关键词: MySQL 数据库服务器 SQL

MySQL Cookbook By Paul DuBois Publisher : O'Reilly Pub Date : October 2002 ISBN : 0-596-00145-2 Pages : 1022 MySQL Cookbook provides a unique problem-and-solution format that offers practical examples for everyday programming dilemmas. For every problem addressed in the book, there's a worked-out solution or "recipe" -- short, focused pieces of code that you can insert directly into your applications. More than a collection of cut-and-paste code, this book explanation how and why the code works, so you can learn to adapt the techniques to similar situations. Copyright Preface MySQL APIs Used in This Book Who This Book Is For What's in This Book Platform Notes Conventions Used in This Book The Companion Web Site Comments and Questions Additional Resources Acknowledgments Chapter 1. Using the mysql Client Program Section 1.1. Introduction Section 1.2. Setting Up a MySQL User Account Section 1.3. Creating a Database and a Sample Table Section 1.4. Starting and Terminating mysql Section 1.5. Specifying Connection Parameters by Using Option Files Section 1.6. Protecting Option Files Section 1.7. Mixing Command-Line and Option File Parameters Section 1.8. What to Do if mysql Cannot Be Found Section 1.9. Setting Environment Variables Section 1.10. Issuing Queries Section 1.11. Selecting a Database Section 1.12. Canceling a Partially Entered Query Section 1.13. Repeating and Editing Queries Section 1.14. Using Auto-Completion for Database and Table Names Section 1.15. Using SQL Variables in Queries Section 1.16. Telling mysql to Read Queries from a File Section 1.17. Telling mysql to Read Queries from Other Programs Section 1.18. Specifying Queries on the Command Line Section 1.19. Using Copy and Paste as a mysql Input Source Section 1.20. Preventing Query Output from Scrolling off the Screen Section 1.21. Sending Query Output to a File or to a Program Section 1.22. Selecting Tabular or Tab-Delimited Query Output Format Section 1.23. Specifying Arbitrary Output Column Delimiters Section 1.24. Producing HTML Output Section 1.25. Producing XML Output Section 1.26. Suppressing Column Headings in Query Output Section 1.27. Numbering Query Output Lines Section 1.28. Making Long Output Lines More Readable Section 1.29. Controlling mysql's Verbosity Level Section 1.30. Logging Interactive mysql Sessions Section 1.31. Creating mysql Scripts from Previously Executed Queries Section 1.32. Using mysql as a Calculator Section 1.33. Using mysql in Shell Scripts Chapter 2. Writing MySQL-Based Programs Section 2.1. Introduction Section 2.2. Connecting to the MySQL Server, Selecting a Database, and Disconnecting Section 2.3. Checking for Errors Section 2.4. Writing Library Files Section 2.5. Issuing Queries and Retrieving Results Section 2.6. Moving Around Within a Result Set Section 2.7. Using Prepared Statements and Placeholders in Queries Section 2.8. Including Special Characters and NULL Values in Queries Section 2.9. Handling NULL Values in Result Sets Section 2.10. Writing an Object-Oriented MySQL Interface for PHP Section 2.11. Ways of Obtaining Connection Parameters Section 2.12. Conclusion and Words of Advice Chapter 3. Record Selection Techniques Section 3.1. Introduction Section 3.2. Specifying Which Columns to Display Section 3.3. Avoiding Output Column Order Problems When Writing Programs Section 3.4. Giving Names to Output Columns Section 3.5. Using Column Aliases to Make Programs Easier to Write Section 3.6. Combining Columns to Construct Composite Values Section 3.7. Specifying Which Rows to Select Section 3.8. WHERE Clauses and Column Aliases Section 3.9. Displaying Comparisons to Find Out How Something Works Section 3.10. Reversing or Negating Query Conditions Section 3.11. Removing Duplicate Rows Section 3.12. Working with NULL Values Section 3.13. Negating a Condition on a Column That Contains NULL Values Section 3.14. Writing Comparisons Involving NULL in Programs Section 3.15. Mapping NULL Values to Other Values for Display Section 3.16. Sorting a Result Set Section 3.17. Selecting Records from the Beginning or End of a Result Set Section 3.18. Pulling a Section from the Middle of a Result Set Section 3.19. Choosing Appropriate LIMIT Values Section 3.20. Calculating LIMIT Values from Expressions Section 3.21. What to Do When LIMIT Requires the "Wrong" Sort Order Section 3.22. Selecting a Result Set into an Existing Table Section 3.23. Creating a Destination Table on the Fly from a Result Set Section 3.24. Moving Records Between Tables Safely Section 3.25. Creating Temporary Tables Section 3.26. Cloning a Table Exactly Section 3.27. Generating Unique Table Names Chapter 4. Working with Strings Section 4.1. Introduction Section 4.2. Writing Strings That Include Quotes or Special Characters Section 4.3. Preserving Trailing Spaces in String Columns Section 4.4. Testing String Equality or Relative Ordering Section 4.5. Decomposing or Combining Strings Section 4.6. Checking Whether a String Contains a Substring Section 4.7. Pattern Matching with SQL Patterns Section 4.8. Pattern Matching with Regular Expressions Section 4.9. Matching Pattern Metacharacters Literally Section 4.10. Controlling Case Sensitivity in String Comparisons Section 4.11. Controlling Case Sensitivity in Pattern Matching Section 4.12. Using FULLTEXT Searches Section 4.13. Using a FULLTEXT Search with Short Words Section 4.14. Requiring or Excluding FULLTEXT Search Words Section 4.15. Performing Phrase Searches with a FULLTEXT Index Chapter 5. Working with Dates and Times Section 5.1. Introduction Section 5.2. Changing MySQL's Date Format Section 5.3. Telling MySQL How to Display Dates or Times Section 5.4. Determining the Current Date or Time Section 5.5. Decomposing Dates and Times Using Formatting Functions Section 5.6. Decomposing Dates or Times Using Component-Extraction Functions Section 5.7. Decomposing Dates or Times Using String Functions Section 5.8. Synthesizing Dates or Times Using Formatting Functions Section 5.9. Synthesizing Dates or Times Using Component-Extraction Functions Section 5.10. Combining a Date and a Time into a Date-and-Time Value Section 5.11. Converting Between Times and Seconds Section 5.12. Converting Between Dates and Days Section 5.13. Converting Between Date-and-Time Values and Seconds Section 5.14. Adding a Temporal Interval to a Time Section 5.15. Calculating Intervals Between Times Section 5.16. Breaking Down Time Intervals into Components Section 5.17. Adding a Temporal Interval to a Date Section 5.18. Calculating Intervals Between Dates Section 5.19. Canonizing Not-Quite-ISO Date Strings Section 5.20. Calculating Ages Section 5.21. Shifting Dates by a Known Amount Section 5.22. Finding First and Last Days of Months Section 5.23. Finding the Length of a Month Section 5.24. Calculating One Date from Another by Substring Replacement Section 5.25. Finding the Day of the Week for a Date Section 5.26. Finding Dates for Days of the Current Week Section 5.27. Finding Dates for Weekdays of Other Weeks Section 5.28. Performing Leap Year Calculations Section 5.29. Treating Dates or Times as Numbers Section 5.30. Forcing MySQL to Treat Strings as Temporal Values Section 5.31. Selecting Records Based on Their Temporal Characteristics Section 5.32. Using TIMESTAMP Values Section 5.33. Recording a Row's Last Modification Time Section 5.34. Recording a Row's Creation Time Section 5.35. Performing Calculations with TIMESTAMP Values Section 5.36. Displaying TIMESTAMP Values in Readable Form Chapter 6. Sorting Query Results Section 6.1. Introduction Section 6.2. Using ORDER BY to Sort Query Results Section 6.3. Sorting Subsets of a Table Section 6.4. Sorting Expression Results Section 6.5. Displaying One Set of Values While Sorting by Another Section 6.6. Sorting and NULL Values Section 6.7. Controlling Case Sensitivity of String Sorts Section 6.8. Date-Based Sorting Section 6.9. Sorting by Calendar Day Section 6.10. Sorting by Day of Week Section 6.11. Sorting by Time of Day Section 6.12. Sorting Using Substrings of Column Values Section 6.13. Sorting by Fixed-Length Substrings Section 6.14. Sorting by Variable-Length Substrings Section 6.15. Sorting Hostnames in Domain Order Section 6.16. Sorting Dotted-Quad IP Values in Numeric Order Section 6.17. Floating Specific Values to the Head or Tail of the Sort Order Section 6.18. Sorting in User-Defined Orders Section 6.19. Sorting ENUM Values Chapter 7. Generating Summaries Section 7.1. Introduction Section 7.2. Summarizing with COUNT( ) Section 7.3. Summarizing with MIN( ) and MAX( ) Section 7.4. Summarizing with SUM( ) and AVG( ) Section 7.5. Using DISTINCT to Eliminate Duplicates Section 7.6. Finding Values Associated with Minimum and Maximum Values Section 7.7. Controlling String Case Sensitivity for MIN( ) and MAX( ) Section 7.8. Dividing a Summary into Subgroups Section 7.9. Summaries and NULL Values Section 7.10. Selecting Only Groups with Certain Characteristics Section 7.11. Determining Whether Values are Unique Section 7.12. Grouping by Expression Results Section 7.13. Categorizing Non-Categorical Data Section 7.14. Controlling Summary Display Order Section 7.15. Finding Smallest or Largest Summary Values Section 7.16. Date-Based Summaries Section 7.17. Working with Per-Group and Overall Summary Values Simultaneously Section 7.18. Generating a Report That Includes a Summary and a List Chapter 8. Modifying Tables with ALTER TABLE Section 8.1. Introduction Section 8.2. Dropping, Adding, or Repositioning a Column Section 8.3. Changing a Column Definition or Name Section 8.4. The Effect of ALTER TABLE on Null and Default Value Attributes Section 8.5. Changing a Column's Default Value Section 8.6. Changing a Table Type Section 8.7. Renaming a Table Section 8.8. Adding or Dropping Indexes Section 8.9. Eliminating Duplicates by Adding an Index Section 8.10. Using ALTER TABLE to Normalize a Table Chapter 9. Obtaining and Using Metadata Section 9.1. Introduction Section 9.2. Obtaining the Number of Rows Affected by a Query Section 9.3. Obtaining Result Set Metadata Section 9.4. Determining Presence or Absence of a Result Set Section 9.5. Formatting Query Results for Display Section 9.6. Getting Table Structure Information Section 9.7. Getting ENUM and SET Column Information Section 9.8. Database-Independent Methods of Obtaining Table Information Section 9.9. Applying Table Structure Information Section 9.10. Listing Tables and Databases Section 9.11. Testing Whether a Table Exists Section 9.12. Testing Whether a Database Exists Section 9.13. Getting Server Metadata Section 9.14. Writing Applications That Adapt to the MySQL Server Version Section 9.15. Determining the Current Database Section 9.16. Determining the Current MySQL User Section 9.17. Monitoring the MySQL Server Section 9.18. Determining Which Table Types the Server Supports Chapter 10. Importing and Exporting Data Section 10.1. Introduction Section 10.2. Importing Data with LOAD DATA and mysqlimport Section 10.3. Specifying the Datafile Location Section 10.4. Specifying the Datafile Format Section 10.5. Dealing with Quotes and Special Characters Section 10.6. Importing CSV Files Section 10.7. Reading Files from Different Operating Systems Section 10.8. Handling Duplicate Index Values Section 10.9. Getting LOAD DATA to Cough Up More Information Section 10.10. Don't Assume LOAD DATA Knows More than It Does Section 10.11. Skipping Datafile Lines Section 10.12. Specifying Input Column Order Section 10.13. Skipping Datafile Columns Section 10.14. Exporting Query Results from MySQL Section 10.15. Exporting Tables as Raw Data Section 10.16. Exporting Table Contents or Definitions in SQL Format Section 10.17. Copying Tables or Databases to Another Server Section 10.18. Writing Your Own Export Programs Section 10.19. Converting Datafiles from One Format to Another Section 10.20. Extracting and Rearranging Datafile Columns Section 10.21. Validating and Transforming Data Section 10.22. Validation by Direct Comparison Section 10.23. Validation by Pattern Matching Section 10.24. Using Patterns to Match Broad Content Types Section 10.25. Using Patterns to Match Numeric Values Section 10.26. Using Patterns to Match Dates or Times Section 10.27. Using Patterns to Match Email Addresses and URLs Section 10.28. Validation Using Table Metadata Section 10.29. Validation Using a Lookup Table Section 10.30. Converting Two-Digit Year Values to Four-Digit Form Section 10.31. Performing Validity Checking on Date or Time Subparts Section 10.32. Writing Date-Processing Utilities Section 10.33. Using Dates with Missing Components Section 10.34. Performing Date Conversion Using SQL Section 10.35. Using Temporary Tables for Data Transformation Section 10.36. Dealing with NULL Values Section 10.37. Guessing Table Structure from a Datafile Section 10.38. A LOAD DATA Diagnostic Utility Section 10.39. Exchanging Data Between MySQL and Microsoft Access Section 10.40. Exchanging Data Between MySQL and Microsoft Excel Section 10.41. Exchanging Data Between MySQL and FileMaker Pro Section 10.42. Exporting Query Results as XML Section 10.43. Importing XML into MySQL Section 10.44. Epilog Chapter 11. Generating and Using Sequences Section 11.1. Introduction Section 11.2. Using AUTO_INCREMENT To Set Up a Sequence Column Section 11.3. Generating Sequence Values Section 11.4. Choosing the Type for a Sequence Column Section 11.5. The Effect of Record Deletions on Sequence Generation Section 11.6. Retrieving Sequence Values Section 11.7. Determining Whether to Resequence a Column Section 11.8. Extending the Range of a Sequence Column Section 11.9. Renumbering an Existing Sequence Section 11.10. Reusing Values at the Top of a Sequence Section 11.11. Ensuring That Rows Are Renumbered in a Particular Order Section 11.12. Starting a Sequence at a Particular Value Section 11.13. Sequencing an Unsequenced Table Section 11.14. Using an AUTO_INCREMENT Column to Create Multiple Sequences Section 11.15. Managing Multiple SimultaneousAUTO_INCREMENT Values Section 11.16. Using AUTO_INCREMENT Valuesto Relate Tables Section 11.17. Using Single-Row Sequence Generators Section 11.18. Generating Repeating Sequences Section 11.19. Numbering Query Output Rows Sequentially Chapter 12. Using Multiple Tables Section 12.1. Introduction Section 12.2. Combining Rows in One Table with Rows in Another Section 12.3. Performing a Join Between Tables in Different Databases Section 12.4. Referring to Join Output Column Names in Programs Section 12.5. Finding Rows in One Table That Match Rows in Another Section 12.6. Finding Rows with No Match in Another Table Section 12.7. Finding Rows Containing Per-Group Minimum or Maximum Values Section 12.8. Computing Team Standings Section 12.9. Producing Master-Detail Lists and Summaries Section 12.10. Using a Join to Fill in Holes in a List Section 12.11. Enumerating a Many-to-Many Relationship Section 12.12. Comparing a Table to Itself Section 12.13. Calculating Differences Between Successive Rows Section 12.14. Finding Cumulative Sums and Running Averages Section 12.15. Using a Join to Control Query Output Order Section 12.16. Converting Subselects to Join Operations Section 12.17. Selecting Records in Parallel from Multiple Tables Section 12.18. Inserting Records in One Table That Include Values from Another Section 12.19. Updating One Table Based on Values in Another Section 12.20. Using a Join to Create a Lookup Table from Descriptive Labels Section 12.21. Deleting Related Rows in Multiple Tables Section 12.22. Identifying and Removing Unattached Records Section 12.23. Using Different MySQL Servers Simultaneously Chapter 13. Statistical Techniques Section 13.1. Introduction Section 13.2. Calculating Descriptive Statistics Section 13.3. Per-Group Descriptive Statistics Section 13.4. Generating Frequency Distributions Section 13.5. Counting Missing Values Section 13.6. Calculating Linear Regressions or Correlation Coefficients Section 13.7. Generating Random Numbers Section 13.8. Randomizing a Set of Rows Section 13.9. Selecting Random Items from a Set of Rows Section 13.10. Assigning Ranks Chapter 14. Handling Duplicates Section 14.1. Introduction Section 14.2. Preventing Duplicates from Occurring in a Table Section 14.3. Dealing with Duplicates at Record-Creation Time Section 14.4. Counting and Identifying Duplicates Section 14.5. Eliminating Duplicates from a Query Result Section 14.6. Eliminating Duplicates from a Self-Join Result Section 14.7. Eliminating Duplicates from a Table Chapter 15. Performing Transactions Section 15.1. Introduction Section 15.2. Verifying Transaction Support Requirements Section 15.3. Performing Transactions Using SQL Section 15.4. Performing Transactions from Within Programs Section 15.5. Using Transactions in Perl Programs Section 15.6. Using Transactions in PHP Programs Section 15.7. Using Transactions in Python Programs Section 15.8. Using Transactions in Java Programs Section 15.9. Using Alternatives to Transactions Chapter 16. Introduction to MySQL on the Web Section 16.1. Introduction Section 16.2. Basic Web Page Generation Section 16.3. Using Apache to Run Web Scripts Section 16.4. Using Tomcat to Run Web Scripts Section 16.5. Encoding Special Characters in Web Output Chapter 17. Incorporating Query Resultsinto Web Pages Section 17.1. Introduction Section 17.2. Displaying Query Results as Paragraph Text Section 17.3. Displaying Query Results as Lists Section 17.4. Displaying Query Results as Tables Section 17.5. Displaying Query Results as Hyperlinks Section 17.6. Creating a Navigation Index from Database Content Section 17.7. Storing Images or Other Binary Data Section 17.8. Retrieving Images or Other Binary Data Section 17.9. Serving Banner Ads Section 17.10. Serving Query Results for Download Chapter 18. Processing Web Input with MySQL Section 18.1. Introduction Section 18.2. Creating Forms in Scripts Section 18.3. Creating Single-Pick Form Elements from Database Content Section 18.4. Creating Multiple-Pick Form Elements from Database Content Section 18.5. Loading a Database Record into a Form Section 18.6. Collecting Web Input Section 18.7. Validating Web Input Section 18.8. Using Web Input to Construct Queries Section 18.9. Processing File Uploads Section 18.10. Performing Searches and Presenting the Results Section 18.11. Generating Previous-Page and Next-Page Links Section 18.12. Generating "Click to Sort" Table Headings Section 18.13. Web Page Access Counting Section 18.14. Web Page Access Logging Section 18.15. Using MySQL for Apache Logging Chapter 19. Using MySQL-Based Web Session Management Section 19.1. Introduction Section 19.2. Using MySQL-Based Sessions in Perl Applications Section 19.3. Using MySQL-Based Storage with the PHP Session Manager Section 19.4. Using MySQL for Session BackingStore with Tomcat Appendix A. Obtaining MySQL Software Section A.1. Obtaining Sample Source Code and Data Section A.2. Obtaining MySQL and Related Software Appendix B. JSP and Tomcat Primer Section B.1. Servlet and JavaServer Pages Overview Section B.2. Setting Up a Tomcat Server Section B.3. Web Application Structure Section B.4. Elements of JSP Pages Appendix C. References Section C.1. MySQL Resources Section C.2. Perl Resources Section C.3. PHP Resources Section C.4. Python Resources Section C.5. Java Resources Section C.6. Apache Resources Section C.7. Other Resources Colophon Index Preface The MySQL database management system has become quite popular in recent years. This has been true especially in the Linux and open source communities, but MySQL's presence in the commercial sector now is increasing as well. It is well liked for several reasons: MySQL is fast, and it's easy to set up, use, and administrate. MySQL runs under many varieties of Unix and Windows, and MySQL-based programs can be written in many languages. MySQL is especially heavily used in combination with a web server for constructing database-backed web sites that involve dynamic content generation. With MySQL's rise in popularity comes the need to address the questions posed by its users about how to solve specific problems. That is the purpose of MySQL Cookbook. It's designed to serve as a handy resource to which you can turn when you need quick solutions or techniques for attacking particular types of questions that come up when you use MySQL. Naturally, because it's a cookbook, it contains recipes: straightforward instructions you can follow rather than develop your own code from scratch. It's written using a problem-and-solution format designed to be extremely practical and to make the contents easy to read and assimilate. It contains many short sections, each describing how to write a query, apply a technique, or develop a script to solve a problem of limited and specific scope. This book doesn't attempt to develop full-fledged applications. Instead, it's intended to assist you in developing such applications yourself by helping you get past problems that have you stumped. For example, a common question is, "How can I deal with quotes and special characters in data values when I'm writing queries?" That's not difficult, but figuring out how to do it is frustrating when you're not sure where to start. This book demonstrates what to do; it shows you where to begin and how to proceed from there. This knowledge will serve you repeatedly, because after you see what's involved, you'll be able to apply the technique to any kind of data, such as text, images, sound or video clips, news articles, compressed files, PDF files, or word processing documents. Another common question is, "Can I access tables from two databases at the same time?" The answer is "Yes," and it's easy to do because it's just a matter of knowing the proper SQL syntax. But it's hard to do until you see how; this book will show you. Other things that you'll learn from this book include: · How to use SQL to select, sort, and summarize records. · How to find matches or mismatches between records in two tables. · How to perform a transaction. · How to determine intervals between dates or times, including age calculations. · How to remove duplicate records. · How to store images into MySQL and retrieve them for display in web pages. · How to convert the legal values of an ENUM column into radio buttons in a web page, or the values of a SET column into checkboxes. · How to get LOAD DATA to read your datafiles properly, or find out which values in the file are bad. · How to use pattern matching techniques to cope with mismatches between the CCYY- MM-DD date format that MySQL uses and dates in your datafiles. · How to copy a table or a database to another server. · How to resequence a sequence number column, and why you really don't want to. One part of knowing how to use MySQL is understanding how to communicate with the server—that is, how to use SQL, the language through which queries are formulated. Therefore, one major emphasis of this book is on using SQL to formulate queries that answer particular kinds of questions. One helpful tool for learning and using SQL is the mysql client program that is included in MySQL distributions. By using this client interactively, you can send SQL statements to the server and see the results. This is extremely useful because it provides a direct interface to SQL. The mysql client is so useful, in fact, that the entire first chapter is devoted to it. But the ability to issue SQL queries alone is not enough. Information extracted from a database often needs to be processed further or presented in a particular way to be useful. What if you have queries with complex interrelationships, such as when you need to use the results of one query as the basis for others? SQL by itself has little facility for making these kinds of choices, which makes it difficult to use decision-based logic to determine which queries to execute. Or what if you need to generate a specialized report with very specific formatting requirements? This too is difficult to achieve using just SQL. These problems bring us to the other major emphasis of the book—how to write programs that interact with the MySQL server through an application programming interface (API). When you know how to use MySQL from within the context of a programming language, you gain the ability to exploit MySQL's capabilities in the following ways: · You can remember the result from a query and use it at a later time. · You can make decisions based on success or failure of a query, or on the content of the rows that are returned. Difficulties in implementing control flow disappear when using an API because the host language provides facilities for expressing decision- based logic: if-then-else constructs, while loops, subroutines, and so forth. · You can format and display query results however you like. If you're writing a command-line script, you can generate plain text. If it's a web-based script, you can generate an HTML table. If it's an application that extracts information for transfer to some other system, you might write a datafile expressed in XML. When you combine SQL with a general purpose programming language and a MySQL client API, you have an extremely flexible framework for issuing queries and processing their results. Programming languages increase your expressive capabilities by giving you a great deal of additional power to perform complex database operations. This doesn't mean this book is complicated, though. It keeps things simple, showing how to construct small building blocks by using techniques that are easy to understand and easily mastered. I'll leave it to you to combine these techniques within your own programs, which you can do to produce arbitrarily complex applications. After all, the genetic code is based on only four nucleic acids, but these basic elements have been combined to produce the astonishing array of biological life we see all around us. Similarly, there are only 12 notes in the scale, but in the hands of skilled composers, they can be interwoven to produce a rich and endless variety of music. In the same way, when you take a set of simple recipes, add your imagination, and apply them to the database programming problems you want to solve, you can produce that are perhaps not works of art, but certainly applications that are useful and that will help you and others be more productive. MySQL APIs Used in This Book MySQL programming interfaces exist for many languages, including (in alphabetical order) C, C++, Eiffel, Java, Pascal, Perl, PHP, Python, Ruby, Smalltalk, and Tcl.[] Given this fact, writing a MySQL cookbook presents an author with something of a challenge. Clearly the book should provide recipes for doing many interesting and useful things with MySQL, but which API or APIs should the book use? Showing an implementation of every recipe in every language would result either in covering very few recipes or in a very, very large book! It would also result in a lot of redundancy when implementations in different languages bear a strong resemblance to each other. On the other hand, it's worthwhile taking advantage of multiple languages, because one language often will be more suitable than another for solving a particular type of problem. [] To see what APIs are currently available, visit the development portal at the MySQL web site, located at http://www.mysql.com/portal/development/html/. To resolve this dilemma, I've picked a small number of APIs from among those that are available and used them to write the recipes in this book. This limits its scope to a manageable number of APIs while allowing some latitude to choose from among them. The primary APIs covered here are: Perl Using the DBI module and its MySQL-specific driver PHP Using its set of built-in MySQL support functions Python Using the DB-API module and its MySQL-specific driver Java Using a MySQL-specific driver for the Java Database Connectivity (JDBC) interface Why these languages? Perl and PHP were easy to pick. Perl is arguably the most widely used language on the Web, and it became so based on certain strengths such as its text-processing capabilities. In particular, it's very popular for writing MySQL programs. PHP also is widely deployed, and its use is increasing steadily. One of PHP's strengths is the ease with which you can use it to access databases, making it a natural choice for MySQL scripting. Python and Java are not as popular as Perl or PHP for MySQL programming, but each has significant numbers of followers. In the Java community in particular, MySQL seems to be making strong inroads among developers who use JavaServer Pages (JSP) technology to build database- backed web applications. (An anecdotal observation: After I wrote MySQL (New Riders), Python and Java were the two languages not covered in that book that readers most often said they would have liked to have seen addressed. So here they are!) I believe these languages taken together reflect pretty well the majority of the existing user base of MySQL programmers. If you prefer some language not shown here, you can still use this book, but be sure to pay careful attention to Chapter 2, to familiarize yourself with the book's primary API languages. Knowing how database operations are performed with the APIs used here will help you understand the recipes in later chapters so that you can translate them into languages not discussed. Who This Book Is For This book should be useful for anybody who uses MySQL, ranging from novices who want to use a database for personal reasons, to professional database and web developers. The book should also appeal to people who do not now use MySQL, but would like to. For example, it should be useful to beginners who want to learn about databases but realize that Oracle isn't the best choice for that. If you're relatively new to MySQL, you'll probably find lots of ways to use it here that you hadn't thought of. If you're more experienced, you'll probably be familiar with many of the problems addressed here, but you may not have had to solve them before and should find the book a great timesaver; take advantage of the recipes given in the book and use them in your own programs rather than figuring out how to write the code from scratch. The book also can be useful for people who aren't even using MySQL. You might suppose that because this is a MySQL cookbook and not a PostgreSQL cookbook or an InterBase cookbook that it won't apply to databases other than MySQL. To some extent that's true, because some of the SQL constructs are MySQL-specific. On the other hand, many of the queries are standard SQL that is portable to many other database engines, so you should be able to use them with little or no modification. And several of our programming language interfaces provide database-independent access methods; you use them the same way regardless of which database you're connecting to. The material ranges from introductory to advanced, so if a recipe describes techniques that seem obvious to you, skip it. Or if you find that you don't understand a recipe, it may be best to set it aside for a while and come back to it later, perhaps after reading some of the preceding recipes. More advanced readers may wonder on occasion why in a book on MySQL I sometimes provide explanatory material on certain basic topics that are not directly MySQL-related, such as how to set environment variables. I decided to do this based on my experience in helping novice MySQL users. One thing that makes MySQL attractive is that it is easy to use, which makes it a popular choice for people without extensive background in databases. However, many of these same people also tend to be thwarted by simple barriers to more effective use of MySQL, as evidenced by the common question, "How can I avoid having to type the full pathname of mysql each time I invoke it?" Experienced readers will recognize immediately that this is simply a matter of appropriately setting the PATH environment variable to include the directory where mysql is installed. But other readers will not, particularly Windows users who are used to dealing only with a graphical interface and, more recently, Mac OS X users who find their familiar user interface now augmented by the powerful but sometimes mysterious command line provided by the Terminal application. If you are in this situation, you'll find these more elementary sections helpful in knocking down barriers that keep you from using MySQL more easily. If you're a more advanced user, just skip over such sections. What's in This Book It's very likely when you use this book that you'll have an application in mind you're trying to develop but are not sure how to implement certain pieces of it. In this case, you'll already know what type of problem you want to solve, so you should search the table of contents or the index looking for a recipe that shows how to do what you want. Ideally, the recipe will be just what you had in mind. Failing that, you should be able to find a recipe for a similar problem that you can adapt to suit the issue at hand. (I try to explain the principles involved in developing each technique so that you'll be able to modify it to fit the particular requirements of your own applications.) Another way to approach this book is to just read through it with no specific problem in mind. This can help you because it will give you a broader understanding of the things MySQL can do, so I recommend that you page through the book occasionally. It's a more effective tool if you have a general familiarity with it and know the kinds of problems it addresses. The following paragraphs summarize each chapter, to help give you an overview of the book's contents. Chapter 1, describes how to use the standard MySQL command-line client. mysql is often the first interface to MySQL that people use, and it's important to know how to exploit its capabilities. This program allows you to issue queries and see the results interactively, so it's good for quick experimentation. You can also use it in batch mode to execute canned SQL scripts or send its output into other programs. In addition, the chapter discusses other ways to use mysql, such as how to number output lines or make long lines more readable, how to generate various output formats, and how to log mysql sessions. Chapter 2, demonstrates the basic elements of MySQL programming in each API language: how to connect to the server, issue queries, retrieve the results, and handle errors. It also discusses how to handle special characters and NULL values in queries, how to write library files to encapsulate code for commonly used operations, and various ways to gather the parameters needed for making connections to the server. Chapter 3, covers several aspects of the SELECT statement, which is the primary vehicle for retrieving data from the MySQL server: specifying which columns and rows you want to retrieve, performing comparisons, dealing with NULL values, selecting one section of a query result, using temporary tables, and copying results into other tables. Later chapters cover some of these topics in more detail, but this chapter provides an overview of the concepts on which they depend. You should read it if you need some introductory background on record selection, for example, if you don't yet know a lot about SQL. Chapter 4, describes how to deal with string data. It addresses string comparisons, pattern matching, breaking apart and combining strings, dealing with case-sensitivity issues, and performing FULLTEXT searches. Chapter 5, shows how to work with temporal data. It describes MySQL's date format and how to display date values in other formats. It also covers conversion between different temporal units, how to perform date arithmetic to compute intervals or generate one date from another, leap-year calculations, and how to use MySQL's special TIMESTAMP column type. Chapter 6, describes how to put the rows of a query result in the order you want. This includes specifying the sort direction, dealing with NULL values, accounting for string case sensitivity, and sorting by dates or partial column values. It also provides examples that show how to sort special kinds of values, such as domain names, IP numbers, and ENUM values. Chapter 7, shows techniques that are useful for assessing the general characteristics of a set of data, such as how many values it contains or what the minimum, maximum, or average values are. Chapter 8, describes how to alter the structure of tables by adding, dropping, or modifying columns, and how to set up indexes. Chapter 9, discusses how to get information about the data a query returns, such as the number of rows or columns in the result, or the name and type of each column. It also shows how to ask MySQL what databases and tables are available or about the structure of a table and its columns. Chapter 10, describes how to transfer information between MySQL and other programs. This includes how to convert files from one format to another, extract or rearrange columns in datafiles, check and validate data, rewrite values such as dates that often come in a variety of formats, and how to figure out which data values cause problems when you load them into MySQL with LOAD DATA. Chapter 11, discusses AUTO_INCREMENT columns, MySQL's mechanism for producing sequence numbers. It shows how to generate new sequence values or determine the most recent value, how to resequence a column, how to begin a sequence at a given value, and how to set up a table so that it can maintain multiple sequences at once. It also shows how to use AUTO_INCREMENT values to maintain a master-detail relationship between tables, including some of the pitfalls to avoid. Chapter 12, shows how to perform joins, which are operations that combine rows in one table with those from another. It demonstrates how to compare tables to find matches or mismatches, produce master-detail lists and summaries, enumerate many-to-many relationships, and update or delete records in one table based on the contents of another. Chapter 13, illustrates how to produce descriptive statistics, frequency distributions, regressions, and correlations. It also covers how to randomize a set of rows or pick a row at random from the set. Chapter 14, discusses how to identify, count, and remove duplicate records—and how to prevent them from occurring in the first place. Chapter 15, shows how to handle multiple SQL statements that must execute together as a unit. It discusses how to control MySQL's auto-commit mode, how to commit or roll back transactions, and demonstrates some workarounds you can use if transactional capabilities are unavailable in your version of MySQL. Chapter 16, gets you set up to write web-based MySQL scripts. Web programming allows you to generate dynamic pages or collect information for storage in your database. The chapter discusses how to configure Apache to run Perl, PHP, and Python scripts, and how to configure Tomcat to run Java scripts written using JSP notation. It also provides an overview of the Java Standard Tag Library (JSTL) that is used heavily in JSP pages in the following chapters. Chapter 17, shows how to use the results of queries to produce various types of HTML structures, such as paragraphs, lists, tables, hyperlinks, and navigation indexes. It also describes how to store images into MySQL, retrieve and display them later, and how to send a downloadable result set to a browser. Chapter 18, discusses ways to obtain input from users over the Web and use it to create new database records or as the basis for performing searches. It deals heavily with form processing, including how to construct form elements, such as radio buttons, pop-up menus, or checkboxes, based on information contained in your database. Chapter 19, describes how to write web applications that remember information across multiple requests, using MySQL for backing store. This is useful when you want to collect information in stages, or when you need to make decisions based on what the user has done earlier. Appendix A, indicates where to get the source code for the examples shown in this book, and where to get the software you need to use MySQL and write your own database programs. Appendix B, provides a general overview of JSP and installation instructions for the Tomcat web server. Read this if you need to install Tomcat or are not familiar with it, or if you're never written JSP pages. Appendix C, lists sources of information that provide additional information about topics covered in this book. It also lists some books that provide introductory background for the programming languages used here. As you get into later chapters, you'll sometimes find recipes that assume a knowledge of topics covered in earlier chapters. This also applies within a chapter, where later sections often use techniques discussed earlier in the chapter. If you jump into a chapter and find a recipe that uses a technique with which you're not familiar, check the table of contents or the index to find out where the technique is covered. You should find that it's been explained earlier. For example, if you find that a recipe sorts a query result using an ORDER BY clause that you don't understand, turn to Chapter 6, which discusses various sorting methods and explains how they work. Platform Notes Development of the code in this book took place under MySQL 3.23 and 4.0. Because new features are added to MySQL on a regular basis, some examples will not work under older versions. I've tried to point out version dependencies when introducing such features for the first time. The MySQL language API modules that I used include DBI 1.20 and up, DBD::mysql 2.0901 and up, MySQLdb 0.9 and up, MM.MySQL 2.0.5 and up, and MySQL Connector/J 2.0.14. DBI requires Perl 5.004_05 or higher up through DBI 1.20, after which it requires Perl 5.005_03 or higher. MySQLdb requires Python 1.5.6 or higher. MM.MySQL and MySQL Connector/J require Java SDK 1.1 or higher. Language processors include Perl 5.6 and 5.6.1; PHP 3 and 4; Python 1.5.6, 2.2; and 2.3, and Java SDK 1.3.1. Most PHP scripts shown here will run under either PHP 3 or PHP 4 (although I strongly recommend PHP 4 over PHP 3). Scripts that require PHP 4 are so noted. I do not assume that you are using Unix, although that is my own preferred development platform. Most of the material here should be applicable both to Unix and Windows. The operating systems I used most for development of the recipes in this book were Mac OS X; RedHat Linux 6.2, 7.0, and 7.3; and various versions of Windows (Me, 98, NT, and 2000). I do assume that MySQL is installed already and available for you to use. I also assume that if you plan to write your own MySQL-based programs, you're reasonably familiar with the language you'll use. If you need to install software, see Appendix A. If you require background material on the programming languages used here, see Appendix C. Conventions Used in This Book The following font conventions have been used throughout the book: Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names. Constant width bold Used to indicate text that you type when running commands. Constant width italic Used to indicate variable input; you should substitute a value of your own choosing. Italic Used for URLs, hostnames, names of directories and files, Unix commands and options, and occasionally for emphasis. Commands often are shown with a prompt to illustrate the context in which they are used. Commands that you issue from the command line are shown with a % prompt: % chmod 600 my.cnf That prompt is one that Unix users are used to seeing, but it doesn't necessarily signify that a command will work only under Unix. Unless indicated otherwise, commands shown with a % prompt generally should work under Windows, too. If you should run a command under Unix as the root user, the prompt is # instead: # chkconfig --add tomcat4 For commands that are specific only to Windows, the C:\> prompt is used: C:\> copy C:\mysql\lib\cygwinb19.dll C:\Windows\System SQL statements that are issued from within the mysql client program are shown with a mysql> prompt and terminated with a semicolon: mysql> SELECT * FROM my_table; For examples that show a query result as you would see it when using mysql, I sometimes truncate the output, using an ellipsis (...) to indicate that the result consists of more rows than are shown. The following query produces many rows of output, of which those in the middle have been omitted: mysql> SELECT name, abbrev FROM states ORDER BY name; +----------------+--------+ | name | abbrev | +----------------+--------+ | Alabama | AL | | Alaska | AK | | Arizona | AZ | ... | West Virginia | WV | | Wisconsin | WI | | Wyoming | WY | +----------------+--------+ Examples that just show the syntax for SQL statements do not include the mysql> prompt, but they do include semicolons as necessary to make it clear where statements end. For example, this is a single statement: CREATE TABLE t1 (i INT) SELECT * FROM t2; But this example represents two statements: CREATE TABLE t1 (i INT); SELECT * FROM t2; The semicolon is a notational convenience used within mysql as a statement terminator. But it is not part of SQL itself, so when you issue SQL statements from within programs that you write (for example, using Perl or Java), you should not include terminating semicolons. This icon indicates a tip, suggestion, or general note. The Companion Web Site MySQL Cookbook has a companion web site that you can visit to obtain the source code and sample data for examples developed throughout this book: http://www.kitebird.com/mysql-cookbook/ The main software distribution is named recipes and you'll find many references to it throughout the book. You can use it to save a lot of typing. For example, when you see a CREATE TABLE statement in the book that describes what a database table looks like, you'll find a SQL batch file in the tables directory of the recipes distribution that you can use to create the table instead of typing out the definition. Change location into the tables directory, then execute the following command, where filename is the name of the containing the CREATE TABLE statement: % mysql cookbook < filename If you need to specify MySQL username or password options, put them before the database name. For more information about the distributions, see Appendix A. The Kitebird site also makes some of the examples from the book available online so that you can try them out from your browser. Comments and Questions Please address comments and questions concerning this book to the publisher: O'Reilly & Associates, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (707) 829-0515 (international/local) (707) 829-0104 (fax) O'Reilly keeps a web page for this book that you can access at: http://www.oreilly.com/catalog/mysqlckbk/ To comment or ask technical questions about this book, send email to: bookquestions@oreilly.com For more information about books, conferences, Resource Centers, and the O'Reilly Network, see the O'Reilly web site at: http://www.oreilly.com Additional Resources Any language that attracts a following tends to benefit from the efforts of its user community, because people who use the language produce code that they make available to others. Perl in particular is served by an extensive support network designed to provide external modules that are not distributed with Perl itself. This is called the Comprehensive Perl Archive Network (CPAN), a mechanism for organizing and distributing Perl code and documentation. CPAN contains modules that allow database access, web programming, and XML processing, to name a few of direct relevance to this cookbook. External support exists for the other languages as well, though none of them currently enjoys the same level of organization as CPAN. PHP has the PEAR archive, and Python has a module archive called the Vaults of Parnassus. For Java, a good starting point is Sun's Java site. Sites that you can visit to find more information are shown in the following table. API language Where to find external support Perl http://cpan.perl.org/ PHP http://pear.php.net/ Python http://www.python.org/ Java http://java.sun.com/ Acknowledgments I'd like to thank my technical reviewers, Tim Allwine, David Lane, Hugh Williams, and Justin Zobel. They made several helpful suggestions and corrections with regard to both organizational structure and technical accuracy. Several members of MySQL AB were gracious enough to add their comments: In particular, principal MySQL developer Monty Widenius combed the text and spotted many problems. Arjen Lentz, Jani Tolonen, Sergei Golubchik, and Zak Greant reviewed sections of the manuscript as well. Andy Dustman, author of the Python MySQLdb module, and Mark Matthews, author of MM.MySQL and MySQL Connector/J, also provided feedback. My thanks to all for improving the manuscript; any errors remaining are my own. Laurie Petrycki, executive editor, conceived the idea for the book and provided valuable overall editorial guidance and cattle-prodding. Lenny Muellner, tools expert, assisted in the conversion of the manuscript from my original format into something printable. David Chu acted as editorial assistant. Ellie Volckhausen designed the cover, which I am happy to see is reptilian in nature. Linley Dolby served as the production editor and proofreader, and Colleen Gorman, Darren Kelly, Jeffrey Holcomb, Brian Sawyer, and Claire Cloutier provided quality control. Thanks to Todd Greanier and Sean Lahman of The Baseball Archive for all their hard work in putting together the baseball database that is used for several of the examples in this book. Some authors are able to compose text productively while sitting at a keyboard, but I write better while sitting far from a computer—preferably with a cup of coffee. That being so, I'd like to acknowledge my debt to the Sow's Ear coffee shop in Verona for providing pleasant surroundings in which to spend many hours scribbling on paper. My wife Karen provided considerable support and understanding in what turned out to be a much longer endeavor than anticipated. Her encouragement is much appreciated, and her patience something to marvel at. Chapter 1. Using the mysql Client Program Section 1.1. Introduction Section 1.2. Setting Up a MySQL User Account Section 1.3. Creating a Database and a Sample Table Section 1.4. Starting and Terminating mysql Section 1.5. Specifying Connection Parameters by Using Option Files Section 1.6. Protecting Option Files Section 1.7. Mixing Command-Line and Option File Parameters Section 1.8. What to Do if mysql Cannot Be Found Section 1.9. Setting Environment Variables Section 1.10. Issuing Queries Section 1.11. Selecting a Database Section 1.12. Canceling a Partially Entered Query Section 1.13. Repeating and Editing Queries Section 1.14. Using Auto-Completion for Database and Table Names Section 1.15. Using SQL Variables in Queries Section 1.16. Telling mysql to Read Queries from a File Section 1.17. Telling mysql to Read Queries from Other Programs Section 1.18. Specifying Queries on the Command Line Section 1.19. Using Copy and Paste as a mysql Input Source Section 1.20. Preventing Query Output from Scrolling off the Screen Section 1.21. Sending Query Output to a File or to a Program Section 1.22. Selecting Tabular or Tab-Delimited Query Output Format Section 1.23. Specifying Arbitrary Output Column Delimiters Section 1.24. Producing HTML Output Section 1.25. Producing XML Output Section 1.26. Suppressing Column Headings in Query Output Section 1.27. Numbering Query Output Lines Section 1.28. Making Long Output Lines More Readable Section 1.29. Controlling mysql's Verbosity Level Section 1.30. Logging Interactive mysql Sessions Section 1.31. Creating mysql Scripts from Previously Executed Queries Section 1.32. Using mysql as a Calculator Section 1.33. Using mysql in Shell Scripts 1.1 Introduction The MySQL database system uses a client-server architecture that centers around the server, mysqld. The server is the program that actually manipulates databases. Client programs don't do that directly; rather, they communicate your intent to the server by means of queries written in Structured Query Language (SQL). The client program or programs are installed locally on the machine from which you wish to access MySQL, but the server can be installed anywhere, as long as clients can connect to it. MySQL is an inherently networked database system, so clients can communicate with a server that is running locally on your machine or one that is running somewhere else, perhaps on a machine on the other side of the planet. Clients can be written for many different purposes, but each interacts with the server by connecting to it, sending SQL queries to it to have database operations performed, and receiving the query results from it. One such client is the mysql program that is included in MySQL distributions. When used interactively, mysql prompts for a query, sends it to the MySQL server for execution, and displays the results. This capability makes mysql useful in its own right, but it's also a valuable tool to help you with your MySQL programming activities. It's often convenient to be able to quickly review the structure of a table that you're accessing from within a script, to try a query before using it in a program to make sure it produces the right kind of output, and so forth. mysql is just right for these jobs. mysql also can be used non-interactively, for example, to read queries from a file or from other programs. This allows you to use it from within scripts or cron jobs or in conjunction with other applications. This chapter describes mysql's capabilities so that you can use it more effectively. Of course, to try out for yourself the recipes and examples shown in this book, you'll need a MySQL user account and a database to work with. The first two sections of the chapter describe how to use mysql to set these up. For demonstration purposes, the examples assume that you'll use MySQL as follows: · The MySQL server is running on the local host. · Your MySQL username and password are cbuser and cbpass. · Your database is named cookbook. For your own experimentation, you can violate any of these assumptions. Your server need not be running locally, and you need not use the username, password, or database name that are used in this book. Naturally, if you don't use MySQL in the manner just described, you'll need to change the examples to use values that are appropriate for your system. Even if you do use different names, I recommend that you at least create a database specifically for trying the recipes shown here, rather than one you're using currently for other purposes. Otherwise, the names of your existing tables may conflict with those used in the examples, and you'll have to make modifications to the examples that are unnecessary when you use a separate database. 1.2 Setting Up a MySQL User Account 1.2.1 Problem You need to create an account to use for connecting to the MySQL server running on a given host. 1.2.2 Solution Use the GRANT statement to set up the MySQL user account. Then use that account's name and password to make connections to the server. 1.2.3 Discussion Connecting to a MySQL server requires a username and password. You can also specify the name of the host where the server is running. If you don't specify connection parameters explicitly, mysql assumes default values. For example, if you specify no hostname, mysql typically assumes the server is running on the local host. The following example shows how to use the mysql program to connect to the server and issue a GRANT statement that sets up a user account with privileges for accessing a database named cookbook. The arguments to mysql include -h localhost to connect to the MySQL server running on the local host, -p to tell mysql to prompt for a password, and -u root to connect as the MySQL root user. Text that you type is shown in bold; non-bold text is program output: % mysql -h localhost -p -u root Enter password: ****** mysql> GRANT ALL ON cookbook.* TO 'cbuser'@'localhost' IDENTIFIED BY 'cbpass'; Query OK, 0 rows affected (0.09 sec) mysql> QUIT Bye After you enter the mysql command shown on the first line, if you get a message indicating that the program cannot be found or that it is a bad command, see Recipe 1.8. Otherwise, when mysql prints the password prompt, enter the MySQL root password where you see the ******. (If the MySQL root user has no password, just press Return at the password prompt.) Then issue a GRANT statement like the one shown. To use a database name other than cookbook, substitute its name where you see cookbook in the GRANT statement. Note that you need to grant privileges for the database even if the user account already exists. However, in that case, you'll likely want to omit the IDENTIFIED BY 'cbpass' part of the statement, because otherwise you'll change that account's current password. The hostname part of 'cbuser'@'localhost' indicates the host from which you'll be connecting to the MySQL server to access the cookbook database. To set up an account that will connect to a server running on the local host, use localhost, as shown. If you plan to make connections to the server from another host, substitute that host in the GRANT statement. For example, if you'll be connecting to the server as cbuser from a host named xyz.com, the GRANT statement should look like this: mysql> GRANT ALL ON cookbook.* TO 'cbuser'@'xyz.com' IDENTIFIED BY 'cbpass'; It may have occurred to you that there's a bit of a paradox involved in the procedure just described. That is, to set up a user account that can make connections to the MySQL server, you must connect to the server first so that you can issue the GRANT statement. I'm assuming that you can already connect as the MySQL root user, because GRANT can be used only by a user such as root that has the administrative privileges needed to set up other user accounts. If you can't connect to the server as root, ask your MySQL administrator to issue the GRANT statement for you. Once that has been done, you should be able to use the new MySQL account to connect to the server, create your own database, and proceed from there on your own. MySQL Accounts and Login Accounts MySQL accounts and login accounts for your operating system are different. For example, the MySQL root user and the Unix root user are separate and have nothing to do with each other, even though the username is the same in each case. This means they are very likely to have different passwords. It also means you cannot create new MySQL accounts by creating login accounts for your operating system; use the GRANT statement instead. 1.3 Creating a Database and a Sample Table 1.3.1 Problem You want to create a database and to set up tables within it. 1.3.2 Solution Use a CREATE DATABASE statement to create a database, a CREATE TABLE statement for each table you want to use, and INSERT to add records to the tables. 1.3.3 Discussion The GRANT statement used in the previous section defines privileges for the cookbook database, but does not create it. You need to create the database explicitly before you can use it. This section shows how to do that, and also how to create a table and load it with some sample data that can be used for examples in the following sections. After the cbuser account has been set up, verify that you can use it to connect to the MySQL server. Once you've connected successfully, create the database. From the host that was named in the GRANT statement, run the following commands to do this (the host named after -h should be the host where the MySQL server is running): % mysql -h localhost -p -u cbuser Enter password: cbpass mysql> CREATE DATABASE cookbook; Query OK, 1 row affected (0.08 sec) Now you have a database, so you can create tables in it. Issue the following statements to select cookbook as the default database, create a simple table, and populate it with a few records:[1] [1] If you don't want to enter the complete text of the INSERT statements (and I don't blame you), skip ahead to Recipe 1.13 for a shortcut. And if you don't want to type in any of the statements, skip ahead to Recipe 1.16. mysql> USE cookbook; mysql> CREATE TABLE limbs (thing VARCHAR(20), legs INT, arms INT); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('human',2,2); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('insect',6,0); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('squid',0,10); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('octopus',0,8); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('fish',0,0); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('centipede',100,0); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('table',4,0); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('armchair',4,2); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('phonograph',0,1); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('tripod',3,0); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('Peg Leg Pete',1,2); mysql> INSERT INTO limbs (thing,legs,arms) VALUES('space alien',NULL,NULL); The table is named limbs and contains three columns to records the number of legs and arms possessed by various life forms and objects. (The physiology of the alien in the last row is such that the proper values for the arms and legs column cannot be determined; NULL indicates "unknown value.") Verify that the table contains what you expect by issuing a SELECT statement: mysql> SELECT * FROM limbs; +--------------+------+------+ | thing | legs | arms | +--------------+------+------+ | human | 2 | 2 | | insect | 6 | 0 | | squid | 0 | 10 | | octopus | 0 | 8 | | fish | 0 | 0 | | centipede | 100 | 0 | | table | 4 | 0 | | armchair | 4 | 2 | | phonograph | 0 | 1 | | tripod | 3 | 0 | | Peg Leg Pete | 1 | 2 | | space alien | NULL | NULL | +--------------+------+------+ 12 rows in set (0.00 sec) At this point, you're all set up with a database and a table that can be used to run some example queries. 1.4 Starting and Terminating mysql 1.4.1 Problem You want to start and stop the mysql program. 1.4.2 Solution Invoke mysql from your command prompt to start it, specifying any connection parameters that may be necessary. To leave mysql, use a QUIT statement. 1.4.3 Discussion To start the mysql program, try just typing its name at your command-line prompt. If mysql starts up correctly, you'll see a short message, followed by a mysql> prompt that indicates the program is ready to accept queries. To illustrate, here's what the welcome message looks like (to save space, I won't show it in any further examples): % mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 18427 to server version: 3.23.51-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> If mysql tries to start but exits immediately with an "access denied" message, you'll need to specify connection parameters. The most commonly needed parameters are the host to connect to (the host where the MySQL server runs), your MySQL username, and a password. For example: % mysql -h localhost -p -u cbuser Enter password: cbpass In general, I'll show mysql commands in examples with no connection parameter options. I assume that you'll supply any parameters that you need, either on the command line, or in an option file (Recipe 1.5) so that you don't have to type them each time you invoke mysql. If you don't have a MySQL username and password, you need to obtain permission to use the MySQL server, as described earlier in Recipe 1.2. The syntax and default values for the connection parameter options are shown in the following table. These options have both a single-dash short form and a double-dash long form. Parameter type Option syntax forms Default value Hostname -h hostname--host=hostname localhost Username -u username--user=username Your login name Password -p--password None As the table indicates, there is no default password. To supply one, use --password or -p, then enter your password when mysql prompts you for it: % mysql -p Enter password: enter your password here If you like, you can specify the password directly on the command line by using either - ppassword (note that there is no space after the -p) or --password=password. I don't recommend doing this on a multiple-user machine, because the password may be visible momentarily to other users who are running tools such as ps that report process information. If you get an error message that mysql cannot be found or is an invalid command when you try to invoke it, that means your command interpreter doesn't know where mysql is installed. See Recipe 1.8. To terminate a mysql session, issue a QUIT statement: mysql> QUIT You can also terminate the session by issuing an EXIT statement or (under Unix) by typing Ctrl-D. The way you specify connection parameters for mysql also applies to other MySQL programs such as mysqldump and mysqladmin. For example, some of the actions that mysqladmin can perform are available only to the MySQL root account, so you need to specify name and password options for that user: % mysqladmin -p -u root shutdown Enter password: 1.5 Specifying Connection Parameters by Using Option Files 1.5.1 Problem You don't want to type connection parameters on the command line every time you invoke mysql. 1.5.2 Solution Put the parameters in an option file. 1.5.3 Discussion To avoid entering connection parameters manually, put them in an option file for mysql to read automatically. Under Unix, your personal option file is named .my.cnf in your home directory. There are also site-wide option files that administrators can use to specify parameters that apply globally to all users. You can use /etc/my.cnf or the my.cnf file in the MySQL server's data directory. Under Windows, the option files you can use are C:\my.cnf, the my.ini file in your Windows system directory, or my.cnf in the server's data directory. Windows may hide filename extensions when displaying files, so a file named my.cnf may appear to be named just my. Your version of Windows may allow you to disable extension-hiding. Alternatively, issue a DIR command in a DOS window to see full names. The following example illustrates the format used to write MySQL option files: # general client program connection options [client] host=localhost user=cbuser password=cbpass # options specific to the mysql program [mysql] no-auto-rehash # specify pager for interactive mode pager=/usr/bin/less This format has the following general characteristics: · Lines are written in groups. The first line of the group specifies the group name inside of square brackets, and the remaining lines specify options associated with the group. The example file just shown has a [client] group and a [mysql] group. Within a group, option lines are written in name=value format, where name corresponds to an option name (without leading dashes) and value is the option's value. If an option doesn't take any value (such as for the no-auto-rehash option), the name is listed by itself with no trailing =value part. · If you don't need some particular parameter, just leave out the corresponding line. For example, if you normally connect to the default host (localhost), you don't need any host line. If your MySQL username is the same as your operating system login name, you can omit the user line. · In option files, only the long form of an option is allowed. This is in contrast to command lines, where options often can be specified using a short form or a long form. For example, the hostname can be given using either -h hostname or -- host=hostname on the command line; in an option file, only host=hostname is allowed. · Options often are used for connection parameters (such as host, user, and password). However, the file can specify options that have other purposes. The pager option shown for the [mysql] group specifies the paging program that mysql should use for displaying output in interactive mode. It has nothing to do with how the program connects to the server. · The usual group for specifying client connection parameters is [client]. This group actually is used by all the standard MySQL clients, so by creating an option file to use with mysql, you make it easier to invoke other programs such as mysqldump and mysqladmin as well. · You can define multiple groups in an option file. A common convention is for a program to look for parameters in the [client] group and in the group named after the program itself. This provides a convenient way to list general client parameters that you want all client programs to use, but still be able to specify options that apply only to a particular program. The preceding sample option file illustrates this convention for the mysql program, which gets general connection parameters from the [client] group and also picks up the no-auto-rehash and pager options from the [mysql] group. (If you put the mysql-specific options in the [client] group, that will result in "unknown option" errors for all other programs that use the [client] group and they won't run properly.) · If a parameter is specified multiple times in an option file, the last value found takes precedence. This means that normally you should list any program-specific groups after the [client] group so that if there is any overlap in the options set by the two groups, the more general options will be overridden by the program-specific values. · Lines beginning with # or ; characters are ignored as comments. Blank lines are ignored, too. · Option files must be plain text files. If you create an option file with a word processor that uses some non-text format by default, be sure to save the file explicitly as text. Windows users especially should take note of this. · Options that specify file or directory pathnames should be written using / as the pathname separator character, even under Windows. If you want to find out which options will be taken from option files by mysql, use this command: % mysql --print-defaults You can also use the my_print_defaults utility, which takes as arguments the names of the option file groups that it should read. For example, mysql looks in both the [client] and [mysql] groups for options, so you can check which values it will take from option files like this: % my_print_defaults client mysql 1.6 Protecting Option Files 1.6.1 Problem Your MySQL username and password are stored in your option file, and you don't want other users reading it. 1.6.2 Solution Change the file's mode to make it accessible only by you. 1.6.3 Discussion If you use a multiple-user operating system such as Unix, you should protect your option file to prevent other users from finding out how to connect to MySQL using your account. Use chmod to make the file private by setting its mode to allow access only by yourself: % chmod 600 .my.cnf 1.7 Mixing Command-Line and Option File Parameters 1.7.1 Problem You'd rather not store your MySQL password in an option file, but you don't want to enter your username and server host manually. 1.7.2 Solution Put the username and host in the option file, and specify the password interactively when you invoke mysql; it looks both in the option file and on the command line for connection parameters. If an option is specified in both places, the one on the command line takes precedence. 1.7.3 Discussion mysql first reads your option file to see what connection parameters are listed there, then checks the command line for additional parameters. This means you can specify some options one way, and some the other way. Command-line parameters take precedence over parameters found in your option file, so if for some reason you need to override an option file parameter, just specify it on the command line. For example, you might list your regular MySQL username and password in the option file for general purpose use. If you need to connect on occasion as the MySQL root user, specify the user and password options on the command line to override the option file values: % mysql -p -u root To explicitly specify "no password" when there is a non-empty password in the option file, use -p on the command line, and then just press Return when mysql prompts you for the password: % mysql -p Enter password: press Return here 1.8 What to Do if mysql Cannot Be Found 1.8.1 Problem When you invoke mysql from the command line, your command interpreter can't find it. 1.8.2 Solution Add the directory where mysql is installed to your PATH setting. Then you'll be able to run mysql from any directory easily. 1.8.3 Discussion If your shell or command interpreter can't find mysql when you invoke it, you'll see some sort of error message. It may look like this under Unix: % mysql mysql: Command not found. Or like this under Windows: C:\> mysql Bad command or invalid filename One way to tell your shell where to find mysql is to type its full pathname each time you run it. The command might look like this under Unix: % /usr/local/mysql/bin/mysql Or like this under Windows: C:\> C:\mysql\bin\mysql Typing long pathnames gets tiresome pretty quickly, though. You can avoid doing so by changing into the directory where mysql is installed before you run it. However, I recommend that you not do that. If you do, the inevitable result is that you'll end up putting all your datafiles and query batch files in the same directory as mysql, thus unnecessarily cluttering up what should be a location intended only for programs. A better solution is to make sure that the directory where mysql is installed is included in the PATH environment variable that lists pathnames of directories where the shell looks for commands. (See Recipe 1.9.) Then you can invoke mysql from any directory by entering just its name, and your shell will be able to find it. This eliminates a lot of unnecessary pathname typing. An additional benefit is that because you can easily run mysql from anywhere, you will have no need to put your datafiles in the same directory where mysql is located. When you're not operating under the burden of running mysql from a particular location, you'll be free to organize your files in a way that makes sense to you, not in a way imposed by some artificial necessity. For example, you can create a directory under your home directory for each database you have and put the files associated with each database in the appropriate directory. I've pointed out the importance of the search path here because I receive many questions from people who aren't aware of the existence of such a thing, and who consequently try to do all their MySQL-related work in the bin directory where mysql is installed. This seems particularly common among Windows users. Perhaps the reason is that, except for Windows NT and its derivatives, the Windows Help application seems to be silent on the subject of the command interpreter search path or how to set it. (Apparently, Windows Help considers it dangerous for people to know how to do something useful for themselves.) Another way for Windows users to avoid typing the pathname or changing into the mysql directory is to create a shortcut and place it in a more convenient location. That has the advantage of making it easy to start up mysql just by opening the shortcut. To specify command-line options or the startup directory, edit the shortcut's properties. If you don't always invoke mysql with the same options, it might be useful to create a shortcut corresponding to each set of options you need—for example, one shortcut to connect as an ordinary user for general work and another to connect as the MySQL root user for administrative purposes. 1.9 Setting Environment Variables 1.9.1 Problem You need to modify your operating environment, for example, to change your shell's PATH setting. 1.9.2 Solution Edit the appropriate shell startup file. Under Windows NT-based systems, another alternative is to use the System control panel. 1.9.3 Discussion The shell or command interpreter you use to run programs from the command-line prompt includes an environment in which you can store variable values. Some of these variables are used by the shell itself. For example, it uses PATH to determine which directories to look in for programs such as mysql. Other variables are used by other programs (such as PERL5LIB, which tells Perl where to look for library files used by Perl scripts). Your shell determines the syntax used to set environment variables, as well as the startup file in which to place the settings. Typical startup files for various shells are shown in the following table. If you've never looked through your shell's startup files, it's a good idea to do so to familiarize yourself with their contents. Shell Possible startup files csh, tcsh .login, .cshrc, .tcshrc sh, bash, ksh .profile .bash_profile, .bash_login, .bashrc DOS prompt C:\AUTOEXEC.BAT The following examples show how to set the PATH variable so that it includes the directory where the mysql program is installed. The examples assume there is an existing PATH setting in one of your startup files. If you have no PATH setting currently, simply add the appropriate line or lines to one of the files. If you're reading this section because you've been referred here from another chapter, you'll probably be more interested in changing some variable other than PATH. The instructions are similar because you use the same syntax. The PATH variable lists the pathnames for one or more directories. If an environment variable's value consists of multiple pathnames, it's conventional under Unix to separate them using the colon character (:). Under Windows, pathnames may contain colons, so the separator is the semicolon character ( ;). To set the value of PATH, use the instructions that pertain to your shell: · For csh or tcsh, look for a setenv PATH command in your startup files, then add the appropriate directory to the line. Suppose your search path is set by a line like this in your .login file: setenv PATH /bin:/usr/bin:/usr/local/bin If mysql is installed in /usr/local/mysql/bin, add that directory to the search path by changing the setenv line to look like this: setenv PATH /usr/local/mysql/bin:/bin:/usr/bin:/usr/local/bin It's also possible that your path will be set with set path, which uses different syntax: set path = (/usr/local/mysql/bin /bin /usr/bin /usr/local/bin) · For a shell in the Bourne shell family such as sh, bash, or ksh, look in your startup files for a line that sets up and exports the PATH variable: export PATH=/bin:/usr/bin:/usr/local/bin The assignment and the export might be on separate lines: PATH=/bin:/usr/bin:/usr/local/bin export PATH Change the setting to this: export PATH=/usr/local/mysql/bin:/bin:/usr/bin:/usr/local/bin Or: PATH=/usr/local/mysql/bin:/bin:/usr/bin:/usr/local/bin export PATH · Under Windows, check for a line that sets the PATH variable in your AUTOEXEC.BAT file. It might look like this: PATH=C:\WINDOWS;C:\WINDOWS\COMMAND Or like this: SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND Change the PATH value to include the directory where mysql is installed. If this is C:\mysql\bin, the resulting PATH setting looks like this: PATH=C:\mysql\bin;C:\WINDOWS;C:\WINDOWS\COMMAND Or: SET PATH=C:\mysql\bin;C:\WINDOWS;C:\WINDOWS\COMMAND · Under Windows NT-based systems, another way to change the PATH value is to use the System control panel (use its Environment or Advanced tab, whichever is present). In other versions of Windows, you can use the Registry Editor application. Unfortunately, the name of the Registry Editor key that contains the path value seems to vary among versions of Windows. For example, on the Windows machines that I use, the key has one name under Windows Me and a different name under Windows 98; under Windows 95, I couldn't find the key at all. It's probably simpler just to edit AUTOEXEC.BAT. After setting an environment variable, you'll need to cause the modification to take effect. Under Unix, you can log out and log in again. Under Windows, if you set PATH using the System control panel, you can simply open a new DOS window. If you edited AUTOEXEC.BAT instead, restart the machine. 1.10 Issuing Queries 1.10.1 Problem You've started mysql and now you want to send queries to the MySQL server. 1.10.2 Solution Just type them in, but be sure to let mysql know where each one ends. 1.10.3 Discussion To issue a query at the mysql> prompt, type it in, add a semicolon ( ;) at the end to signify the end of the statement, and press Return. An explicit statement terminator is necessary; mysql doesn't interpret Return as a terminator because it's allowable to enter a statement using multiple input lines. The semicolon is the most common terminator, but you can also use \g ("go") as a synonym for the semicolon. Thus, the following examples are equivalent ways of issuing the same query, even though they are entered differently and terminated differently:[2] [2] Example queries in this book are shown with SQL keywords like SELECT in uppercase for distinctiveness, but that's simply a typographical convention. You can enter keywords in any lettercase. mysql> SELECT NOW( ); +---------------------+ | NOW( ) | +---------------------+ | 2001-07-04 10:27:23 | +---------------------+ mysql> SELECT -> NOW( )\g +---------------------+ | NOW( ) | +---------------------+ | 2001-07-04 10:27:28 | +---------------------+ Notice for the second query that the prompt changes from mysql> to -> on the second input line. mysql changes the prompt this way to let you know that it's still waiting to see the query terminator. Be sure to understand that neither the ; character nor the \g sequence that serve as query terminators are part of the query itself. They're conventions used by the mysql program, which recognizes these terminators and strips them from the input before sending the query to the MySQL server. It's important to remember this when you write your own programs that send queries to the server (as we'll begin to do in the next chapter). In that context, you don't include any terminator characters; the end of the query string itself signifies the end of the query. In fact, adding a terminator may well cause the query to fail with an error. 1.11 Selecting a Database 1.11.1 Problem You want to tell mysql which database to use. 1.11.2 Solution Name the database on the mysql command line or issue a USE statement from within mysql. 1.11.3 Discussion When you issue a query that refers to a table (as most queries do), you need to indicate which database the table is part of. One way to do so is to use a fully qualified table reference that begins with the database name. (For example, cookbook.limbs refers to the limbs table in the cookbook database.) As a convenience, MySQL also allows you to select a default (current) database so that you can refer to its tables without explicitly specifying the database name each time. You can specify the database on the command line when you start mysql: % mysql cookbook If you provide options on the command line such as connection parameters when you run mysql, they should precede the database name: % mysql -h host -p -u user cookbook If you've already started a mysql session, you can select a database (or switch to a different one) by issuing a USE statement: mysql> USE cookbook; Database changed If you've forgotten or are not sure which database is the current one (which can happen easily if you're using multiple databases and switching between them several times during the course of a mysql session), use the following statement: mysql> SELECT DATABASE( ); +------------+ | DATABASE() | +------------+ | cookbook | +------------+ DATABASE( ) is a function that returns the name of the current database. If no database has been selected yet, the function returns an empty string: mysql> SELECT DATABASE( ); +------------+ | DATABASE() | +------------+ | | +------------+ The STATUS command (and its synonym, \s) also display the current database name, in additional to several other pieces of information: mysql> \s -------------- Connection id: 5589 Current database: cookbook Current user: cbuser@localhost Current pager: stdout Using outfile: '' Server version: 3.23.51-log Protocol version: 10 Connection: Localhost via UNIX socket Client characterset: latin1 Server characterset: latin1 UNIX socket: /tmp/mysql.sock Uptime: 9 days 39 min 43 sec Threads: 4 Questions: 42265 Slow queries: 0 Opens: 82 Flush tables: 1 Open tables: 52 Queries per second avg: 0.054 -------------- Temporarily Using a Table from Another Database To use a table from another database temporarily, you can switch to that database and then switch back when you're done using the table. However, you can also use the table without switching databases by referring to the table using its fully qualified name. For example, to use the table other_tbl in another database other_db, you can refer to it as other_db.other_tbl. 1.12 Canceling a Partially Entered Query 1.12.1 Problem You start to enter a query, then decide not to issue it after all. 1.12.2 Solution Cancel the query using your line kill character or the \c sequence. 1.12.3 Discussion If you change your mind about issuing a query that you're entering, cancel it. If the query is on a single line, use your line kill character to erase the entire line. (The particular character to use depends on your terminal setup; for me, the character is Ctrl-U.) If you've entered a statement over multiple lines, the line kill character will erase only the last line. To cancel the statement completely, enter \c and type Return. This will return you to the mysql> prompt: mysql> SELECT * -> FROM limbs -> ORDER BY\c mysql> Sometimes \c appears to do nothing (that is, the mysql> prompt does not reappear), which leads to the sense that you're "trapped" in a query and can't escape. If \c is ineffective, the cause usually is that you began typing a quoted string and haven't yet entered the matching end quote that terminates the string. Let mysql's prompt help you figure out what to do here. If the prompt has changed from mysql> to ">, That means mysql is looking for a terminating double quote. If the prompt is '> instead, mysql is looking for a terminating single quote. Type the appropriate matching quote to end the string, then enter \c followed by Return and you should be okay. 1.13 Repeating and Editing Queries 1.13.1 Problem The query you just entered contained an error, and you want to fix it without typing the whole thing again. Or you want to repeat an earlier statement without retyping it. 1.13.2 Solution Use mysql's built-in query editor. 1.13.3 Discussion If you issue a long query only to find that it contains a syntax error, what should you do? Type in the entire corrected query from scratch? No need. mysql maintains a statement history and supports input-line editing. This allows you to recall queries so that you can modify and reissue them easily. There are many, many editing functions, but most people tend to use a small set of commands for the majority of their editing.[3] A basic set of useful commands is shown in the following table. Typically, you use Up Arrow to recall the previous line, Left Arrow and Right Arrow to move around within the line, and Backspace or Delete to erase characters. To add new characters to the line, just move the cursor to the appropriate spot and type them in. When you're done editing, press Return to issue the query (the cursor need not be at the end of the line when you do this). [3] The input-line editing capabilities in mysql are based on the GNU Readline library. You can read the documentation for this library to find out more about the many editing functions that are available. For more information, check the Bash manual, available online at http://www.gnu.org/manual/. Editing Key Effect of Key Up Arrow Scroll up through statement history Down Arrow Scroll down through statement history Left Arrow Move left within line Right Arrow Move right within line Ctrl-A Move to beginning of line Ctrl-E Move to end of line Backspace Delete previous character Ctrl-D Delete character under cursor Input-line editing is useful for more than just fixing mistakes. You can use it to try out variant forms of a query without retyping the entire thing each time. It's also handy for entering a series of similar statements. For example, if you wanted to use the query history to issue the series of INSERT statements shown earlier in Recipe 1.3 to create the limbs table, first enter the initial INSERT statement. Then, to issue each successive statement, press the Up Arrow key to recall the previous statement with the cursor at the end, backspace back through the column values to erase them, enter the new values, and press Return. To recall a statement that was entered on multiple lines, the editing procedure is a little trickier than for single-line statements. In this case, you must recall and reenter each successive line of the query in order. For example, if you've entered a two-line query that contains a mistake, press Up Arrow twice to recall the first line. Make any modifications necessary and press Return. Then press Up Arrow twice more to recall the second line. Modify it, press Return, and the query will execute. Under Windows, mysql allows statement recall only for NT-based systems. For versions such as Windows 98 or Me, you can use the special mysqlc client program instead. However, mysqlc requires an additional library file, cygwinb19.dll. If you find a copy of this library in the same directory where mysqlc is installed (the bin dir under the MySQL installation directory), you should be all set. If the library is located in the MySQL lib directory, copy it into your Windows system directory. The command looks something like this; you should modify it to reflect the actual locations of the two directories on your system: C:\> copy C:\mysql\lib\cygwinb19.dll C:\Windows\System After you make sure the library is in a location where mysqlc can find it, invoke mysqlc and it should be capable of input-line editing. One unfortunate consequence of using mysqlc is that it's actually a fairly old program. (For example, even in MySQL 4.x distributions, mysqlc dates back to 3.22.7.) This means it doesn't understand newer statements such as SOURCE. 1.14 Using Auto-Completion for Database and Table Names 1.14.1 Problem You wish there was a way to type database and table names more quickly. 1.14.2 Solution There is; use mysql's name auto-completion facility. 1.14.3 Discussion Normally when you use mysql interactively, it reads the list of database names and the names of the tables and columns in your current database when it starts up. mysql remembers this information to provide name completion capabilities that are useful for entering statements with fewer keystrokes: · Type in a partial database, table, or column name and then hit the Tab key. · If the partial name is unique, mysql completes it for you. Otherwise, you can hit Tab again to see the possible matches. · Enter additional characters and hit Tab again once to complete it or twice to see the new set of matches. mysql's name auto-completion capability is based on the table names in the current database, and thus is unavailable within a mysql session until a database has been selected, either on the command line or by means of a USE statement. Auto-completion allows you to cut down the amount of typing you do. However, if you don't use this feature, reading name-completion information from the MySQL server may be counterproductive because it can cause mysql to start up more slowly when you have a lot of tables in your database. To tell mysql not to read this information so that it starts up more quickly, specify the -A (or --no-auto-rehash) option on the mysql command line. Alternatively, put a no-auto-rehash line in the [mysql] group of your MySQL option file: [mysql] no-auto-rehash To force mysql to read name completion information even if it was invoked in no-completion mode, issue a REHASH or \# command at the mysql> prompt. 1.15 Using SQL Variables in Queries 1.15.1 Problem You want to save a value from a query so you can refer to it in a subsequent query. 1.15.2 Solution Use a SQL variable to store the value for later use. 1.15.3 Discussion As of MySQL 3.23.6, you can assign a value returned by a SELECT statement to a variable, then refer to the variable later in your mysql session. This provides a way to save a result returned from one query, then refer to it later in other queries. The syntax for assigning a value to a SQL variable within a SELECT query is @var_name := value, where var_name is the variable name and value is a value that you're retrieving. The variable may be used in subsequent queries wherever an expression is allowed, such as in a WHERE clause or in an INSERT statement. A common situation in which SQL variables come in handy is when you need to issue successive queries on multiple tables that are related by a common key value. Suppose you have a customers table with a cust_id column that identifies each customer, and an orders table that also has a cust_id column to indicate which customer each order is associated with. If you have a customer name and you want to delete the customer record as well as all the customer's orders, you need to determine the proper cust_id value for that customer, then delete records from both the customers and orders tables that match the ID. One way to do this is to first save the ID value in a variable, then refer to the variable in the DELETE statements:[4] [4] In MySQL 4, you can use multiple-table DELETE statements to accomplish tasks like this with a single query. See Chapter 12 for examples. mysql> SELECT @id := cust_id FROM customers WHERE cust_id=' customer name '; mysql> DELETE FROM customers WHERE cust_id = @id; mysql> DELETE FROM orders WHERE cust_id = @id; The preceding SELECT statement assigns a column value to a variable, but variables also can be assigned values from arbitrary expressions. The following statement determines the highest sum of the arms and legs columns in the limbs table and assigns it to the @max_limbs variable: mysql> SELECT @max_limbs := MAX(arms+legs) FROM limbs; Another use for a variable is to save the result from LAST_INSERT_ID( ) after creating a new record in a table that has an AUTO_INCREMENT column: mysql> SELECT @last_id := LAST_INSERT_ID( ); LAST_INSERT_ID( ) returns the value of the new AUTO_INCREMENT value. By saving it in a variable, you can refer to the value several times in subsequent statements, even if you issue other statements that create their own AUTO_INCREMENT values and thus change the value returned by LAST_INSERT_ID( ). This is discussed further in Chapter 11. SQL variables hold single values. If you assign a value to a variable using a statement that returns multiple rows, the value from the last row is used: mysql> SELECT @name := thing FROM limbs WHERE legs = 0; +----------------+ | @name := thing | +----------------+ | squid | | octopus | | fish | | phonograph | +----------------+ mysql> SELECT @name; +------------+ | @name | +------------+ | phonograph | +------------+ If the statement returns no rows, no assignment takes place and the variable retains its previous value. If the variable has not been used previously, that value is NULL: mysql> SELECT @name2 := thing FROM limbs WHERE legs < 0; Empty set (0.00 sec) mysql> SELECT @name2; +--------+ | @name2 | +--------+ | NULL | +--------+ To set a variable explicitly to a particular value, use a SET statement. SET syntax uses = rather than := to assign the value: mysql> SET @sum = 4 + 7; mysql> SELECT @sum; +------+ | @sum | +------+ | 11 | +------+ A given variable's value persists until you assign it another value or until the end of your mysql session, whichever comes first. Variable names are case sensitive: mysql> SET @x = 1; SELECT @x, @X; +------+------+ | @x | @X | +------+------+ | 1 | NULL | +------+------+ SQL variables can be used only where expressions are allowed, not where constants or literal identifiers must be provided. Although it's tempting to attempt to use variables for such things as table names, it doesn't work. For example, you might try to generate a temporary table name using a variable as follows, but the result is only an error message: mysql> SET @tbl_name = CONCAT('tbl_',FLOOR(RAND( )*1000000)); mysql> CREATE TABLE @tbl_name (int_col INT); ERROR 1064 at line 2: You have an error in your SQL syntax near '@tbl_name (int_col INT)' at line 1 SQL variables are a MySQL-specific extension, so they will not work with other database engines. 1.16 Telling mysql to Read Queries from a File 1.16.1 Problem You want mysql to read queries stored in a file so you don't have to enter them manually. 1.16.2 Solution Redirect mysql's input or use the SOURCE command. 1.16.3 Discussion By default, the mysql program reads input interactively from the terminal, but you can feed it queries in batch mode using other input sources such as a file, another program, or the command arguments. You can also use copy and paste as a source of query input. This section discusses how to read queries from a file. The next few sections discuss how to take input from other sources. To create a SQL script for mysql to execute in batch mode, put your statements in a text file, then invoke mysql and redirect its input to read from that file: % mysql cookbook < filename Statements that are read from an input file substitute for what you'd normally type in by hand, so they must be terminated with semicolons (or \g), just as if you were entering them manually. One difference between interactive and batch modes is the default output style. For interactive mode, the default is tabular (boxed) format. For batch mode, the default is to delimit column values with tabs. However, you can select whichever output style you want using the appropriate command-line options. See the section on selecting tabular or tab- delimited format later in the chapter (Recipe 1.22). Batch mode is convenient when you need to issue a given set of statements on multiple occasions, because then you need not enter them manually each time. For example, batch mode makes it easy to set up cron jobs that run with no user intervention. SQL scripts are also useful for distributing queries to other people. Many of the examples shown in this book can be run using script files that are available as part of the accompanying recipes source distribution (see Appendix A). You can feed these files to mysql in batch mode to avoid typing queries yourself. A common instance of this is that when an example shows a CREATE TABLE statement that describes what a particular table looks like, you'll find a SQL batch file in the distribution that can be used to create (and perhaps load data into) the table. For example, earlier in the chapter, statements for creating and populating the limbs table were shown. The recipes distribution includes a file limbs.sql that contains statements to do the same thing. The file looks like this: DROP TABLE IF EXISTS limbs; CREATE TABLE limbs ( thing VARCHAR(20), # what the thing is legs INT, # number of legs it has arms INT # number of arms it has ); INSERT INTO limbs (thing,legs,arms) VALUES('human',2,2); INSERT INTO limbs (thing,legs,arms) VALUES('insect',6,0); INSERT INTO limbs (thing,legs,arms) VALUES('squid',0,10); INSERT INTO limbs (thing,legs,arms) VALUES('octopus',0,8); INSERT INTO limbs (thing,legs,arms) VALUES('fish',0,0); INSERT INTO limbs (thing,legs,arms) VALUES('centipede',100,0); INSERT INTO limbs (thing,legs,arms) VALUES('table',4,0); INSERT INTO limbs (thing,legs,arms) VALUES('armchair',4,2); INSERT INTO limbs (thing,legs,arms) VALUES('phonograph',0,1); INSERT INTO limbs (thing,legs,arms) VALUES('tripod',3,0); INSERT INTO limbs (thing,legs,arms) VALUES('Peg Leg Pete',1,2); INSERT INTO limbs (thing,legs,arms) VALUES('space alien',NULL,NULL); To execute the statements in this SQL script file in batch mode, change directory into the tables directory of the recipes distribution where the table-creation scripts are located, then run this command: % mysql cookbook < limbs.sql You'll note that the script contains a statement to drop the table if it exists before creating it anew and loading it with data. That allows you to experiment with the table without worrying about changing its contents, because you can restore the table to its baseline state any time by running the script again. The command just shown illustrates how to specify an input file for mysql on the command line. As of MySQL 3.23.9, you can read a file of SQL statements from within a mysql session by using a SOURCE filename command (or \. filename, which is synonymous). Suppose the SQL script file test.sql contains the following statements: SELECT NOW( ); SELECT COUNT(*) FROM limbs; You can execute that file from within mysql as follows: mysql> SOURCE test.sql; +---------------------+ | NOW( ) | +---------------------+ | 2001-07-04 10:35:08 | +---------------------+ 1 row in set (0.00 sec) +----------+ | COUNT(*) | +----------+ | 12 | +----------+ 1 row in set (0.01 sec) SQL scripts can themselves include SOURCE or \. commands to include other scripts. The danger of this is that it's possible to create a source loop. Normally you should take care to avoid such loops, but if you're feeling mischievous and want to create one deliberately to find out how deep mysql can nest input files, here's how to do it. First, issue the following two statements manually to create a counter table to keep track of the source file depth and initialize the nesting level to zero: mysql> CREATE TABLE counter (depth INT); mysql> INSERT INTO counter SET depth = 0; Then create a script file loop.sql that contains the following lines (be sure each line ends with a semicolon): UPDATE counter SET depth = depth + 1; SELECT depth FROM counter; SOURCE loop.sql; Finally, invoke mysql and issue a SOURCE command to read the script file: % mysql cookbook mysql> SOURCE loop.sql; The first two statements in loop.sql increment the nesting counter and display the current depth value. In the third statement, loop.sql sources itself, thus creating an input loop. You'll see the output whiz by, with the counter display incrementing each time through the loop. Eventually mysql will run out of file descriptors and stop with an error: ERROR: Failed to open file 'loop.sql', error: 24 What is error 24? Find out by using MySQL's perror (print error) utility: % perror 24 Error code 24: Too many open files 1.17 Telling mysql to Read Queries from Other Programs 1.17.1 Problem You want to shove the output from another program into mysql. 1.17.2 Solution Use a pipe. 1.17.3 Discussion An earlier section used the following command to show how mysql can read SQL statements from a file: % mysql cookbook < limbs.sql mysql can also read a pipe, to receive output from other programs as its input. As a trivial example, the preceding command is equivalent to this one: % cat limbs.sql | mysql cookbook Before you tell me that I've qualified for this week's "useless use of cat award,"[5] allow me to observe that you can substitute other commands for cat. The point is that any command that produces output consisting of semicolon-terminated SQL statements can be used as an input source for mysql. This can be useful in many ways. For example, the mysqldump utility is used to generate database backups. It writes a backup as a set of SQL statements that recreate the database, so to process mysqldump output, you feed it to mysql. This means you can use the combination of mysqldump and mysql to copy a database over the network to another MySQL server: [5] Under Windows, the equivalent would be the "useless use of type award": % mysqldump cookbook | mysql -h some.other.host.com cookbook Program-generated SQL also can be useful when you need to populate a table with test data but don't want to write the INSERT statements by hand. Instead, write a short program that generates the statements and send its output to mysql using a pipe: % generate-test-data | mysql cookbook 1.17.4 See Also mysqldump is discussed further in Chapter 10. 1.18 Specifying Queries on the Command Line 1.18.1 Problem You want to specify a query directly on the command line for mysql to execute. 1.18.2 Solution mysql can read a query from its argument list. Use the -e (or --execute) option to specify a query on the command line. 1.18.3 Discussion For example, to find out how many records are in the limbs table, run this command: % mysql -e "SELECT COUNT(*) FROM limbs" cookbook +----------+ | COUNT(*) | +----------+ | 12 | +----------+ To run multiple queries with the -e option, separate them with semicolons: % mysql -e "SELECT COUNT(*) FROM limbs;SELECT NOW( )" cookbook +----------+ | COUNT(*) | +----------+ | 12 | +----------+ +---------------------+ | NOW( ) | +---------------------+ | 2001-07-04 10:42:22 | +---------------------+ 1.18.4 See Also By default, results generated by queries that are specified with -e are displayed in tabular format if output goes to the terminal, and in tab-delimited format otherwise. To produce a different output style, see Recipe 1.22. 1.19 Using Copy and Paste as a mysql Input Source 1.19.1 Problem You want to take advantage of your graphical user interface (GUI) to make mysql easier to use. 1.19.2 Solution Use copy and paste to supply mysql with queries to execute. In this way, you can take advantage of your GUI's capabilities to augment the terminal interface presented by mysql. 1.19.3 Discussion Copy and paste is useful in a windowing environment that allows you to run multiple programs at once and transfer information between them. If you have a document containing queries open in a window, you can just copy the queries from there and paste them into the window in which you're running mysql. This is equivalent to typing the queries yourself, but often quicker. For queries that you issue frequently, keeping them visible in a separate window can be a good way to make sure they're always at your fingertips and easily accessible. 1.20 Preventing Query Output from Scrolling off the Screen 1.20.1 Problem Query output zooms off the top of your screen before you can see it. 1.20.2 Solution Tell mysql to display output a page at a time, or run mysql in a window that allows scrollback. 1.20.3 Discussion If a query produces many lines of output, normally they just scroll right off the top of the screen. To prevent this, tell mysql to present output a page at a time by specifying the --pager option.[6] --pager=program tells mysql to use a specific program as your pager: [6] The --pager option is not available under Windows. % mysql --pager=/usr/bin/less --pager by itself tells mysql to use your default pager, as specified in your PAGER environment variable: % mysql --pager If your PAGER variable isn't set, you must either define it or use the first form of the command to specify a pager program explicitly. To define PAGER, use the instructions in Recipe 1.9 for setting environment variables. Within a mysql session, you can turn paging on and off using \P and \n. \P without an argument enables paging using the program specified in your PAGER variable. \P with an argument enables paging using the argument as the name of the paging program: mysql> \P PAGER set to /bin/more mysql> \P /usr/bin/less PAGER set to /usr/bin/less mysql> \n PAGER set to stdout Output paging was introduced in MySQL 3.23.28. Another way to deal with long result sets is to use a terminal program that allows you to scroll back through previous output. Programs such as xterm for the X Window System, Terminal for Mac OS X, MacSSH or BetterTelnet for Mac OS, or Telnet for Windows allow you to set the number of output lines saved in the scrollback buffer. Under Windows NT, 2000, or XP, you can set up a DOS window that allows scrollback using the following procedure: 1. Open the Control Panel. 2. Create a shortcut to the MS-DOS prompt by right clicking on the Console item and dragging the mouse to where you want to place the shortcut (on the desktop, for example). 3. Right click on the shortcut and select the Properties item from the menu that appears. 4. Select the Layout tab in the resulting Properties window. 5. Set the screen buffer height to the number of lines you want to save and click the OK button. Now you should be able to launch the shortcut to get a scrollable DOS window that allows output produced by commands in that window to be retrieved by using the scrollbar. 1.21 Sending Query Output to a File or to a Program 1.21.1 Problem You want to send mysql output somewhere other than to your screen. 1.21.2 Solution Redirect mysql's output or use a pipe. 1.21.3 Discussion mysql chooses its default output format according to whether you run it interactively or non- interactively. Under interactive use, mysql normally sends its output to the terminal and writes query results using tabular format: mysql> SELECT * FROM limbs; +--------------+------+------+ | thing | legs | arms | +--------------+------+------+ | human | 2 | 2 | | insect | 6 | 0 | | squid | 0 | 10 | | octopus | 0 | 8 | | fish | 0 | 0 | | centipede | 100 | 0 | | table | 4 | 0 | | armchair | 4 | 2 | | phonograph | 0 | 1 | | tripod | 3 | 0 | | Peg Leg Pete | 1 | 2 | | space alien | NULL | NULL | +--------------+------+------+ 12 rows in set (0.00 sec) In non-interactive mode (that is, when either the input or output is redirected), mysql writes output in tab-delimited format: % echo "SELECT * FROM limbs" | mysql cookbook thing legs arms human 2 2 insect 6 0 squid 0 10 octopus 0 8 fish 0 0 centipede 100 0 table 4 0 armchair 4 2 phonograph 0 1 tripod 3 0 Peg Leg Pete 1 2 space alien NULL NULL However, in either context, you can select any of mysql's output formats by using the appropriate command-line options. This section describes how to send mysql output somewhere other than the terminal. The next several sections discuss the various mysql output formats and how to select them explicitly according to your needs when the default format isn't what you want. To save output from mysql in a file, use your shell's standard redirection capability: % mysql cookbook > outputfile However, if you try to run mysql interactively with the output redirected, you won't be able to see what you're typing, so generally in this case you'll also take query input from a file (or another program): % mysql cookbook < inputfile > outputfile You can also send query output to another program. For example, if you want to mail query output to someone, you might do so like this: % mysql cookbook < inputfile | mail paul Note that because mysql runs non-interactively in that context, it produces tab-delimited output, which the mail recipient may find more difficult to read than tabular output. Recipe 1.22 shows how to fix this problem. 1.22 Selecting Tabular or Tab-Delimited Query Output Format 1.22.1 Problem mysql produces tabular output when you want tab-delimited output, or vice versa. 1.22.2 Solution Select the desired format explicitly with the appropriate command-line option. 1.22.3 Discussion When you use mysql non-interactively (such as to read queries from a file or to send results into a pipe), it writes output in tab-delimited format by default. Sometimes it's desirable to produce tabular output instead. For example, if you want to print or mail query results, tab- delimited output doesn't look very nice. Use the -t (or --table) option to produce tabular output that is more readable: % mysql -t cookbook < inputfile | lpr % mysql -t cookbook < inputfile | mail paul The inverse operation is to produce batch (tab-delimited) output in interactive mode. To do this, use -B or --batch. 1.23 Specifying Arbitrary Output Column Delimiters 1.23.1 Problem You want mysql to produce query output using a delimiter other than tab. 1.23.2 Solution Postprocess mysql's output. 1.23.3 Discussion In non-interactive mode, mysql separates output columns with tabs and there is no option for specifying the output delimiter. Under some circumstances, it may be desirable to produce output that uses a different delimiter. Suppose you want to create an output file for use by a program that expects values to be separated by colon characters (:) rather than tabs. Under Unix, you can convert tabs to arbitrary delimiters by using utilities such as tr and sed. For example, to change tabs to colons, any of the following commands would work (TAB indicates where you type a tab character):[7] [7] The syntax for some versions of tr may be different; consult your local documentation. Also, some shells use the tab character for special purposes such as filename completion. For such shells, type a literal tab into the command by preceding it with Ctrl-V. % mysql cookbook < inputfile | sed -e "s/ TAB /:/g" > outputfile % mysql cookbook < inputfile | tr " TAB " ":" > outputfile % mysql cookbook < inputfile | tr "\011" ":" > outputfile sed is more powerful than tr because it understands regular expressions and allows multiple substitutions. This is useful when you want to produce output in something like comma- separated values (CSV) format, which requires three substitutions: · Escape any quote characters that appear in the data by doubling them so that when you use the resulting CSV file, they won't be taken as column delimiters. · Change the tabs to commas. · Surround column values with quotes. sed allows all three subsitutions to be performed in a single command: % mysql cookbook < inputfile \ | sed -e 's/"/""/g' -e 's/ TAB /","/g' -e 's/^/"/' -e 's/$/"/' > outputfile That's fairly cryptic, to say the least. You can achieve the same result with other languages that may be easier to read. Here's a short Perl script that does the same thing as the sed command (it converts tab-delimited input to CSV output), and includes comments to document how it works: #! /usr/bin/perl -w while (<>) # read next input line { s/"/""/g; # double any quotes within column values s/\t/","/g; # put `","' between column values s/^/"/; # add `"' before the first value s/$/"/; # add `"' after the last value print; # print the result } exit (0); If you name the script csv.pl, you can use it like this: % mysql cookbook < inputfile | csv.pl > outputfile If you run the command under a version of Windows that doesn't know how to associate .pl files with Perl, it may be necessary to invoke Perl explicitly: C:\> mysql cookbook < inputfile | perl csv.pl > outputfile Perl may be more suitable if you need a cross-platform solution, because it runs under both Unix and Windows. tr and sed normally are unavailable under Windows. 1.23.4 See Also An even better way to produce CSV output is to use the Perl Text::CSV_XS module, which was designed for that purpose. This module is discussed in Chapter 10, where it's used to construct a more general-purpose file reformatter. 1.24 Producing HTML Output 1.24.1 Problem You'd like to turn a query result into HTML. 1.24.2 Solution mysql can do that for you. 1.24.3 Discussion mysql generates result set output as HTML tables if you use -H (or --html) option. This gives you a quick way to produce sample output for inclusion into a web page that shows what the result of a query looks like.[8] Here's an example that shows the difference between tabular format and HTML table output (a few line breaks have been added to the HTML output to make it easier to read): [8] I'm referring to writing static HTML pages here. If you're writing a script that produces web pages on the fly, there are better ways to generate HTML output from a query. For more information on writing web scripts, see Chapter 16. % mysql -e "SELECT * FROM limbs WHERE legs=0" cookbook +------------+------+------+ | thing | legs | arms | +------------+------+------+ | squid | 0 | 10 | | octopus | 0 | 8 | | fish | 0 | 0 | | phonograph | 0 | 1 | +------------+------+------+ % mysql -H -e "SELECT * FROM limbs WHERE legs=0" cookbook
thinglegsarms
squid010
octopus08
fish00
phonograph01
The first line of the table contains column headings. If you don't want a header row, see Recipe 1.26. The -H and --html options produce output only for queries that generate a result set. No output is written for queries such as INSERT or UPDATE statements. -H and --html may be used as of MySQL 3.22.26. (They actually were introduced in an earlier version, but the output was not quite correct.) 1.25 Producing XML Output 1.25.1 Problem You'd like to turn a query result into XML. 1.25.2 Solution mysql can do that for you. 1.25.3 Discussion mysql creates an XML document from the result of a query if you use the -X (or --xml) option. Here's an example that shows the difference between tabular format and the XML created from the same query: % mysql -e "SELECT * FROM limbs WHERE legs=0" cookbook +------------+------+------+ | thing | legs | arms | +------------+------+------+ | squid | 0 | 10 | | octopus | 0 | 8 | | fish | 0 | 0 | | phonograph | 0 | 1 | +------------+------+------+ % mysql -X -e "SELECT * FROM limbs WHERE legs=0" cookbook squid 0 10 octopus 0 8 fish 0 0 phonograph 0 1 -X and --xml may be used as of MySQL 4.0. If your version of MySQL is older than that, you can write your own XML generator. See Recipe 10.42. 1.26 Suppressing Column Headings in Query Output 1.26.1 Problem You don't want to include column headings in query output. 1.26.2 Solution Turn column headings off with the appropriate command-line option. Normally this is -N or -- skip-column-names, but you can use -ss instead. 1.26.3 Discussion Tab-delimited format is convenient for generating datafiles that you can import into other programs. However, the first row of output for each query lists the column headings by default, which may not always be what you want. Suppose you have a program named summarize the produces various descriptive statistics for a column of numbers. If you're producing output from mysql to be used with this program, you wouldn't want the header row because it would throw off the results. That is, if you ran a command like this, the output would be inaccurate because summarize would count the column heading: % mysql -e "SELECT arms FROM limbs" cookbook | summarize To create output that contains only data values, suppress the column header row with the -N (or --skip-column-names) option: % mysql -N -e "SELECT arms FROM limbs" cookbook | summarize -N and --skip-column-names were introduced in MySQL 3.22.20. For older versions, you can achieve the same effect by specifying the "silent" option (-s or --silent) twice: % mysql -ss -e "SELECT arms FROM limbs" cookbook | summarize Under Unix, another alternative is to use tail to skip the first line: % mysql -e "SELECT arms FROM limbs" cookbook | tail +2 | summarize 1.27 Numbering Query Output Lines 1.27.1 Problem You'd like the lines of a query result nicely numbered. 1.27.2 Solution Postprocess the output from mysql, or use a SQL variable. 1.27.3 Discussion The -N option can be useful in combination with cat -n when you want to number the output rows from a query under Unix: % mysql -N -e "SELECT thing, arms FROM limbs" cookbook | cat -n 1 human 2 2 insect 0 3 squid 10 4 octopus 8 5 fish 0 6 centipede 0 7 table 0 8 armchair 2 9 phonograph 1 10 tripod 0 11 Peg Leg Pete 2 12 NULL Another option is to use a SQL variable. Expressions involving variables are evaluated for each row of a query result, a property that you can use to provide a column of row numbers in the output: mysql> SET @n = 0; mysql> SELECT @n := @n+1 AS rownum, thing, arms, legs FROM limbs; +--------+--------------+------+------+ | rownum | thing | arms | legs | +--------+--------------+------+------+ | 1 | human | 2 | 2 | | 2 | insect | 0 | 6 | | 3 | squid | 10 | 0 | | 4 | octopus | 8 | 0 | | 5 | fish | 0 | 0 | | 6 | centipede | 0 | 100 | | 7 | table | 0 | 4 | | 8 | armchair | 2 | 4 | | 9 | phonograph | 1 | 0 | | 10 | tripod | 0 | 3 | | 11 | Peg Leg Pete | 2 | 1 | | 12 | space alien | NULL | NULL | +--------+--------------+------+------+ 1.28 Making Long Output Lines More Readable 1.28.1 Problem The output lines from a query are too long. They wrap around and make a mess of your screen. 1.28.2 Solution Use vertical output format. 1.28.3 Discussion Some queries generate output lines that are so long they take up more than one line on your terminal, which can make query results difficult to read. Here is an example that shows what excessively long query output lines might look like on your screen:[9] [9] Prior to MySQL 3.23.32, omit the FULL keyword from the SHOW COLUMNS statement. mysql> SHOW FULL COLUMNS FROM limbs; +-------+-------------+------+-----+---------+-------+---------------------------------+ | Field | Type | Null | Key | Default | Extra | Privileges | +-------+-------------+------+-----+---------+-------+---------------------------------+ | thing | varchar(20) | YES | | NULL | | select,insert,update,references | | legs | int(11) | YES | | NULL | | select,insert,update,references | | arms | int(11) | YES | | NULL | | select,insert,update,references | +-------+-------------+------+-----+---------+-------+---------------------------------+ An alternative is to generate "vertical" output with each column value on a separate line. This is done by terminating a query with \G rather than with a ; character or with \g. Here's what the result from the preceding query looks like when displayed using vertical format: mysql> SHOW FULL COLUMNS FROM limbs\G *************************** 1. row *************************** Field: thing Type: varchar(20) Null: YES Key: Default: NULL Extra: Privileges: select,insert,update,references *************************** 2. row *************************** Field: legs Type: int(11) Null: YES Key: Default: NULL Extra: Privileges: select,insert,update,references *************************** 3. row *************************** Field: arms Type: int(11) Null: YES Key: Default: NULL Extra: Privileges: select,insert,update,references To specify vertical output from the command line, use the -E (or --vertical) option when you invoke mysql. This affects all queries issued during the session, something that can be useful when using mysql to execute a script. (If you write the statements in the SQL script file using the usual semicolon terminator, you can select normal or vertical output from the command line by selective use of -E.) 1.29 Controlling mysql's Verbosity Level 1.29.1 Problem You want mysql to produce more output. Or less. 1.29.2 Solution Use the -v or -s options for more or less verbosity. 1.29.3 Discussion When you run mysql non-interactively, not only does the default output format change, it becomes more terse. For example, mysql doesn't print row counts or indicate how long queries took to execute. To tell mysql to be more verbose, use -v or --verbose. These options can be specified multiple times for increasing verbosity. Try the following commands to see how the output differs: % echo "SELECT NOW( )" | mysql % echo "SELECT NOW( )" | mysql -v % echo "SELECT NOW( )" | mysql -vv % echo "SELECT NOW( )" | mysql -vvv The counterparts of -v and --verbose are -s and --silent. These options too may be used multiple times for increased effect. 1.30 Logging Interactive mysql Sessions 1.30.1 Problem You want to keep a record of what you did in a mysql session. 1.30.2 Solution Create a tee file. 1.30.3 Discussion If you maintain a log of an interactive MySQL session, you can refer back to it later to see what you did and how. Under Unix, you can use the script program to save a log of a terminal session. This works for arbitrary commands, so it works for interactive mysql sessions, too. However, script also adds a carriage return to every line of the transcript, and it includes any backspacing and corrections you make as you're typing. A method of logging an interactive mysql session that doesn't add extra messy junk to the log file (and that works under both Unix and Windows) is to start mysql with a --tee option that specifies the name of the file in which to record the session:[10] [10] It's called a "tee" because it's similar to the Unix tee utility. For more background, try this command: % mysql --tee=tmp.out cookbook To control session logging from within mysql, use \T and \t to turn tee output on and off. This is useful if you want to record only parts of a session: mysql> \T tmp.out Logging to file 'tmp.out' mysql> \t Outfile disabled. A tee file contains the queries you enter as well as the output from those queries, so it's a convenient way to keep a complete record of them. It's useful, for example, when you want to print or mail a session or parts of it, or for capturing query output to include as an example in a document. It's also a good way to try out queries to make sure you have the syntax correct before putting them in a script file; you can create the script from the tee file later by editing it to remove everything except those queries you want to keep. mysql appends session output to the end of the tee file rather than overwriting it. If you want an existing file to contain only the contents of a single session, remove it first before invoking mysql. The ability to create tee files was introduced in MySQL 3.23.28. 1.31 Creating mysql Scripts from Previously Executed Queries 1.31.1 Problem You want to reuse queries that were issued during an earlier mysql session. 1.31.2 Solution Use a tee file from the earlier session, or look in mysql's statement history file. 1.31.3 Discussion One way to create a batch file is to enter your queries into the file from scratch with a text editor and hope that you don't make any mistakes while typing them. But it's often easier to use queries that you've already verified as correct. How? First, try out the queries "by hand" using mysql in interactive mode to make sure they work properly. Then, extract the queries from a record of your session to create the batch file. Two sources of information are particularly useful for creating SQL scripts: · You can record all or parts of a mysql session by using the --tee command-line option or the \T command from within mysql. (See Recipe 1.30 for more information.) · Under Unix, a second option is to use your history file. mysql maintains a record of your queries, which it stores in the file .mysql_history in your home directory. A tee file session log has more context because it contains both query input and output, not just the text of the queries. This additional information can make it easier to locate the parts of the session you want. (Of course, you must also remove the extra stuff to create a batch file from the tee file.) Conversely, the history file is more concise. It contains only of the queries you issue, so there are fewer extraneous lines to delete to obtain the queries you want. Choose whichever source of information best suits your needs. 1.32 Using mysql as a Calculator 1.32.1 Problem You need a quick way to evaluate an expression. 1.32.2 Solution Use mysql as a calculator. MySQL doesn't require every SELECT statement to refer to a table, so you can select the results of arbitrary expressions. 1.32.3 Discussion SELECT statements typically refer to some table or tables from which you're retrieving rows. However, in MySQL, SELECT need not reference any table at all, which means that you can use the mysql program as a calculator for evaluating an expression: mysql> SELECT (17 + 23) / SQRT(64); +----------------------+ | (17 + 23) / SQRT(64) | +----------------------+ | 5.00000000 | +----------------------+ This is also useful for checking how a comparison works. For example, to determine whether or not string comparisons are case sensitive, try the following query: mysql> SELECT 'ABC' = 'abc'; +---------------+ | 'ABC' = 'abc' | +---------------+ | 1 | +---------------+ The result of this comparison is 1 (meaning "true"; in general, nonzero values are true). This tells you that string comparisons are not case sensitive by default. Expressions that evaluate to false return zero: mysql> SELECT 'ABC' = 'abcd'; +----------------+ | 'ABC' = 'abcd' | +----------------+ | 0 | +----------------+ If the value of an expression cannot be determined, the result is NULL: mysql> SELECT 1/0; +------+ | 1/0 | +------+ | NULL | +------+ SQL variables may be used to store the results of intermediate calculations. The following statements use variables this way to compute the total cost of a hotel bill: mysql> SET @daily_room_charge = 100.00; mysql> SET @num_of_nights = 3; mysql> SET @tax_percent = 8; mysql> SET @total_room_charge = @daily_room_charge * @num_of_nights; mysql> SET @tax = (@total_room_charge * @tax_percent) / 100; mysql> SET @total = @total_room_charge + @tax; mysql> SELECT @total; +--------+ | @total | +--------+ | 324 | +--------+ 1.33 Using mysql in Shell Scripts 1.33.1 Problem You want to invoke mysql from within a shell script rather than using it interactively. 1.33.2 Solution There's no rule against that. Just be sure to supply the appropriate arguments to the command. 1.33.3 Discussion If you need to process query results within a program, you'll typically use a MySQL programming interface designed specifically for the language you're using (for example, in a Perl script you'd use the DBI interface). But for simple, short, or quick-and-dirty tasks, it may be easier just to invoke mysql directly from within a shell script, possibly postprocessing the results with other commands. For example, an easy way to write a MySQL server status tester is to use a shell script that invokes mysql, as is demonstrated later in this section. Shell scripts are also useful for prototyping programs that you intend to convert for use with a standard API later. For Unix shell scripting, I recommend that you stick to shells in the Bourne shell family, such as sh, bash, or ksh. (The csh and tcsh shells are more suited to interactive use than to scripting.) This section provides some examples showing how to write Unix scripts for /bin/sh. It also comments briefly on DOS scripting. The sidebar "Using Executable Programs" describes how to make scripts executable and run them. Using Executable Programs When you write a program, you'll generally need to make it executable before you can run it. In Unix, you do this by setting the "execute" file access modes using the chmod command: % chmod +x myprog To run the program, name it on the command line: % myprog However, if the program is in your current directory, your shell might not find it. The shell searches for programs in the directories named in your PATH environment variable, but for security reasons, the search path for Unix shells often is deliberately set not to include the current directory (.). In that case, you need to include a leading path of ./ to explicitly indicate the program's location: % ./myprog Some of the programs developed in this book are intended only to demonstrate a particular concept and probably never will be run outside your current directory, so examples that use them generally show how to invoke them using the leading ./ path. For programs that are intended for repeated use, it's more likely that you'll install them in a directory named in your PATH setting. In that case, no leading path will be necessary to invoke them. This also holds for common Unix utilities (such as chmod), which are installed in standard system directories. Under Windows, programs are interpreted as executable based on their filename extensions (such as .exe or .bat), so chmod is unnecessary. Also, the command interpreter includes the current directory in its search path by default, so you should be able to invoke programs that are located there without specifying any leading path. (Thus, if you're using Windows and you want to run an example command that is shown in this book using ./, you should omit the ./ from the command.) 1.33.4 Writing Shell Scripts Under Unix Here is a shell script that reports the current uptime of the MySQL server. It runs a SHOW STATUS query to get the value of the Uptime status variable that contains the server uptime in seconds: #! /bin/sh # mysql_uptime.sh - report server uptime in seconds mysql -B -N -e "SHOW STATUS LIKE 'Uptime'" The first line of the script that begins with #! is special. It indicates the pathname of the program that should be invoked to execute the rest of the script, /bin/sh in this case. To use the script, create a file named mysql_uptime.sh that contains the preceding lines and make it executable with chmod +x. The mysql_uptime.sh script runs mysql using -e to indicate the query string, -B to generate batch (tab-delimited) output, and -N to suppress the column header line. The resulting output looks like this: % ./mysql_uptime.sh Uptime 1260142 The command shown here begins with ./, indicating that the script is located in your current directory. If you move the script to a directory named in your PATH setting, you can invoke it from anywhere, but then you should omit the ./ from the command. Note that moving the script make cause csh or tcsh not to know where the script is located until your next login. To remedy this without logging in again, use rehash after moving the script. The following example illustrates this process: % ./mysql_uptime.sh Uptime 1260348 % mv mysql_uptime.sh /usr/local/bin % mysql_uptime.sh mysql_uptime.sh: Command not found. % rehash % mysql_uptime.sh Uptime 1260397 If you prefer a report that lists the time in days, hours, minutes, and seconds rather than just seconds, you can use the output from the mysql STATUS statement, which provides the following information: mysql> STATUS; Connection id: 12347 Current database: cookbook Current user: cbuser@localhost Current pager: stdout Using outfile: '' Server version: 3.23.47-log Protocol version: 10 Connection: Localhost via UNIX socket Client characterset: latin1 Server characterset: latin1 UNIX socket: /tmp/mysql.sock Uptime: 14 days 14 hours 2 min 46 sec For uptime reporting, the only relevant part of that information is the line that begins with Uptime. It's a simple matter to write a script that sends a STATUS command to the server and filters the output with grep to extract the desired line: #! /bin/sh # mysql_uptime2.sh - report server uptime mysql -e STATUS | grep "^Uptime" The result looks like this: % ./mysql_uptime2.sh Uptime: 14 days 14 hours 2 min 46 sec The preceding two scripts specify the statement to be executed by means of the -e command- line option, but you can use other mysql input sources described earlier in the chapter, such as files and pipes. For example, the following mysql_uptime3.sh script is like mysql_uptime2.sh but provides input to mysql using a pipe: #! /bin/sh # mysql_uptime3.sh - report server uptime echo STATUS | mysql | grep "^Uptime" Some shells support the concept of a "here-document," which serves essentially the same purpose as file input to a command, except that no explicit filename is involved. (In other words, the document is located "right here" in the script, not stored in an external file.) To provide input to a command using a here-document, use the following syntax: command < mysql_uptime Uptime 9609 DOS scripting has some serious limitations, however. For example, here-documents are not supported, and command argument quoting capabilities are more limited. One way around these problems is to install a more reasonable working environment; see the sidebar "Finding the DOS Prompt Restrictive?" Finding the DOS Prompt Restrictive? If you're a Unix user who is comfortable with the shells and utilities that are part of the Unix command-line interface, you probably take for granted some of the commands used in this chapter, such as grep, sed, tr, and tail. These tools are so commonly available on Unix systems that it can be a rude and painful shock to realize that they are nowhere to be found if at some point you find it necessary to work at the DOS prompt under Windows. One way to make the DOS command-line environment more palatable is to install Cygnus tools for Windows (Cygwin) or Unix for Windows (UWIN). These packages include some of the more popular Unix shells as well as many of the utilities that Unix users have come to expect. Programming tools such as compilers are available with each package as well. The package distributions may be obtained at the following locations: http://www.cygwin.com/ http://www.research.att.com/sw/tools/uwin/ These distributions can change the way you use this book under Windows, because they eliminate some of the exceptions where I qualify commands as available under Unix but not Windows. By installing Cygwin or UWIN, many of those distinctions become irrelevant. Chapter 2. Writing MySQL-Based Programs Section 2.1. Introduction Section 2.2. Connecting to the MySQL Server, Selecting a Database, and Disconnecting Section 2.3. Checking for Errors Section 2.4. Writing Library Files Section 2.5. Issuing Queries and Retrieving Results Section 2.6. Moving Around Within a Result Set Section 2.7. Using Prepared Statements and Placeholders in Queries Section 2.8. Including Special Characters and NULL Values in Queries Section 2.9. Handling NULL Values in Result Sets Section 2.10. Writing an Object-Oriented MySQL Interface for PHP Section 2.11. Ways of Obtaining Connection Parameters Section 2.12. Conclusion and Words of Advice 2.1 Introduction This chapter discusses how to write programs that use MySQL. It covers basic API operations that are fundamental to your understanding of the recipes in later chapters, such as connecting to the MySQL server, issuing queries, and retrieving the results. 2.1.1 MySQL Client Application Programming Interfaces This book shows how to write MySQL-based programs using Perl, PHP, Python, and Java, and it's possible to use several other languages as well. But one thing all MySQL clients have in common, no matter which language you use, is that they connect to the server using some kind of application programming interface (API) that implements a communications protocol. This is true regardless of the program's purpose, whether it's a command-line utility, a job that runs automatically on a predetermined schedule, or a script that's used from a web server to make database content available over the Web. MySQL APIs provide a standard way for you, the application developer, to express database operations. Each API translates your instructions into something the MySQL server can understand. The server itself speaks a low-level protocol that I call the raw protocol. This is the level at which direct communication takes place over the network between the server and its clients. A client establishes a connection to the port on which the server is listening and communicates with it by speaking the client-server protocol in its most basic terms. (Basically, the client fills in data structures and shoves them over the network.) It's not productive to attempt to communicate directly with the server at this level (see the sidebar Want to Telnet to the MySQL Server?"), nor to write programs that do so. The raw protocol is a binary communication stream that is efficient, but not particularly easy to use, a fact that usually deters developers from attempting to write programs that talk to the server this way. More convenient access to the MySQL server is provided through a programming interface that is written at a level above that of the raw protocol level. The interface handles the details of the raw protocol on behalf of your programs. It provides calls for operations such as connecting to the server, sending queries, retrieving the results of queries, and obtaining query status information. Java drivers implement this low-level protocol directly. They plug into the Java Database Connectivity (JDBC) interface, so you write your programs using standard JDBC calls. JDBC passes your requests for database operations to the MySQL driver, which maps them into operations that communicate with the MySQL server using the raw protocol. The MySQL drivers for Perl, PHP, and Python adopt a different approach. They do not implement the raw protocol directly. Instead, they rely on the MySQL client library that is included with MySQL distributions. This client library is written in C and thus provides the basis of an application programming interface for communicating with the server from within C programs. Most of the standard clients in the MySQL distribution are written in C and use this API. You can use it in your own programs, too, and should consider doing so if you want the most efficient programs possible. However, most third-party application development is not done in C. Instead, the C API is most often used indirectly as an embedded library within other languages. This is how MySQL communication is implemented for Perl, PHP, Python, and several other languages. The API for these higher-level languages is written as a "wrapper" around the C routines, which are linked into the language processor. The benefit of this approach is that it allows a language processor to talk to the MySQL server on your behalf using the C routines while providing to you an interface in which you express database operations more conveniently. For example, scripting languages such as Perl typically make it easy to manipulate text without having to allocate string buffers or dispose of them when you're done with them the way you do in C. Higher-level languages let you concentrate more on what you're trying to do and less on the details that you must think about when you're writing directly in C. This book doesn't cover the C API in any detail, because we never use it directly; the programs developed in this book use higher-level interfaces that are built on top of the C API. However, if you'd like to try writing MySQL client programs in C, the following sources of information may be helpful: · The MySQL Reference Manual contains a chapter that provides a reference for the C API functions. You should also have a look at the source for the standard MySQL clients provided with the MySQL source distribution that are written in C. Source distributions and the manual both are available at the MySQL web site, http://www.mysql.com/, and you can obtain the manual in printed form from O'Reilly & Associates. · The book MySQL (New Riders) contains reference material for the C API, and also includes a chapter that provides detailed tutorial instructions for writing MySQL programs in C. In fact, you needn't even buy the book to get this particular chapter; it's available in PDF form at http://www.kitebird.com/mysql-book/. The source code for the sample programs discussed in the chapter is available from the same site for you to study and use. These programs were deliberately written for instructional purposes, so you may find them easier to understand than the standard clients in the MySQL source distribution. Want to Telnet to the MySQL Server? Some networking protocols such as SMTP and POP are ASCII based. This makes it possible to talk directly to a server for those protocols by using Telnet to connect to the port on which the server is listening and typing in commands from the keyboard. Because of this, people sometimes assume that it should also be possible to communicate with the MySQL server the same way: by opening a Telnet connection to it and entering commands. That doesn't work, due to the binary nature of the raw protocol that the server uses. You can verify this for yourself. Suppose the MySQL server is running on the local host and listening on the default port (3306). Connect to it using the following command: % telnet localhost 3306 You'll see something that looks like a version number, probably accompanied by a bunch of gibberish characters. What you're seeing is the raw protocol. You can't get very far by communicating with the server in this fashion, which is why the answer to the common question, "How can I Telnet to the MySQL server?" is, "Don't bother." The only thing you can find out this way is whether or not the server is up and listening for connections on the port. MySQL client APIs provide the following capabilities, each of which is covered in this chapter: · Connecting to the MySQL server; selecting a database; disconnecting from the server. Every program that uses MySQL must first establish a connection to the server, and most programs also will specify which database to use. Some APIs expect the database name to be supplied at connect time (which is why connecting and selecting are covered in the same section). Others provide an explicit call for selecting the database. In addition, well-behaved MySQL programs close the connection to the server when they're done with it. · Checking for errors. Many people write MySQL programs that perform no error checking at all, which makes them difficult to debug when things go wrong. Any database operation can fail and you should know how to find out when that occurs and why. This is necessary so that you can take appropriate action such as terminating the program or informing the user of the problem. · Issuing queries and retrieving results. The whole point of connecting to a database server is to run queries. Each API provides at least one way to issue queries, as well as several functions for processing the results of queries. Because of the many options available to you, this section is easily the most extensive of the chapter. · Using prepared statements and placeholders in queries. One way to write a query that refers to specific data values is to embed the values directly in the query string. Most APIs provide another mechanism that allows you to prepare a query in advance that refers to the data values symbolically. When you execute the statement, you supply the data values separately and the API places them into the query string for you. · Including special characters and NULL values in queries. Some characters such as quotes and backslashes have special meaning in queries, and you must take certain precautions when constructing queries containing them. The same is true for NULL values. If you do not handle these properly, your programs may generate SQL statements that are erroneous or that yield unexpected results. This section discusses how to avoid these problems. · Handling NULL values in result sets. NULL values are special not only when you construct queries, but in results returned from queries. Each API provides a convention for dealing with them. To write your own programs, it's necessary to know how to perform each of the fundamental database API operations no matter which language you use, so each one is shown in each of our languages (PHP, Perl, Python, and Java). Seeing how each API handles a given operation should help you see the correspondences between APIs more easily and facilitate understanding of recipes shown in the following chapters, even if they're written in a language you don't use very much. (Later chapters usually illustrate recipe implementations using just one or two languages.) I recognize that it may seem overwhelming to see each recipe in four different languages if you're interested only in one particular API. In that case, I advise you to approach the recipes as follows: read just the introductory part that provides the general background, then go directly to the section for the language in which you're interested. Skip the other languages. Should you develop an interest in writing programs in other languages later, you can always come back and read the other sections then. This chapter also discusses the following topics, which are not directly part of MySQL APIs but can help you use them more easily: · Writing library files. As you write program after program, you may find that there are certain operations you carry out repeatedly. Library files provide a way to encapsulate the code for these operations so that you can perform them from multiple scripts without including all the code in each script. This reduces code duplication and makes your programs more portable. This section shows how to write a library file for each API that includes a function for connecting to the server—one operation that every program that uses MySQL must perform. (Later chapters develop additional library routines for other operations.) · Writing an object-oriented MySQL interface for PHP. The APIs for Perl, Python, and Java each are class-based and provide an object- oriented programming model based on a database-independent architecture. PHP's built-in interface is based on MySQL-specific function calls. The section describes how to write a PHP class that can be used to take an object-oriented approach to developing MySQL scripts. · Ways of obtaining connection parameters. The earlier section on establishing connections to the MySQL server relies on connection parameters hardwired into the code. However, there are several other ways to obtain parameters, ranging from storing them in a separate file to allowing the user to specify them at runtime. To avoid typing in the example programs, you should obtain the recipes source distribution (see Appendix A). Then when an example says something like "create a file named xyz that contains the following information . . . " you can just use the corresponding file from the recipes distribution. The scripts for this chapter are located under the api directory, with the exception of the library files, which can be found in the lib directory. The primary table used for examples in this chapter is named profile. It's created in Recipe 2.5, which you should know in case you skip around in the chapter and wonder where it came from. See also the note at the very end of the chapter about resetting the profile table to a known state for use in other chapters. 2.1.2 Assumptions Several assumptions should be satisfied for the material in this chapter to be used most effectively: · You should have MySQL support installed for any language processors you plan to use. If you need to install any of the APIs, see Appendix A. · You should already have set up a MySQL user account for accessing the server and a database to use for trying out queries. As described in Chapter 1, the examples use a MySQL account with a name and password of cbuser and cbpass, and we'll connect to a MySQL server running on the local host to access a database named cookbook. If you need to create the account or the database, see the instructions in that chapter. · The recipes assume a certain basic understanding of the API languages. If a recipe uses constructs with which you're not familiar, consult a good general text for the language in which you're interested. Appendix C lists some sources that may be helpful. · Proper execution of some of the programs may require that you set environment variables that control their behavior. See Recipe 1.9 for details about how to do this. 2.2 Connecting to the MySQL Server, Selecting a Database, and Disconnecting 2.2.1 Problem You need to establish a connection to the server to access a database, and to shut down the connection when you're done. 2.2.2 Solution Each API provides functions for connecting and disconnecting. The connection routines require that you provide parameters specifying the MySQL user account you want to use. You can also specify a database to use. Some APIs allow this at connection time; others require a separate call after connecting. 2.2.3 Discussion The programs in this section show how to perform three fundamental operations that are common to the vast majority of MySQL programs: · Establishing a connection to the MySQL server. Every program that uses MySQL does this, no matter which API you use. The details on specifying connection parameters vary between APIs, and some APIs provide more flexibility than others. However, there are many common elements. For example, you must specify the host where the server is running, as well as the name and password for the MySQL account that you're using to access the server. · Selecting a database. Most MySQL programs select a database, either when they connect to the server or immediately thereafter. · Disconnecting from the server Each API provides a means of shutting down an open connection. It's best to close the connection as soon as you're done with the server so that it can free up any resources that are allocated to servicing the connection. Otherwise, if your program performs additional computations after accessing the server, the connection will be held open longer than necessary. It's also preferable to close the connection explicitly. If a program simply terminates without closing the connection, the MySQL server eventually notices, but shutting down the connection explicitly allows the server to perform an orderly close on its end immediately. Our example programs for each API in this section show how to connect to the server, select the cookbook database, and disconnect. However, on occasion you might want to write a MySQL program that doesn't select a database. This would be the case if you plan to issue a query that doesn't require a default database, such as SHOW VARIABLES or SHOW DATABASES. Or perhaps you're writing an interactive program that connects to the server and allows the user to specify the database after the connection has been made. To cover such situations, the discussion for each API also indicates how to connect without selecting any database. The Meaning of localhost in MySQL One of the parameters you specify when connecting to a MySQL server is the host where the server is running. Most programs treat the hostname localhost and the IP address 127.0.0.1 as synonymous. Under Unix, MySQL programs behave differently; by convention, they treat the hostname localhost specially and attempt to connect to the server using a Unix domain socket file. To force a TCP/IP connection to the local host, use the IP address 127.0.0.1 rather than the hostname localhost. (Under Windows, localhost and 127.0.0.1 are treated the same, because Windows doesn't have Unix domain sockets.) The default port is 3306 for TCP/IP connections. The pathname for the Unix domain socket varies, although it's often /tmp/mysql.sock. The recipes indicate how to specify the socket file pathname or TCP/IP port number explicitly if you don't want to use the default. 2.2.4 Perl To write MySQL scripts in Perl, you should have the DBI module installed, as well as the MySQL-specific DBI driver module, DBD::mysql. Appendix A contains information on getting these if they're not already installed. There is an older interface for Perl named MysqlPerl, but it's obsolete and is not covered here. Here is a simple Perl script that connects to the cookbook database, then disconnects: #! /usr/bin/perl -w # connect.pl - connect to the MySQL server use strict; use DBI; my $dsn = "DBI:mysql:host=localhost;database=cookbook"; my $dbh = DBI->connect ($dsn, "cbuser", "cbpass") or die "Cannot connect to server\n"; print "Connected\n"; $dbh->disconnect ( ); print "Disconnected\n"; exit (0); To try the script, create a file named connect.pl that contains the preceding code. To run connect.pl under Unix, you may need to change the pathname on the first line if your Perl program is located somewhere other than /usr/bin/perl. Then make the script executable with chmod +x, and invoke it as follows: % chmod +x connect.pl % ./connect.pl Connected Disconnected Under Windows, chmod will not be necessary; you run connect.pl like this: C:\> perl connect.pl Connected Disconnected If you have a filename association set up that allows .pl files to be executed directly from the command line, you need not invoke Perl explicitly: C:\> connect.pl Connected Disconnected For more information on running programs that you've written yourself, see the sidebar "Using Executable Programs" in Recipe 1.33. The -w option turns on warning mode so that Perl produces warnings for any questionable constructs. Our example script has no such constructs, but it's a good idea to get in the habit of using -w; as you modify your scripts during the development process, you'll often find that Perl has useful comments to make about them. The use strict line turns on strict variable checking and causes Perl to complain about any variables that are used without having been declared first. This is a sensible precaution because it helps find errors that might otherwise go undetected. The use DBI statement tells Perl that the program needs to use the DBI module. It's unnecessary to load the MySQL driver module (DBD::mysql) explicitly, because DBI will do that itself when the script connects to the database server. The next two lines establish the connection to MySQL by setting up a data source name (DSN) and calling the DBI connect( ) method. The arguments to connect( ) are the DSN, the MySQL username, the password, and any connection attributes you want to specify. The DSN is required. The other arguments are optional, although usually it's necessary to supply a name and password to get very far. The DSN specifies which database driver to use and other options indicating where to connect. For MySQL programs, the DSN has the format DBI:mysql:options. The three components of which have the following meanings: · The first component is always DBI. It's not case sensitive; dbi or Dbi would do just as well. · The second component tells DBI which database driver to use. For MySQL, the name must be mysql and it is case sensitive. You can't use MySQL, MYSQL, or any other variation. · The third component, if present, is a semicolon-separated list of name=value pairs specifying additional connection options. The order of any options you provide doesn't matter. For our purposes here, the two most relevant options are host and database. They specify the hostname where the MySQL server is running and the database you want to use. Note that the second colon in the DSN is not optional, even if you don't specify any options. Given this information, the DSN for connecting to the cookbook database on the local host localhost looks like this: DBI:mysql:host=localhost;database=cookbook If you leave out the host option, its default value is localhost. Thus, these two DSNs are equivalent: DBI:mysql:host=localhost;database=cookbook DBI:mysql:database=cookbook If you omit the database option, no database is selected when you connect. The second and third arguments of the connect( ) call are your MySQL username and password. You can also provide a fourth argument following the password to specify attributes that control DBI's behavior when errors occur. By default, DBI prints error messages when errors occur but does not terminate your script. That's why connect.pl checks whether connect( ) returns undef to indicate failure: my $dbh = DBI->connect ($dsn, "cbuser", "cbpass") or die "Cannot connect to server\n"; Other error-handling strategies are possible. For example, you can tell DBI to terminate the script automatically when an error occurs in a DBI call by disabling the PrintError attribute and enabling RaiseError instead. Then you don't have to check for errors yourself: my $dbh = DBI->connect ($dsn, $user_name, $password, {PrintError => 0, RaiseError => 1}); Error handling is discussed further in Recipe 2.3. Assuming that connect( ) succeeds, it returns a database handle that contains information about the state of the connection. (In DBI parlance, references to objects are called "handles.") Later we'll see other handles, such as statement handles that are associated with particular queries. DBI scripts in this book conventionally use $dbh and $sth to signify database and statement handles. 2.2.4.1 Additional connection parameters For connections to localhost, you can provide a mysql_socket option in the DSN to specify the path to the Unix domain socket: my $dsn = "DBI:mysql:host=localhost;mysql_socket=/var/tmp/mysql.sock" . ";database=cookbook"; The mysql_socket option is available as of MySQL 3.21.15. For non-localhost connections, you can provide a port option to specify the port number: my $dsn = "DBI:mysql:host=mysql.snake.net;port=3307;database=cookbook"; 2.2.5 PHP To write PHP scripts that use MySQL, your PHP interpreter must have MySQL support compiled in. If it doesn't, your scripts will terminate with an error message like this: Fatal error: Call to undefined function: mysql_connect( ) Should that occur, check the instructions included with your PHP distribution to see how to enable MySQL support. PHP scripts usually are written for use with a web server. I'll assume that if you're going to use PHP that way here, you can simply drop PHP scripts into your server's document tree, request them from your browser, and they will execute. For example, if you run Apache as the web server on the host http://apache.snake.net/ and you install a PHP script myscript.php at the top level of the Apache document tree, you should be able to access the script by requesting this URL: http://apache.snake.net/myscript.php This book uses the .php extension (suffix) for PHP script filenames. If you use a different extension, such as .php3 or .phtml, you'll need to change the script names or else reconfigure your web server to recognize the .php extension. Otherwise, when you request a PHP script from your browser, the literal text of the script will appear in your browser window. You don't want this to happen, particularly if the script contains the username and password you use for connecting to MySQL. (For additional information about configuring Apache for use with PHP, see Recipe 16.3.) PHP scripts often are written as a mixture of HTML and PHP code, with the PHP code embedded between the special tags. Here is a simple example: A simple page

For brevity, when I show PHP examples consisting entirely of code, typically I'll omit the enclosing tags. Examples that switch between HTML and PHP code include the tags. To use MySQL in a PHP script, you connect to the MySQL server and select a database in two steps, by calling the mysql_connect( ) and mysql_select_db( ) functions. Our first PHP script, connect.php, shows how this works: # connect.php - connect to the MySQL server if (!($conn_id = @mysql_connect ("localhost", "cbuser", "cbpass"))) die ("Cannot connect to server\n"); print ("Connected\n"); if (!@mysql_select_db ("cookbook", $conn_id)) die ("Cannot select database\n"); mysql_close ($conn_id); print ("Disconnected\n"); mysql_connect( ) takes three arguments: the host where the MySQL server is running, and the name and password of the MySQL account you want to use. If the connection attempt succeeds, mysql_connect( ) returns a connection identifier that can be passed to other MySQL-related functions later. PHP scripts in this book conventionally use $conn_id to signify connection identifiers. If the connection attempt fails, mysql_connect( ) prints a warning and returns FALSE. (The script prevents any such warning by putting @ (the warning-suppression operator) in front of the function name so it can print its own message instead.) mysql_select_db( ) takes the database name and an optional connection identifier as arguments. If you omit the second argument, the function assumes it should use the current connection (that is, the one most recently opened). The script just shown calls mysql_select_db( ) immediately after it connects, so the following calls are equivalent: if (!@mysql_select_db ("cookbook", $conn_id)) die ("Cannot select database\n"); if (!@mysql_select_db ("cookbook")) die ("Cannot select database\n"); If mysql_select_db( ) selects the database successfully, it returns TRUE. Otherwise, it prints a warning and returns FALSE. (Again, as with the mysql_connect( ) call, the script uses the @ operator to suppress the warning.) If you don't want to select any database, just omit the call to mysql_select_db( ). To try the connect.php script, copy it to your web server's document tree and request it from your browser. Alternatively, if you have a standalone version of the PHP interpreter that can be run from the command line, you can try the script without a web server or browser: % php -q connect.php Connected Disconnected PHP actually provides two functions for connecting to the MySQL server. The script connect.php uses mysql_connect( ), but you can use mysql_pconnect( ) instead if you want to establish a persistent connection that doesn't close when the script terminates. This allows the connection to be reused by subsequent PHP scripts run by the web server, thus avoiding the overhead of setting up a new connection. However, MySQL is so efficient at opening connections that you might not notice much difference between the two functions. Also, you should consider that use of mysql_pconnect( ) sometimes results in too many connections being left open. A symptom of this is that the MySQL server stops accepting new connections because so many persistent connections have been opened by web server processes. Using mysql_connect( ) rather than mysql_pconnect( ) may help to avoid this problem. 2.2.5.1 Additional connection parameters For connections to localhost, you can specify a pathname for the Unix domain socket by adding :/path/to/socket to the hostname in the connect call: $hostname = "localhost:/var/tmp/mysql.sock"; if (!($conn_id = @mysql_connect ($hostname, "cbuser", "cbpass"))) die ("Cannot connect to server\n"); For non-localhost, connections, you can specify a port number by adding :port_num to the hostname: $hostname = "mysql.snake.net:3307"; if (!($conn_id = @mysql_connect ($hostname, "cbuser", "cbpass"))) die ("Cannot connect to server\n"); The socket pathname option is available as of PHP 3.0.B4. The port number option is available as of PHP 3.0.10. In PHP 4, you can use the PHP initialization file to specify a default hostname, username, password, socket path, or port number by setting the values of the mysql.default_host, mysql.default_user, mysql.default_password, mysql.default_socket, or mysql.default_port configuration directives. 2.2.6 Python To write MySQL programs in Python, you need the MySQLdb module that provides MySQL connectivity for Python's DB-API interface. If you don't have this module, see Appendix A for instructions. DB-API, like Perl's DBI module, provides a relatively database-independent way to access database servers, and supplants earlier Python DBMS-access modules that each had their own interfaces and calling conventions. This book doesn't cover the older, obsolete MySQL Python interface. Python avoids the use of functions that return a special value to indicate the occurrence of an error. In other words, you typically don't write code like this: if (func1 ( ) == some_bad_value or func2 () == another_bad_value): print "An error occurred" else: print "No error occurred" Instead, put the statements you want to execute in a try block. Errors cause exceptions to be raised that you can catch with an except block containing the error handling code: try: func1 ( ) func2 ( ) except: print "An error occurred" Exceptions that occur at the top level of a script (that is, outside of any try block) are caught by the default exception handler, which prints a stack trace and exits. To use the DB-API interface, import the database driver module you want to use (which is MySQLdb for MySQL programs). Then create a database connection object by calling the driver's connect( ) method. This object provides access to other DB-API methods, such as the close( ) method that severs the connection to the database server. Here is a short Python program, connect.py, that illustrates these operations: #! /usr/bin/python # connect.py - connect to the MySQL server import sys import MySQLdb try: conn = MySQLdb.connect (db = "cookbook", host = "localhost", user = "cbuser", passwd = "cbpass") print "Connected" except: print "Cannot connect to server" sys.exit (1) conn.close ( ) print "Disconnected" sys.exit (0) The import lines give the script access to the sys module (needed for the sys.exit( ) function) and to the MySQLdb module. Then the script attempts to establish a connection to the MySQL server by calling connect( ) to obtain a connection object, conn. Python scripts in this book conventionally use conn to signify connection objects. If the connection cannot be established, an exception occurs and the script prints an error message. Otherwise, it closes the connection by using the close( ) method. Because the arguments to connect( ) are named, their order does not matter. If you omit the host argument from the connect( ) call, its default value is localhost. If you leave out the db argument or pass a db value of "" (the empty string), no database is selected. If you pass a value of None, however, the call will fail. To try the script, create a file called connect.py containing the code just shown. Under Unix, you may need to change the path to Python on the first line of the script if your Python interpreter is located somewhere other than /usr/bin/python. Then make the script executable with chmod +x and run it: % chmod +x connect.py % ./connect.py Connected Disconnected Under Windows, run the script like this: C:\> python connect.py Connected Disconnected If you have a filename association set up that allows .py files to be executed directly from the command line, you need not invoke Python explicitly: C:\> connect.py Connected Disconnected 2.2.6.1 Additional connection parameters For connections to localhost, you can provide a unix_socket parameter to specify the path to the Unix domain socket: conn = MySQLdb.connect (db = "cookbook", host = "localhost", unix_sock = "/var/tmp/mysql.sock", user = "cbuser", passwd = "cbpass") For non-localhost connections, you can provide a port parameter to specify the port number: conn = MySQLdb.connect (db = "cookbook", host = "mysql.snake.net", port = 3307, user = "cbuser", passwd = "cbpass") 2.2.7 Java Database programs in Java are written using the JDBC interface, in conjunction with a driver for the particular database engine you wish to access. This makes the JDBC architecture similar to that used by the Perl DBI and Python DB-API modules: a generic interface used in conjunction with database-specific drivers. Java itself is similar to Python in that you don't test specific function calls for return values that indicate an error. Instead, you provide handlers that are called when exceptions are thrown. Java programming requires a software development kit (SDK). See the sidebar, Installing a Java SDK for instructions on installing one if you need it. To write MySQL-based Java programs, you'll also need a MySQL-specific JDBC driver. Several are listed in Appendix A. I use the MySQL Connector/J driver because it is free and is actively maintained; use one of the other drivers if you prefer. (MySQL Connector/J is the successor to MM.MySQL, and if you already have MM.MySQL installed, you can use it instead by making a simple change: whenever you see org.gjt.mm.mysql in Java code, replace it with com.mysql.jdbc.) Installing a Java SDK java.sun.com makes Java SDKs available for Solaris, Linux, and Windows, but you may already have the necessary tools installed, or they may be available by another means. For example, Mac OS X includes javac, jikes, and other support needed for building Java applications in the Developer Tools distribution available at connect.apple.com. If a Java SDK is not already installed on your system, get one from java.sun.com, install it, and set the JAVA_HOME environment variable to the pathname where the SDK is installed. Examples shown here assume an SDK installation directory of /usr/local/java/jdk for Unix and D:\jdk for Windows, so the commands for setting JAVA_HOME look like this: export JAVA_HOME=/usr/local/java/jdk (sh, bash, etc.) setenv JAVA_HOME=/usr/local/java/jdk (csh, tcsh, etc.) set JAVA_HOME=D:\jdk (Windows) Adjust the instructions appropriately for the pathname used on your system. To make environment variable changes take effect, log out and log in again under Unix, or restart under Windows. For more information on setting environment variables, see Recipe 1.9. The following Java program, Connect.java, illustrates how to connect to and disconnect from the MySQL server: // Connect.java - connect to the MySQL server import java.sql.*; public class Connect { public static void main (String[ ] args) { Connection conn = null; String url = "jdbc:mysql://localhost/cookbook"; String userName = "cbuser"; String password = "cbpass"; try { Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); conn = DriverManager.getConnection (url, userName, password); System.out.println ("Connected"); } catch (Exception e) { System.err.println ("Cannot connect to server"); } finally { if (conn != null) { try { conn.close ( ); System.out.println ("Disconnected"); } catch (Exception e) { /* ignore close errors */ } } } } } The import java.sql.* statement references the classes and interfaces that provide access to the data types you use to manage different aspects of your interaction with the database server. These are required for all JDBC programs. Connecting to the server is a two-step process. First, register the database driver with JDBC by calling Class.forName( ). Then call DriverManager.getConnection( ) to initiate the connection and obtain a Connection object that maintains information about the state of the connection. Java programs in this book conventionally use conn to signify connection objects. Use com.mysql.jdbc.Driver for the name of the MySQL Connector/J JDBC driver. If you use a different driver, check its documentation and use the name specified there. DriverManager.getConnection( ) takes three arguments: a URL describing where to connect and the database to use, the MySQL username, and the password. The format of the URL string is as follows: jdbc:driver://host_name/db_name This format follows the usual Java convention that the URL for connecting to a network resource begins with a protocol designator. For JDBC programs, the protocol is jdbc, and you'll also need a subprotocol designator that specifies the driver name (mysql, for MySQL programs). Many parts of the connection URL are optional, but the leading protocol and subprotocol designators are not. If you omit host_name, the default host value is localhost. If you omit the database name, no database is selected when you connect. However, you should not omit any of the slashes in any case. For example, to connect to the local host without selecting a database name, the URL is: jdbc:mysql:/// To try out the program, you should compile it and execute it. The class statement indicates the program's name, which in this case is Connect. The name of the file containing the program should match this name and include a .java extension, so the filename for the example program is Connect.java.[1] Compile the program using javac: [1] If you make a copy of Connect.java to use as the basis for a new program, you'll need to change the class name in the class statement to match the name of your new file. % javac Connect.java If you prefer a different Java compiler, just substitute its name in compilation commands. For example, if you'd rather use Jikes, compile the file like this instead: % jikes Connect.java javac (or jikes, or whatever) generates compiled byte code to produce a class file named Connect.class. Use the java program to run the class file (note that you specify the name of the class file without the .class extension): % java Connect Connected Disconnected You may need to set your CLASSPATH environment variable before the example program will compile and run. The value of CLASSPATH should include at least your current directory (.) and the path to the MySQL Connector/J JDBC driver. On my system, that driver is located in /usr/local/lib/java/lib/mysql-connector-java-bin.jar, so for tcsh or csh, I'd set CLASSPATH like this: setenv CLASSPATH .:/usr/local/lib/java/lib/mysql-connector-java-bin.jar For shells such as sh, bash, and ksh, I'd set it like this: export CLASSPATH=.:/usr/local/lib/java/lib/mysql-connector-java-bin.jar Under Windows, I'd set CLASSPATH as follows if the driver is in the D:\Java\lib directory: CLASSPATH=.;D:\Java\lib\mysql-connector-java-bin.jar You may also need to add other class directories or libraries to your CLASSPATH setting; the specifics depend on how your system is set up. Beware of Class.forName( )! The example program Connect.java registers the JDBC driver like this: Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); You're supposed to be able to register drivers without invoking newInstance( ), like so: Class.forName ("com.mysql.jdbc.Driver"); However, that call doesn't work for some Java implementations, so be sure not to omit newInstance( ), or you may find yourself enacting the Java motto, "write once, debug everywhere." Some JDBC drivers (MySQL Connector/J among them) allow you to specify the username and password as parameters at the end of the URL. In this case, you omit the second and third arguments of the getConnection( ) call. Using that URL style, the code that establishes the connection in the example program could have been written like this: // connect using username and password included in URL Connection conn = null; String url = "jdbc:mysql://localhost/cookbook?user=cbuser&password=cbpass"; try { Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); conn = DriverManager.getConnection (url); System.out.println ("Connected"); } The character that separates the user and password parameters should be &, not ;. 2.2.7.1 Additional connection parameters For non-localhost connections, specify an explicit port number by adding :port_num to the hostname in the connection URL: String url = "jdbc:mysql://mysql.snake.net:3307/cookbook"; For connections to localhost, there is no option for specifying the Unix domain socket pathname, at least not for MySQL Connector/J. Other MySQL JDBC drivers may allow for this; check their documentation. 2.3 Checking for Errors 2.3.1 Problem Something went wrong with your program and you don't know what. 2.3.2 Solution Everybody has problems getting programs to work correctly. But if you don't anticipate difficulties by checking for errors, you make the job a lot harder. Add some error-checking code so your programs can help you figure out what went wrong. 2.3.3 Discussion You now know how to connect to the MySQL server. It's also a good idea to know how to check for errors and how to retrieve MySQL-related error information from the API, so that's what we'll cover next. When errors occur, MySQL provides a numeric error code and a corresponding descriptive text error message. The recipes in this section show how to access this information. You're probably anxious to see how to do more interesting things (such as issue queries and get back the results), but error checking is fundamentally important. Programs sometimes fail, especially during development, and if you don't know how to determine why failures occur, you'll be flying blind. The example programs in this section show how to check for errors, but will in fact execute without any problems if your MySQL account is set up properly. Thus, you may have to modify the examples slightly to force errors to occur so that the error-handling statements are triggered. For example, you can change a connection-establishment call to supply a bad password. This will give you a feel for how the code acts when errors do occur. A general debugging aid that is not specific to any API is to check the MySQL query log to see what queries the server actually is receiving. (This requires that you have query logging turned on and that you have access to the log on the MySQL server host.) The log often will show you that a query is malformed in a particular way and give you a clue about why your program is not constructing the proper query string. If you're running a script under a web server and it fails, check the server's error log. 2.3.4 Perl The DBI module provides two attributes that control what happens when DBI method invocations fail: · PrintError, if enabled, causes DBI to print an error message using warn( ). · RaiseError, if enabled, causes DBI to print an error message using die( ); this terminates your script. By default, PrintError is enabled and RaiseError is disabled, so a script continues executing after printing a message if errors occur. Either or both attributes can be specified in the connect( ) call. Setting an attribute to 1 or 0 enables or disables it, respectively. To specify either or both attributes, pass them in a hash reference as the fourth argument to the connect( ) call. (The syntax is demonstrated shortly.) The following code uses the default settings for the error-handling attributes. This results in a warning message if the connect( ) call fails, but the script will continue executing: my $dbh = DBI->connect ($dsn, "cbuser", "cbpass"); However, because you really can't do much if the connection attempt fails, it's often prudent to exit instead after DBI prints a message: my $dbh = DBI->connect ($dsn, "cbuser", "cbpass") or exit; To print your own error messages, leave RaiseError disabled and disable PrintError as well. Then test the results of DBI method calls yourself. When a method fails, the $DBI::err and $DBI::errstr variables will contain the MySQL numeric error code and descriptive error string, respectively: my $dbh = DBI->connect ($dsn, "cbuser", "cbpass", {PrintError => 0}) or die "Connection error: $DBI::errstr ($DBI::err)\n"; If no error occurs, $DBI::err will be 0 or undef, and $DBI::errstr will be the empty string or undef. When checking for errors, you should access these variables immediately after invoking the DBI method that sets them. If you invoke another method before using them, their values will be reset. The default settings (PrintError enabled, RaiseError disabled) are not so useful if you're printing your own messages. In this case, DBI prints a message automatically, then your script prints its own message. This is at best redundant, and at worst confusing to the person using the script. If you enable RaiseError, you can call DBI methods without checking for return values that indicate errors. If a method fails, DBI prints an error and terminates your script. If the method returns, you can assume it succeeded. This is the easiest approach for script writers: let DBI do all the error checking! However, if PrintError and RaiseError both are enabled, DBI may call warn( ) and die( ) in succession, resulting in error messages being printed twice. To avoid this problem, it's best to disable PrintError whenever you enable RaiseError. That's the approach generally used in this book, as illustrated here: my $dbh = DBI->connect ($dsn, "cbuser", "cbpass", {PrintError => 0, RaiseError => 1}); If you don't want the all-or-nothing behavior of enabling RaiseError for automatic error checking versus having to do all your own checking, you can adopt a mixed approach. Individual handles have PrintError and RaiseError attributes that can be enabled or disabled selectively. For example, you can enable RaiseError globally by turning it on when you call connect( ), then disable it selectively on a per-handle basis. Suppose you have a script that reads the username and password from the command-line arguments, then loops while the user enters queries to be executed. In this case you'd probably want DBI to die and print the error message automatically if the connection fails (there's not much you can do if the user doesn't provide a valid name and password). After connecting, on the other hand, you wouldn't want the script to exit just because the user enters a syntactically invalid query. It would be better for the script to trap the error, print a message, then loop to get the next query. The following code shows how this can be done (the do( ) method used in the example executes a query and returns undef to indicate an error): my $user_name = shift (@ARGV); my $password = shift (@ARGV); my $dbh = DBI->connect ($dsn, $user_name, $password, {PrintError => 0, RaiseError => 1}); $dbh->{RaiseError} = 0; # disable automatic termination on error print "Enter queries to be executed, one per line; terminate with Control- D\n"; while (<>) # read and execute queries { $dbh->do ($_) or warn "Query failed: $DBI::errstr ($DBI::err)\en"; } $dbh->{RaiseError} = 1; # re-enable automatic termination on error If RaiseError is enabled, you can trap errors without terminating your program by executing code within an eval block. If an error occurs within the block, eval fails and returns a message in the $@ variable. Typically, eval is used something like this: eval { # statements that might fail go here... }; if ($@) { print "An error occurred: $@\n"; } This technique is commonly used, for example, to implement transactions. (See Chapter 15.) Using RaiseError in combination with eval differs from using RaiseError alone in the following ways: · Errors terminate only the eval block, not the entire script. · Any error terminates the eval block, whereas RaiseError applies only to DBI- related errors. When you use eval with RaiseError enabled, be sure to disable PrintError. Otherwise, in some versions of DBI, an error may simply cause warn( ) to be called without terminating the eval block as you expect. In addition to using the error-handling attributes PrintError and RaiseError, you can get lots of useful information about your script's execution by turning on DBI's tracing mechanism. Invoke the trace( ) method with an argument indicating the trace level. Levels 1 to 9 enable tracing with increasingly more verbose output, and level 0 disables tracing: DBI->trace (1); # enable tracing, minimal output DBI->trace (3); # elevate trace level DBI->trace (0); # disable tracing Individual database and statement handles have trace( ) methods, too. That means you can localize tracing to a single handle if you want. Trace output normally goes to your terminal (or, in the case of a web script, to the web server's error log). You can write trace output to a specific file by providing a second argument indicating a filename: DBI->trace (1, "/tmp/trace.out"); If the trace file already exists, trace output is appended to the end; the file's contents are not cleared first. Beware of turning on a file trace while developing a script, then forgetting to disable the trace when you put the script into production. You'll eventually find to your chagrin that the trace file has become quite large. (Or worse, a filesystem will fill up and you'll have no idea why!) 2.3.5 PHP In PHP, most functions that can succeed or fail indicate what happened by means of their return value. You can check that value and take action accordingly. Some functions also print a warning message when they fail. (mysql_connect( ) and mysql_select_db( ) both do this, for example.) Automatic printing of warnings can be useful sometimes, but if the purpose of your script is to produce a web page (which is likely), you may not want PHP to splatter these messages into the middle of the page. You can suppress such warnings two ways. First, to prevent an individual function call from producing an error message, put the @ warning- suppression operator in front of its name. Then test the return value and deal with errors yourself. That was the approach used for the previous section on connecting to the MySQL server, where connect.php printed its own messages: if (!($conn_id = @mysql_connect ("localhost", "cbuser", "cbpass"))) die ("Cannot connect to server\n"); print ("Connected\n"); if (!@mysql_select_db ("cookbook", $conn_id)) die ("Cannot select database\n"); Second, you can disable these warnings globally by using the error_reporting( ) function to set the PHP error level to zero: error_reporting (0); However, be aware that by turning off warnings this way, you won't get any notification for things that are wrong with your script that you really should know about, such as parse errors caused by malformed syntax. To obtain specific error information about failed MySQL-related operations, use mysql_errno( ) and mysql_error( ), which return a numeric error code and descriptive error string. Each function takes an optional connection identifier argument. if you omit the identifier, both functions assume you want error information for the most recently opened connection. However, prior to PHP 4.0.6, both functions require that there is a connection. For older versions of PHP, this requirement makes the error functions useless for reporting problems with the connection-establishment routines. (If mysql_connect( ) or mysql_pconnect( ) fail, mysql_errno( ) and mysql_error( ) return 0 and the empty string, just as if no error had occurred.) To work around this, you can use the PHP global variable $php_errormsg instead, as shown in the following example. The code shows how to print error messages, both for failed connection attempts and for errors that occur subsequent to a successful connection. For problems connecting, it attempts to use mysql_errno( ) and mysql_error( ) if they return useful information. Otherwise, it falls back to using $php_errormsg: if (!($conn_id = @mysql_connect ("localhost", "cbuser", "cbpass"))) { # If mysql_errno( )/mysql_error( ) work for failed connections, use # them (invoke with no argument). Otherwise, use $php_errormsg. if (mysql_errno ( )) { die (sprintf ("Cannot connect to server: %s (%d)\n", htmlspecialchars (mysql_error ( )), mysql_errno ( ))); } else { die ("Cannot connect to server: " . htmlspecialchars ($php_errormsg) . "\n"); } } print ("Connected\n"); if (!@mysql_select_db ("cookbook", $conn_id)) { die (sprintf ("Cannot select database: %s (%d)\n", htmlspecialchars (mysql_error ($conn_id)), mysql_errno ($conn_id))); } The htmlspecialchars( ) function escapes the <, >, and & characters so they display properly in web pages. It's useful here when displaying error messages because we don't know what particular characters a message contains. Use of $php_errormsg requires the track_errors variable to be enabled in your PHP initialization file. On my system, that file is /usr/local/lib/php.ini. Locate the file on your system, then make sure the track_errors line looks like this: track_errors = On; If you change the track_errors setting and you're using PHP as an Apache module, you'll need to restart Apache to make the change take effect. 2.3.6 Python Python programs signal errors by raising exceptions, and handle errors by catching exceptions in an except block. To obtain MySQL-specific error information, name an exception class and provide a variable to receive the information. Here's an example: try: conn = MySQLdb.connect (db = "cookbook", host = "localhost", user = "cbuser", passwd = "cbpass") print "Connected" except MySQLdb.Error, e: print "Cannot connect to server" print "Error code:", e.args[0] print "Error message:", e.args[1] sys.exit (1) If an exception occurs, the first and second elements of e.args will be set to the numeric error code and descriptive error message, respectively. (Note that the Error class is accessed through the MySQLdb driver module name.) 2.3.7 Java Java programs handle errors by catching exceptions. If you simply want to do the minimum amount of work, print a stack trace to inform the user where the problem lies: catch (Exception e) { e.printStackTrace ( ); } The stack trace shows the location of the problem, but not necessarily what the problem is. It may not be all that meaningful except to you, the program's developer. To be more specific, you can print the error message and code associated with an exception: · All Exception objects support the getMessage( ) method. JDBC methods may throw exceptions using SQLException objects; these are like Exception objects but also support getErrorCode( ) and getSQLState( ) methods. · For MySQL errors, getErrorCode( ) and getMessage( ) return the numeric error code and descriptive error string. · getSQLState( ) returns a string that provides error values defined according to the XOPEN SQL specification (which you may or may not find useful). · You can also get information about non-fatal warnings, which some methods generate using SQLWarning objects. SQLWarning is a subclass of SQLException, but warnings are accumulated in a list rather than thrown immediately, so they don't interrupt your program and you can print them at your leisure. The following example program, Error.java, demonstrates how to access error messages by printing all the error information it can get its hands on. It attempts to connect to the MySQL server and prints exception information if the attempt fails. Then it issues a query and prints exception and warning information if the query fails: // Error.java - demonstrate MySQL error-handling import java.sql.*; public class Error { public static void main (String[ ] args) { Connection conn = null; String url = "jdbc:mysql://localhost/cookbook"; String userName = "cbuser"; String password = "cbpass"; try { Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); conn = DriverManager.getConnection (url, userName, password); System.out.println ("Connected"); tryQuery (conn); // issue a query } catch (Exception e) { System.err.println ("Cannot connect to server"); System.err.println (e); if (e instanceof SQLException) // JDBC-specific exception? { // print general message plus any database-specific message // (note how e is cast from Exception to SQLException to // access the SQLException-specific methods) System.err.println ("SQLException: " + e.getMessage ( )); System.err.println ("SQLState: " + ((SQLException) e).getSQLState ( )); System.err.println ("VendorCode: " + ((SQLException) e).getErrorCode ( )); } } finally { if (conn != null) { try { conn.close ( ); System.out.println ("Disconnected"); } catch (SQLException e) { // print general message plus any // database-specific message System.err.println ("SQLException: " + e.getMessage ( )); System.err.println ("SQLState: " + e.getSQLState ( )); System.err.println ("VendorCode: " + e.getErrorCode ( )); } } } } public static void tryQuery (Connection conn) { Statement s = null; try { // issue a simple query s = conn.createStatement ( ); s.execute ("USE cookbook"); s.close ( ); // print any accumulated warnings SQLWarning w = conn.getWarnings ( ); while (w != null) { System.err.println ("SQLWarning: " + w.getMessage ( )); System.err.println ("SQLState: " + w.getSQLState ( )); System.err.println ("VendorCode: " + w.getErrorCode ( )); w = w.getNextWarning ( ); } } catch (SQLException e) { // print general message plus any database-specific message System.err.println ("SQLException: " + e.getMessage ( )); System.err.println ("SQLState: " + e.getSQLState ( )); System.err.println ("VendorCode: " + e.getErrorCode ( )); } } } 2.4 Writing Library Files 2.4.1 Problem You notice that you're writing similar code for common operations in several programs. 2.4.2 Solution Put functions to perform those operations in a library file. Then you write the code only once. 2.4.3 Discussion This section describes how to put code for common operations in library files. Encapsulation (or modularization) isn't really a "recipe" so much as a programming technique. Its principal benefit is that you don't have to repeat code in each program you write; instead, you just call a function that's in the library. For example, by putting the code for connecting to the cookbook database into a library function, you need not write out all the parameters associated with making that connection. Simply invoke the function from your program and you're connected. Connection establishment isn't the only operation you can encapsulate, of course. Later on in the book, other utility functions are developed and placed in library files. All such files, including those shown in this section, can be found under the lib directory of the recipes distribution. As you write your own programs, you'll probably identify several operations that you perform often and that are good candidates for inclusion in a library. The techniques demonstrated in this section will help you write your own library files. Library files have other benefits besides making it easier to write programs. They can help portability. For example, if you write connection parameters into each program that connects to the MySQL server, you have to change each program if you move them to another machine where you use different parameters. If instead you write your programs to connect to the database by calling a library function, you localize the changes that need to be made: it's necessary to modify only the affected library function, not all the programs that use it. Code encapsulation also can improve security in some ways. If you make a private library file readable only to yourself, only scripts run by you can execute routines in the file. Or suppose you have some scripts located in your web server's document tree. A properly configured server will execute the scripts and send their output to remote clients. But if the server becomes misconfigured somehow, the result can be that your scripts get sent to clients as plain text, thus displaying your MySQL username and password. (And you'll probably realize it too late. Oops.) If the code for establishing a connection to the MySQL server is placed in a library file that's located outside the document tree, those parameters won't be exposed to clients. (Be aware, though, that if you install a library file to be readable by your web server, you don't have much security should you share the web server with other developers. Any of those developers can write a web script to read and display your library file, because by default the script will run with the permissions of the web server and thus will have access to the library.) The recipes that follow demonstrate how to write, for each API, a library file that contains a routine for connecting to the cookbook database on the MySQL server. The Perl, PHP, and Python routines are written to return the appropriate type of value (a database handle, a connection identifier, or connection object), or to exit with an error message if the connection cannot be established. (The error-checking techniques used by these routines are those discussed in Recipe 2.3.) The Java connection routine demonstrates a different approach. It returns a connection object if it succeeds and otherwise throws an exception that the caller can deal with. To assist in handling such exceptions, the library also includes utility functions that return or print an error message that includes the error information returned by MySQL. Libraries are of no use by themselves; the way that each one is used is illustrated by a short "test harness" program. You can use any of these harness programs as the basis for creating new programs of your own: Make a copy of the file and add your own code between the connect and disconnect calls. Library file writing involves not only the question of what to put in the file, but also subsidiary issues such as where to install the file so it can be accessed by your programs and (on multiuser systems such as Unix) how to set its access privileges so its contents aren't exposed to people who shouldn't see it. Writing the library file and setting up your language processor to be able to find it are API-specific issues; they're dealt with in the language-specific sections to follow. By contrast, questions about file ownership and access mode are more general issues about which you'll need to make some decisions no matter which language you use (at least if you're using Unix): · If a library file is private and contains code to be used only by you, the file can be placed under your own account and made accessible only to you. Assuming a library file mylib is already owned by you, you can make it private like this: % chmod 600 mylib · If the library file is to be used only by your web server, you can install it in a server library directory and make the file owned by and accessible only to the server user ID. You may need to be root to do this. For example, if the web server runs as wwwusr, these commands make the file private to that user: · # chown wwwusr mylib # chmod 600 mylib · If the library file is public, you can place it in a location that your programming language searches automatically when it looks for libraries. (Most language processors search for libraries in some default set of directories.) You may need to be root to install files in one of these directories. Then you can make the file world readable: # chmod 444 mylib The example programs in this section assume that you'll install library files somewhere other than the directories the language processors search by default, as an excuse to demonstrate how to modify each language's search algorithm to look in a directory of your choosing. Many of the programs written in this book execute in a web context, so the library file installation directories used for the examples are the perl, php, python, and java directories under /usr/local/apache/lib. If you want to put the files somewhere else, just adjust the pathnames in the programs appropriately, or else take advantage of the facility that many programming languages provide for specifying where to look for library files by means of an environment or configuration variable. For our API languages, these variables are listed in the following table: Language Variable name Variable type Perl PERL5LIB Environment variable PHP include_path Configuration variable Python PYTHONPATH Environment variable Java CLASSPATH Environment variable In each case, the variable value is a directory or set of directories. For example, if under Unix I put Perl library files in the /u/paul/lib/perl directory, I can set the PERL5LIB environment variable for tcsh like this in my .login file: setenv PERL5LIB /u/paul/lib/perl Under Windows, if I put Perl library files in D:\lib\perl, I can set PERL5LIB as follows in AUTOEXEC.BAT: SET PERL5LIB=D:\lib\perl In each case, the variable setting tells Perl to look in the specified directory for library files, in addition to whatever other directories it would search by default. The other environment variables (PYTHONPATH and CLASSPATH) are specified using the same syntax. For more information on setting environment variables, see Recipe 1.9. For PHP, the search path is defined by the value of the include_path variable in the PHP initialization file (typically named php.ini or php3.ini). On my system, the file's pathname is /usr/local/lib/php.ini; under Windows, the file is likely to be found in the Windows system directory or under the main PHP installation directory. The value of include_path is defined with a line like this: include_path = "value" The value is specified using the same syntax as for environment variables that name directories. That is, it's a list of directory names, with the names separated by colons under Unix and semicolons under Windows. For example, if you want PHP to look for include files in the current directory and in the lib/php directory under the web server root directory /usr/local/apache, include_path should be set like this under Unix: include_path = ".:/usr/local/apache/lib/php" If you modify the initialization file and PHP is running as an Apache module, you'll need to restart Apache to make the change take effect. Now let's construct a library for each API. Each section here demonstrates how to write the library file itself, then discusses how to use the library from within programs. 2.4.4 Perl In Perl, library files are called modules, and typically have an extension of .pm ("Perl module"). Here's a sample module file, Cookbook.pm, that implements a module named Cookbook. (It's conventional for the basename of a Perl module file to be the same as the identifier on the package line in the file.) package Cookbook; # Cookbook.pm - library file with utility routine for connecting to MySQL use strict; use DBI; # Establish a connection to the cookbook database, returning a database # handle. Dies with a message if the connection cannot be established. sub connect { my $db_name = "cookbook"; my $host_name = "localhost"; my $user_name = "cbuser"; my $password = "cbpass"; my $dsn = "DBI:mysql:host=$host_name;database=$db_name"; return (DBI->connect ($dsn, $user_name, $password, { PrintError => 0, RaiseError => 1})); } 1; # return true The module encapsulates the code for establishing a connection to the MySQL server into a function connect( ), and the package identifier establishes a Cookbook namespace for the module, so you invoke the connect( ) function using the module name: $dbh = Cookbook::connect ( ); The final line of the module file is a statement that trivially evaluates to true. This is needed because Perl assumes something is wrong with a module and exits after reading it if the module doesn't return a true value. Perl locates module files by searching through the directories named in its @INC array. This array contains a default list of directories. To find out what they are on your system, invoke Perl as follows at the command line: % perl -V The last part of the output from the command shows the directories listed in the @INC array. If you install a module file in one of those directories, your scripts will find it automatically. If you install the module somewhere else, you'll need to tell your scripts where to find it by including a use lib statement. For example, if you install the Cookbook.pm module file in /usr/local/apache/lib/perl, you can write a test harness script harness.pl that uses the module as follows: #! /usr/bin/perl -w # harness.pl - test harness for Cookbook.pm library use strict; use lib qw(/usr/local/apache/lib/perl); use Cookbook; my $dbh = Cookbook::connect ( ); print "Connected\n"; $dbh->disconnect ( ); print "Disconnected\n"; exit (0); Note that harness.pl does not have a use DBI statement. It's not necessary, because the Cookbook module itself imports the DBI module, so any script that uses Cookbook also gets DBI. Another way to specify where Perl should look for module files (in addition to the directories that it searches by default) is to set the PERL5LIB environment variable. If you do that, the advantage is that your scripts won't need the use lib statement. (The corresponding disadvantage is that every user who runs scripts that use the Cookbook module will have to set PERL5LIB.) 2.4.5 PHP PHP provides an include statement that allows the contents of a file to be read into and included as part of the current script. This provides a natural mechanism for creating libraries: put the library code into an include file, install it in one of the directories in PHP's search path, and include it into scripts that need it. For example, if you create an include file named Cookbook.php, any script that needs it can use a statement like this: include "Cookbook.php"; The contents of PHP include files are written like regular scripts. We can write such a file, Cookbook.php, to contain a function, cookbook_connect( ), as follows: Although most PHP examples throughout this book don't show the tags, I've shown them as part of Cookbook.php here to emphasize that include files must enclose all PHP code within those tags. The PHP interpreter doesn't make any assumptions about the contents of an include file when it begins parsing it, because you might include a file that contains nothing but HTML. Therefore, you must use to specify explicitly which parts of the include file should be considered as PHP code rather than as HTML, just as you do in the main script. Assuming that Cookbook.php is installed in a directory that's named in PHP's search path (as defined by the include_path variable in the PHP initialization file), it can be used from a test harness script, harness.php. The entire script looks like this: If you don't have permission to modify the PHP initialization file, you can access an include file by specifying its full pathname. For example: include "/usr/local/apache/lib/php/Cookbook.php"; PHP also provides a require statement that is like include except that PHP reads the file even if the require occurs inside a control structure that never executes (such as an if block for which the condition is never true). PHP 4 adds include_once and require_once statements. These are like include and require except that if the file has already been read, its contents are not processed again. This is useful for avoiding multiple-declaration problems that can easily occur in situations where library files include other library files. A way to simulate single-inclusion behavior under PHP 3 is to associate a unique symbol with a library and process its contents only if the symbol is not already defined. For example, a library file, MyLibrary.php, might be structured like this: Where Should PHP Include Files Be Installed? PHP scripts often are placed in the document tree of your web server, and clients can request them directly. For PHP library files, I recommend that you place them somewhere outside the document tree, especially if (like Cookbook.php) they contain names and passwords. This is particularly true if you use a different extension such as .inc for the names of include files. If you do that and install include files in the document tree, they might be requested directly by clients and will be displayed as plain text, exposing their contents. To prevent that from happening, reconfigure Apache so that it treats files with the .inc extension as PHP code to be processed by the PHP interpreter rather than being displayed literally. 2.4.6 Python Python libraries are written as modules and referenced from scripts using import or from statements. To put the code for connecting to MySQL into a function, we can write a module file Cookbook.py: # Cookbook.py - library file with utility routine for connecting to MySQL import sys import MySQLdb # Establish a connection to the cookbook database, returning a connection # object. Dies with a message if the connection cannot be established. def connect ( ): host_name = "localhost" db_name = "cookbook" user_name = "cbuser" password = "cbpass" try: conn = MySQLdb.connect (db = db_name, host = host_name, user = user_name, passwd = password) return conn except MySQLdb.Error, e: print "Cannot connect to server" print "Error code:", e.args[0] print "Error message:", e.args[1] sys.exit (1) The filename basename determines the module name, so the module is called Cookbook. Module methods are accessed through the module name, thus you would invoke the connect( ) method of the Cookbook module like this: conn = Cookbook.connect ( ); The Python interpreter searches for modules in directories named in the sys.path variable. Just as with Perl's @INC array, sys.path is initialized to a default set of directories. You can find out what those directories are on your system by running Python interactively and entering a couple of commands: % python >>> import sys >>> sys.path If you put Cookbook.py in one of the default directories, you can reference it from a script using an import statement and Python will find it automatically: import Cookbook If you install Cookbook.py somewhere else, you can add the directory where it's installed to the value of sys.path. Do this by importing the sys module and invoking sys.path.insert( ). The following test harness script, harness.py, shows how to do this, assuming the Cookbook module is installed in the /usr/local/apache/lib/python directory: #! /usr/bin/python # harness.py - test harness for Cookbook.py library # Import sys module and add directory to search path import sys sys.path.insert (0, "/usr/local/apache/lib/python") import MySQLdb import Cookbook conn = Cookbook.connect ( ) print "Connected" conn.close ( ) print "Disconnected" sys.exit (0) Another way to tell Python where to find module files is to set the PYTHONPATH environment variable. If you set that variable to include your module directory, scripts that you run need not modify sys.path. It's also possible to import individual symbols from a module using a from statement: from Cookbook import connect This makes the connect( ) routine available to the script without the need for the module name, so you'd use it like this: conn = connect ( ) 2.4.7 Java Java library files are similar to Java programs in most ways: · The class line in the source file indicates a class name. · The file should have the same name as the class (with a .java extension). · You compile the .java file to produce a .class file. However, unlike regular program files, Java library files have no main( ) function. In addition, the file should begin with a package identifier that specifies the location of the class within the Java namespace. A common convention is to begin package identifiers with the reverse domain of the code author; this helps make identifiers unique and avoid conflict with classes written by other authors.[2] In my case, the domain is kitebird.com, so if I want to write a library file and place it under mcb within my domain's namespace, the library should begin with a package statement like this: [2] Domain names proceed right to left from more general to more specific within the domain namespace, whereas the Java class namespace proceeds left to right from general to specific. Thus, to use a domain as the prefix for a package name within the Java class namespace, it's necessary to reverse it. package com.kitebird.mcb; Java packages developed for this book will be placed within the com.kitebird.mcb namespace to ensure their naming uniqueness. The following library file, Cookbook.java, defines a Cookbook class that implements a connect( ) method for connecting to the cookbook database. connect( ) returns a Connection object if it succeeds, and throws an exception otherwise. To help the caller deal with failures, the Cookbook class also defines getErrorMessage( ) and printErrorMessage( ), utility routines that return the error message as a string or print it to System.err. // Cookbook.java - library file with utility routine for connecting to MySQL package com.kitebird.mcb; import java.sql.*; public class Cookbook { // Establish a connection to the cookbook database, returning // a connection object. Throws an exception if the connection // cannot be established. public static Connection connect ( ) throws Exception { String url = "jdbc:mysql://localhost/cookbook"; String user = "cbuser"; String password = "cbpass"; Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); return (DriverManager.getConnection (url, user, password)); } // Return an error message as a string public static String getErrorMessage (Exception e) { StringBuffer s = new StringBuffer ( ); if (e instanceof SQLException) // JDBC-specific exception? { // print general message plus any database-specific message s.append ("Error message: " + e.getMessage ( ) + "\n"); s.append ("Error code: " + ((SQLException) e).getErrorCode ( ) + "\n"); } else { s.append (e + "\n"); } return (s.toString ( )); } // Get the error message and print it to System.err public static void printErrorMessage (Exception e) { System.err.println (Cookbook.getErrorMessage (e)); } } The routines within the class are declared using the static keyword, which makes them class methods rather than instance methods. That's because the class is used directly rather than by creating an object from it and invoking the methods through the object. To use the Cookbook.java file, compile it to produce Cookbook.class, then install the class file in a directory that corresponds to the package identifier. This means that Cookbook.class should be installed in a directory named com/kitebird/mcb (or com\kitebird\mcb under Windows) that is located under some directory named in your CLASSPATH setting. For example, if CLASSPATH includes /usr/local/apache/lib/java under Unix, you could install Cookbook.class in the /usr/local/apache/lib/java/com/kitebird/mcb directory. (See Recipe 2.2 for more information about the CLASSPATH variable.) To use the Cookbook class from within a Java program, you must first import it, then invoke the Cookbook.connect( ) method. The following test harness program, Harness.java, shows how to do this: // Harness.java - test harness for Cookbook library class import java.sql.*; import com.kitebird.mcb.Cookbook; public class Harness { public static void main (String[ ] args) { Connection conn = null; try { conn = Cookbook.connect ( ); System.out.println ("Connected"); } catch (Exception e) { Cookbook.printErrorMessage (e); System.exit (1); } finally { if (conn != null) { try { conn.close ( ); System.out.println ("Disconnected"); } catch (Exception e) { String err = Cookbook.getErrorMessage (e); System.out.println (err); } } } } } Harness.java also shows how to use the error message routines from the Cookbook class when a MySQL-related exception occurs. printErrorMessage( ) takes the exception object and uses it to print an error message to System.err. getErrorMessage( ) returns the error message as a string. You can display the message yourself, write it to a log file, or whatever. 2.5 Issuing Queries and Retrieving Results 2.5.1 Problem You want your program to send a query to the MySQL server and retrieve the result. 2.5.2 Solution Some statements only return a status code, others return a result set (a set of rows). Most APIs provide different functions for each type of statement; if so, use the function that's appropriate for your query. 2.5.3 Discussion This section is the longest of the chapter because there are two categories of queries you can execute. Some statements retrieve information from the database; others make changes to that information. These two types of queries are handled differently. In addition, some APIs provide several different functions for issuing queries, which complicates matters further. Before we get to the examples demonstrating how to issue queries from within each API, I'll show the table used for examples, then discuss the general statement categories and outline a strategy for processing them. In Chapter 1, we created a table named limbs to use for some sample queries. In this chapter, we'll use a different table named profile. It's based on the idea of a "buddy list," that is, the set of people we like to keep in touch with while we're online. To maintain a profile about each person, we can use the following table: CREATE TABLE profile ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name CHAR(20) NOT NULL, birth DATE, color ENUM('blue','red','green','brown','black','white'), foods SET('lutefisk','burrito','curry','eggroll','fadge','pizza'), cats INT, PRIMARY KEY (id) ); The profile table reflects that the things that are important to us are each buddy's name, age, favorite color, favorite foods, and number of cats—obviously one of those goofy tables that are used only for examples in a book![3] The table includes an id column containing unique values so that we can distinguish records from each other, even if two buddies have the same name. id and name are NOT NULL because they're each required to have a value. The other columns are allowed to be NULL because we might not know the value to put into them for any given individual. (We'll use NULL to signify "unknown.") Notice that although we want to keep track of age, there is no age column in the table. Instead, there is a birth column of DATE type. That's because ages change, but birthdays don't. If we recorded age values, we'd have to keep updating them. Storing the birth date is better because it's stable, and we can use it to calculate age at any given moment. (Age calculations are discussed in Recipe 5.20.) color is an ENUM column; color values can be any one of the listed values. foods is a SET, which allows the value to be chosen as any combination of the individual set members. That way we can record multiple favorite foods for any buddy. [3] Actually, it's not that goofy. The table uses several different data types for its columns, and these will come in handy later for illustrating how to solve particular kinds of problems that pertain to specific column types. To create the table, use the profile.sql script in the tables directory of the recipes distribution. Change location into that directory, then run the following command: % mysql cookbook < profile.sql Another way to create the table is to issue the CREATE TABLE statement manually from within the mysql program, but I recommend that you use the script, because it also loads sample data into the table. That way you can experiment with the table, then restore it after changing it by running the script again.[4] [4] See the note at the very end of this chapter on the importance of restoring the profile table. The initial contents of the profile table loaded by the profile.sql script look like this: mysql> SELECT * FROM profile; +----+---------+------------+-------+-----------------------+------+ | id | name | birth | color | foods | cats | +----+---------+------------+-------+-----------------------+------+ | 1 | Fred | 1970-04-13 | black | lutefisk,fadge,pizza | 0 | | 2 | Mort | 1969-09-30 | white | burrito,curry,eggroll | 3 | | 3 | Brit | 1957-12-01 | red | burrito,curry,pizza | 1 | | 4 | Carl | 1973-11-02 | red | eggroll,pizza | 4 | | 5 | Sean | 1963-07-04 | blue | burrito,curry | 5 | | 6 | Alan | 1965-02-14 | red | curry,fadge | 1 | | 7 | Mara | 1968-09-17 | green | lutefisk,fadge | 1 | | 8 | Shepard | 1975-09-02 | black | curry,pizza | 2 | | 9 | Dick | 1952-08-20 | green | lutefisk,fadge | 0 | | 10 | Tony | 1960-05-01 | white | burrito,pizza | 0 | +----+---------+------------+-------+-----------------------+------+ Most of the columns in the profile table allow NULL values, but none of the rows in the sample dataset actually contain NULL yet. This is because NULL values complicate query processing a bit and I don't want to deal with those complications until we get to Recipe 2.8 and Recipe 2.9. 2.5.4 SQL Statement Categories SQL statements can be divided into two broad categories: · Statements that do not return a result set (that is, a set of rows). This statement category includes INSERT, DELETE, and UPDATE. As a general rule, statements of this type generally change the database in some way. There are some exceptions, such as USE db_name, which changes the current (default) database for your session without making any changes to the database itself. · Statements that return a result set, such as SELECT, SHOW, EXPLAIN, and DESCRIBE. I refer to such statements generically as SELECT statements, but you should understand that category to include any statement that returns rows. The first step in processing a query is to send it to the MySQL server for execution. Some APIs (Perl and Java, for example) recognize a distinction between the two categories of statements and provide separate calls for executing them. Others (such as PHP and Python) do not and have a single call for issuing all statements. However, one thing all APIs have in common is that you don't use any special character to indicate the end of the query. No terminator is necessary because the end of the query string implicitly terminates the query. This differs from the way you issue queries in the mysql program, where you terminate statements using a semicolon ( ;) or \g. (It also differs from the way I normally show the syntax for SQL statements, because I include semicolons to make it clear where statements end.) After sending the query to the server, the next step is to check whether or not it executed successfully. Do not neglect this step. You'll regret it if you do. If a query fails and you proceed on the basis that it succeeded, your program won't work. If the query did execute, your next step depends on the type of query you issued. If it's one that returns no result set, there's nothing else to do (unless you want to check how many rows were affected by the query). If the query does return a result set, you can fetch its rows, then close the result set. Don't Shoot Yourself in the Foot: Check for Errors Apparently, the principle that you should check for errors is not so obvious or widely appreciated as one might hope. Many messages posted on MySQL-related mailing lists are requests for help with programs that fail for reasons unknown to the people that wrote them. In a surprising number of cases, the reason these developers are mystified by their programs is that they put in no error checking, and thus gave themselves no way to know that there was a problem or to find out what it was! You cannot help yourself this way. Plan for failure by checking for errors so that you can take appropriate action if they occur. Now we're ready to see how to issue queries in each API. Note that although the scripts check for errors as necessary, for brevity they just print a generic message that an error occurred. You can display more specific error messages using the techniques illustrated in Recipe 2.3. 2.5.5 Perl The Perl DBI module provides two basic approaches to query execution, depending on whether or not you expect to get back a result set. To issue a query such as INSERT or UPDATE that returns no result set, use the do( ) method. It executes the query and returns the number of rows affected by the query, or undef if an error occurs. For example, if Fred gets a new kitty, the following query can be used to increment his cats count by one: my $count = $dbh->do ("UPDATE profile SET cats = cats+1 WHERE name = 'Fred'"); if ($count) # print row count if no error occurred { $count += 0; print "$count rows were updated\n"; } If the query executes successfully but affects no rows, do( ) returns a special value, the string "0E0" (that is, the value zero in scientific notation). "0E0" can be used for testing the execution status of a query because it is true in Boolean contexts (unlike undef). For successful queries, it can also be used when counting how many rows were affected, because it is treated as the number zero in numeric contexts. Of course, if you print that value as is, you'll print "0E0", which might look kind of weird to people who use your program. The preceding example shows one way to make sure this doesn't happen: adding zero to the value explicitly coerces it to numeric form so that it displays as 0. You can also use printf with a %d format specifier to cause an implicit numeric conversion: my $count = $dbh->do ("UPDATE profile SET color = color WHERE name = 'Fred'"); if ($count) # print row count if no error occurred { printf "%d rows were updated\n", $count; } If RaiseError is enabled, your script will terminate automatically if a DBI-related error occurs and you don't need to bother checking $count to see if do( ) failed: my $count = $dbh->do ("UPDATE profile SET color = color WHERE name = 'Fred'"); printf "%d rows were updated\n", $count; To process queries such as SELECT that do return a result set, use a different approach that involves four steps: · Specify the query by calling prepare( ) using the database handle. prepare( ) returns a statement handle to use with all subsequent operations on the query. (If an error occurs, the script terminates if RaiseError is enabled; otherwise, prepare( ) returns undef.) · Call execute( ) to execute the query and generate the result set. · Perform a loop to fetch the rows returned by the query. DBI provides several methods you can use in this loop, which we'll describe shortly. · Release resources associated with the result set by calling finish( ). The following example illustrates these steps, using fetchrow_array( ) as the row-fetching method and assuming RaiseError is enabled: my $sth = $dbh->prepare ("SELECT id, name, cats FROM profile"); $sth->execute ( ); my $count = 0; while (my @val = $sth->fetchrow_array ( )) { print "id: $val[0], name: $val[1], cats: $val[2]\n"; ++$count; } $sth->finish ( ); print "$count rows were returned\n"; The row-fetching loop just shown is followed by a call to finish( ), which closes the result set and tells the server that it can free any resources associated with it. You don't actually need to call finish( ) if you fetch every row in the set, because DBI notices when you've reached the last row and releases the set for itself. Thus, the example could have omitted the finish( ) call without ill effect. It's more important to invoke finish( ) explicitly if you fetch only part of a result set. The example illustrates that if you want to know how many rows a result set contains, you should count them yourself while you're fetching them. Do not use the DBI rows( ) method for this purpose; the DBI documentation discourages this practice. (The reason is that it is not necessarily reliable for SELECT statements—not because of some deficiency in DBI, but because of differences in the behavior of various database engines.) DBI has several functions that can be used to obtain a row at a time in a row-fetching loop. The one used in the previous example, fetchrow_array( ), returns an array containing the next row, or an empty list when there are no more rows. Elements of the array are accessed as $val[0], $val[1], ..., and are present in the array in the same order they are named in the SELECT statement. This function is most useful for queries that explicitly name columns to selected. (If you retrieve columns with SELECT *, there are no guarantees about the positions of columns within the array.) fetchrow_arrayref( ) is like fetchrow_array( ), except that it returns a reference to the array, or undef when there are no more rows. Elements of the array are accessed as $ref->[0], $ref->[1], and so forth. As with fetchrow_array( ), the values are present in the order named in the query: my $sth = $dbh->prepare ("SELECT id, name, cats FROM profile"); $sth->execute ( ); my $count = 0; while (my $ref = $sth->fetchrow_arrayref ( )) { print "id: $ref->[0], name: $ref->[1], cats: $ref->[2]\n"; ++$count; } print "$count rows were returned\n"; fetchrow_hashref( ) returns a reference to a hash structure, or undef when there are no more rows: my $sth = $dbh->prepare ("SELECT id, name, cats FROM profile"); $sth->execute ( ); my $count = 0; while (my $ref = $sth->fetchrow_hashref ( )) { print "id: $ref->{id}, name: $ref->{name}, cats: $ref->{cats}\n"; ++$count; } print "$count rows were returned\n"; The elements of the hash are accessed using the names of the columns that are selected by the query ($ref->{id}, $ref->{name}, and so forth). fetchrow_hashref( ) is particularly useful for SELECT * queries, because you can access elements of rows without knowing anything about the order in which columns are returned. You just need to know their names. On the other hand, it's more expensive to set up a hash than an array, so fetchrow_hashref( ) is slower than fetchrow_array( ) or fetchrow_arrayref( ). It's also possible to "lose" row elements if they have the same name, because column names must be unique. The following query selects two values, but fetchrow_hashref( ) would return a hash structure containing a single element named id: SELECT id, id FROM profile To avoid this problem, you can use column aliases to ensure that like-named columns have distinct names in the result set. The following query retrieves the same columns as the previous query, but gives them the distinct names id and id2: SELECT id, id AS id2 FROM profile Admittedly, this query is pretty silly, but if you're retrieving columns from multiple tables, you may very easily run into the problem of having columns in the result set that have the same name. An example where this occurs may be seen in Recipe 12.4. In addition to the methods for performing the query execution process just described, DBI provides several high-level retrieval methods that issue a query and return the result set in a single operation. These all are database handle methods that take care of creating and disposing of the statement handle internally before returning the result set. Where the methods differ is the form in which they return the result. Some return the entire result set, others return a single row or column of the set, as summarized in the following table:[5] [5] selectrow_arrayref( ) and selectall_hashref( ) require DBI 1.15 or newer. selectrow_hashref( ) requires DBI 1.20 or newer (it was present a few versions before that, but with a different behavior than it uses now). Method Return value selectrow_array( ) First row of result set as an array selectrow_arrayref( ) First row of result set as a reference to an array selectrow_hashref( ) First row of result set as a reference to a hash selectcol_arrayref( ) First column of result set as a reference to an array selectall_arrayref( ) Entire result set as a reference to an array of array references selectall_hashref( ) Entire result set as a reference to a hash of hash references Most of these methods return a reference. The exception is selectrow_array( ), which selects the first row of the result set and returns an array or a scalar, depending on how you call it. In array context, selectrow_array( ) returns the entire row as an array (or the empty list if no row was selected). This is useful for queries from which you expect to obtain only a single row: my @val = $dbh->selectrow_array ( "SELECT name, birth, foods FROM profile WHERE id = 3"); When selectrow_array( ) is called in array context, the return value can be used to determine the size of the result set. The column count is the number of elements in the array, and the row count is 1 or 0: my $ncols = @val; my $nrows = ($ncols ? 1 : 0); You can also invoke selectrow_array( ) in scalar context, in which case it returns only the first column from the row. This is especially convenient for queries that return a single value: my $buddy_count = $dbh->selectrow_array ("SELECT COUNT(*) FROM profile"); If a query returns no result, selectrow_array( ) returns an empty array or undef, depending on whether you call it in array or scalar context. selectrow_arrayref( ) and selectrow_hashref( ) select the first row of the result set and return a reference to it, or undef if no row was selected. To access the column values, treat the reference the same way you treat the return value from fetchrow_arrayref( ) or fetchrow_hashref( ). You can also use the reference to get the row and column counts: my $ref = $dbh->selectrow_arrayref ($query); my $ncols = (defined ($ref) ? @{$ref} : 0); my $nrows = ($ncols ? 1 : 0); my $ref = $dbh->selectrow_hashref ($query); my $ncols = (defined ($ref) ? keys (%{$ref}) : 0); my $nrows = ($ncols ? 1 : 0); With selectcol_arrayref( ), a reference to a single-column array is returned, representing the first column of the result set. Assuming a non-undef return value, elements of the array are accessed as $ref->[i] for the value from row i. The number of rows is the number of elements in the array, and the column count is 1 or 0: my $ref = $dbh->selectcol_arrayref ($query); my $nrows = (defined ($ref) ? @{$ref} : 0); my $ncols = ($nrows ? 1 : 0); selectall_arrayref( ) returns a reference to an array, where the array contains an element for each row of the result. Each of these elements is a reference to an array. To access row i of the result set, use $ref->[i] to get a reference to the row. Then treat the row reference the same way as a return value from fetchrow_arrayref( ) to access individual column values in the row. The result set row and column counts are available as follows: my $ref = $dbh->selectall_arrayref ($query); my $nrows = (defined ($ref) ? @{$ref} : 0); my $ncols = ($nrows ? @{$ref->[0]} : 0); selectall_hashref( ) is somewhat similar to selectall_arrayref( ), but returns a reference to a hash, each element of which is a hash reference to a row of the result. To call it, specify an argument that indicates which column to use for hash keys. For example, if you're retrieving rows from the profile table, the PRIMARY KEY is the id column: my $ref = $dbh->selectall_hashref ("SELECT * FROM profile", "id"); Then access rows using the keys of the hash. For example, if one of the rows has a key column value of 12, the hash reference for the row is accessed as $ref->{12}. That value is keyed on column names, which you can use to access individual column elements (for example, $ref->{12}->{name}). The result set row and column counts are available as follows: my @keys = (defined ($ref) ? keys (%{$ref}) : ( )); my $nrows = scalar (@keys); my $ncols = ($nrows ? keys (%{$ref->{$keys[0]}}) : 0); The selectall_XXX( ) methods are useful when you need to process a result set more than once, because DBI provides no way to "rewind" a result set. By assigning the entire result set to a variable, you can iterate through its elements as often as you please. Take care when using the high-level methods if you have RaiseError disabled. In that case, a method's return value may not always allow you to distinguish an error from an empty result set. For example, if you call selectrow_array( ) in scalar context to retrieve a single value, an undef return value is particularly ambiguous because it may indicate any of three things: an error, an empty result set, or a result set consisting of a single NULL value. If you need to test for an error, you can check the value of $DBI::errstr or $DBI::err. 2.5.6 PHP PHP doesn't have separate functions for issuing queries that return result sets and those that do not. Instead, there is a single function mysql_query( ) for all queries. mysql_query( ) takes a query string and an optional connection identifier as arguments, and returns a result identifier. If you leave out the connection identifier argument, mysql_query( ) uses the most recently opened connection by default. The first statement below uses an explicit identifier; the second uses the default connection: $result_id = mysql_query ($query, $conn_id); $result_id = mysql_query ($query); If the query fails, $result_id will be FALSE. This means that an error occurred because your query was bad: it was syntactically invalid, you didn't have permission to access a table named in the query, or some other problem prevented the query from executing. A FALSE return value does not mean that the query affected 0 rows (for a DELETE, INSERT, or UPDATE) or returned rows (for a SELECT). If $result_id is not FALSE, the query executed properly. What you do at that point depends on the type of query. For queries that don't return rows, $result_id will be TRUE, and the query has completed. If you want, you can call mysql_affected_rows( ) to find out how many rows were changed: $result_id = mysql_query ("DELETE FROM profile WHERE cats = 0", $conn_id); if (!$result_id) die ("Oops, the query failed"); print (mysql_affected_rows ($conn_id) . " rows were deleted\n"); mysql_affected_rows( ) takes the connection identifier as its argument. If you omit the argument, the current connection is assumed. For queries that return a result set, mysql_query( ) returns a nonzero result identifier. Generally, you use this identifier to call a row-fetching function in a loop, then call mysql_free_result( ) to release the result set. The result identifier is really nothing more than a number that tells PHP which result set you're using. This identifier is not a count of the number of rows selected, nor does it contain the contents of any of those rows. Many beginning PHP programmers make the mistake of thinking mysql_query( ) returns a row count or a result set, but it doesn't. Make sure you're clear on this point and you'll save yourself a lot of trouble. Here's an example that shows how to run a SELECT query and use the result identifier to fetch the rows: $result_id = mysql_query ("SELECT id, name, cats FROM profile", $conn_id); if (!$result_id) die ("Oops, the query failed"); while ($row = mysql_fetch_row ($result_id)) print ("id: $row[0], name: $row[1], cats: $row[2]\n"); print (mysql_num_rows ($result_id) . " rows were returned\n"); mysql_free_result ($result_id); The example demonstrates that you obtain the rows in the result set by executing a loop in which you pass the result identifier to one of PHP's row-fetching functions. To obtain a count of the number of rows in a result set, pass the result identifier to mysql_num_rows( ). When there are no more rows, pass the identifier to mysql_free_result( ) to close the result set. (After you call mysql_free_result( ), don't try to fetch a row or get the row count, because at that point $result_id is no longer valid.) Each PHP row-fetching function returns the next row of the result set indicated by $result_id, or FALSE when there are no more rows. Where they differ is in the data type of the return value. The function shown in the preceding example, mysql_fetch_row( ), returns an array whose elements correspond to the columns selected by the query and are accessed using numeric subscripts. mysql_fetch_array( ) is like mysql_fetch_row( ), but the array it returns also contains elements that can be accessed using the names of the selected columns. In other words, you can access each column using either its numeric position or its name: $result_id = mysql_query ("SELECT id, name, cats FROM profile", $conn_id); if (!$result_id) die ("Oops, the query failed"); while ($row = mysql_fetch_array ($result_id)) { print ("id: $row[0], name: $row[1], cats: $row[2]\n"); print ("id: $row[id], name: $row[name], cats: $row[cats]\n"); } print (mysql_num_rows ($result_id) . " rows were returned\n"); mysql_free_result ($result_id); Despite what you might expect, mysql_fetch_array( ) is not appreciably slower than mysql_fetch_row( ), even though the array it returns contains more information. The previous example does not quote the non-numeric element names because they appear inside a quoted string. Should you refer to the elements outside of a string, the element names should be quoted: printf ("id: %s, name: %s, cats: %s\n", $row["id"], $row["name"], $row["cats"]); mysql_fetch_object( ) returns an object having members that correspond to the columns selected by the query and that are accessed using the column names: $result_id = mysql_query ("SELECT id, name, cats FROM profile", $conn_id); if (!$result_id) die ("Oops, the query failed"); while ($row = mysql_fetch_object ($result_id)) print ("id: $row->id, name: $row->name, cats: $row->cats\n"); print (mysql_num_rows ($result_id) . " rows were returned\n"); mysql_free_result ($result_id); PHP 4.0.3 adds a fourth row-fetching function, mysql_fetch_assoc( ), that returns an array containing elements that are accessed by name. In other words, it is like mysql_fetch_array( ), except that the row does not contain the values accessed by numeric index. Don't Use count( ) to Get a Column Count in PHP 3 PHP programmers sometimes fetch a result set row and then use count($row) to determine how many values the row contains. It's preferable to use mysql_num_fields( ) instead, as you can see for yourself by executing the following fragment of PHP code: if (!($result_id = mysql_query ("SELECT 1, 0, NULL", $conn_id))) die ("Cannot issue query\n"); $count = mysql_num_fields ($result_id); print ("The row contains $count columns\n"); if (!($row = mysql_fetch_row ($result_id))) die ("Cannot fetch row\n"); $count = count ($row); print ("The row contains $count columns\n"); If you run the code under PHP 3, you'll find that count( ) returns 2. With PHP 4, count( ) returns 3. These differing results occur because count( ) counts array values that correspond to NULL values in PHP 4, but not in PHP 3. By contrast, mysql_field_count( ) uniformly returns 3 for both versions of PHP. The moral is that count( ) won't necessarily give you an accurate value. Use mysql_field_count( ) if you want to know the true column count. 2.5.7 Python The Python DB-API interface does not have distinct calls for queries that return a result set and those that do not. To process a query in Python, use your database connection object to get a cursor object.[6] Then use the cursor's execute( ) method to send the query to the server. If there is no result set, the query is completed, and you can use the cursor's rowcount attribute to determine how many records were changed:[7] [6] If you're familiar with the term "cursor" as provided on the server side in some databases, MySQL doesn't really provide cursors the same way. Instead, the MySQLdb module emulates cursors on the client side of query execution. [7] Note that rowcount is an attribute, not a function. Refer to it as rowcount, not rowcount( ), or an exception will be raised. try: cursor = conn.cursor ( ) cursor.execute ("UPDATE profile SET cats = cats+1 WHERE name = 'Fred'") print "%d rows were updated" % cursor.rowcount except MySQLdb.Error, e: print "Oops, the query failed" print e If the query does return a result set, fetch its rows and close the set. DB-API provides a couple of methods for retrieving rows. fetchone( ) returns the next row as a sequence (or None when there are no more rows): try: cursor = conn.cursor ( ) cursor.execute ("SELECT id, name, cats FROM profile") while 1: row = cursor.fetchone ( ) if row == None: break print "id: %s, name: %s, cats: %s" % (row[0], row[1], row[2]) print "%d rows were returned" % cursor.rowcount cursor.close ( ) except MySQLdb.Error, e: print "Oops, the query failed" print e As you can see from the preceding example, the rowcount attribute is useful for SELECT queries, too; it indicates the number of rows in the result set. Another row-fetching method, fetchall( ), returns the entire result set as a sequence of sequences. You can iterate through the sequence to access the rows: try: cursor = conn.cursor ( ) cursor.execute ("SELECT id, name, cats FROM profile") rows = cursor.fetchall ( ) for row in rows: print "id: %s, name: %s, cats: %s" % (row[0], row[1], row[2]) print "%d rows were returned" % cursor.rowcount cursor.close ( ) except MySQLdb.Error, e: print "Oops, the query failed" print e Like DBI, DB-API doesn't provide any way to rewind a result set, so fetchall( ) can be convenient when you need to iterate through the rows of the result set more than once or access individual values directly. For example, if rows holds the result set, you can access the value of the third column in the second row as rows[1][2] (indexes begin at 0, not 1). To access row values by column name, specify the DictCursor cursor type when you create the cursor object. This causes rows to be returned as Python dictionary objects with named elements: try: cursor = conn.cursor (MySQLdb.cursors.DictCursor) cursor.execute ("SELECT id, name, cats FROM profile") for row in cursor.fetchall ( ): print "id: %s, name: %s, cats: %s" \ % (row["id"], row["name"], row["cats"]) print "%d rows were returned" % cursor.rowcount cursor.close ( ) except MySQLdb.Error, e: print "Oops, the query failed" print e 2.5.8 Java The JDBC interface provides specific object types for the various phases of query processing. Queries are issued in JDBC by passing SQL strings to Java objects of one type. The results, if there are any, are returned as objects of another type. Problems that occur while accessing the database cause exceptions to be thrown. To issue a query, the first step is to get a Statement object by calling the createStatement( ) method of your Connection object: Statement s = conn.createStatement ( ); Then use the Statement object to send the query to the server. JDBC provides several methods for doing this. Choose the one that's appropriate for the type of statement you want to issue: executeUpdate( ) for statements that don't return a result set, executeQuery( ) for statements that do, and execute( ) when you don't know. The executeUpdate( ) method sends a query that generates no result set to the server and returns a count indicating the number of rows that were affected. When you're done with the statement object, close it. The following example illustrates this sequence of events: try { Statement s = conn.createStatement ( ); int count = s.executeUpdate ("DELETE FROM profile WHERE cats = 0"); s.close ( ); // close statement System.out.println (count + " rows were deleted"); } catch (Exception e) { Cookbook.printErrorMessage (e); } For statements that return a result set, use executeQuery( ). Then get a result set object and use it to retrieve the row values. When you're done, close both the result set and statement objects: try { Statement s = conn.createStatement ( ); s.executeQuery ("SELECT id, name, cats FROM profile"); ResultSet rs = s.getResultSet ( ); int count = 0; while (rs.next ( )) // loop through rows of result set { int id = rs.getInt (1); // extract columns 1, 2, and 3 String name = rs.getString (2); int cats = rs.getInt (3); System.out.println ("id: " + id + ", name: " + name + ", cats: " + cats); ++count; } rs.close ( ); // close result set s.close ( ); // close statement System.out.println (count + " rows were returned"); } catch (Exception e) { Cookbook.printErrorMessage (e); } The ResultSet object returned by the getResultSet( ) method of your Statement object has a number of methods of its own, such as next( ) to fetch rows and various getXXX( ) methods that access columns of the current row. Initially the result set is positioned just before the first row of the set. Call next( ) to fetch each row in succession until it returns false, indicating that there are no more rows. To determine the number of rows in a result set, count them yourself, as shown in the preceding example. Column values are accessed using methods such as getInt( ), getString( ), getFloat( ), and getDate( ). To obtain the column value as a generic object, use getObject( ). The getXXX( ) calls can be invoked with an argument indicating either column position (beginning at 1, not 0) or column name. The previous example shows how to retrieve the id, name, and cats columns by position. To access columns by name instead, the row-fetching loop of that example can be rewritten as follows: while (rs.next ( )) // loop through rows of result set { int id = rs.getInt ("id"); String name = rs.getString ("name"); int cats = rs.getInt ("cats"); System.out.println ("id: " + id + ", name: " + name + ", cats: " + cats); ++count; } You can retrieve a given column value using any getXXX( ) call that makes sense for the column type. For example, you can use getString( ) to retrieve any column value as a string: String id = rs.getString ("id"); String name = rs.getString ("name"); String cats = rs.getString ("cats"); System.out.println ("id: " + id + ", name: " + name + ", cats: " + cats); Or you can use getObject( ) to retrieve values as generic objects and convert the values as necessary. The following code uses toString( ) to convert object values to printable form: Object id = rs.getObject ("id"); Object name = rs.getObject ("name"); Object cats = rs.getObject ("cats"); System.out.println ("id: " + id.toString ( ) + ", name: " + name.toString ( ) + ", cats: " + cats.toString ( )); To find out how many columns are in each row, access the result set's metadata. The following code uses the column count to print each row's columns as a comma-separated list of values: try { Statement s = conn.createStatement ( ); s.executeQuery ("SELECT * FROM profile"); ResultSet rs = s.getResultSet ( ); ResultSetMetaData md = rs.getMetaData ( ); // get result set metadata int ncols = md.getColumnCount ( ); // get column count from metadata int count = 0; while (rs.next ( )) // loop through rows of result set { for (int i = 0; i < ncols; i++) // loop through columns { String val = rs.getString (i+1); if (i > 0) System.out.print (", "); System.out.print (val); } System.out.println ( ); ++count; } rs.close ( ); // close result set s.close ( ); // close statement System.out.println (count + " rows were returned"); } catch (Exception e) { Cookbook.printErrorMessage (e); } The third JDBC query-executing method, execute( ), works for either type of query. It's particularly useful when you receive a query string from an external source and don't know whether or not it generates a result set. The return value from execute( ) indicates the query type so that you can process it appropriately: if execute( ) returns true, there is a result set, otherwise not. Typically you'd use it something like this, where queryStr represents an arbitrary SQL statement: try { Statement s = conn.createStatement ( ); if (s.execute (queryStr)) { // there is a result set ResultSet rs = s.getResultSet ( ); // ... process result set here ... rs.close ( ); // close result set } else { // there is no result set, just print the row count System.out.println (s.getUpdateCount ( ) + " rows were affected"); } s.close ( ); // close statement } catch (Exception e) { Cookbook.printErrorMessage (e); } Closing JDBC Statement and Result Set Objects The JDBC query-issuing examples in this section close the statement and result set objects explicitly when they are done with those objects. Some Java implementations close them automatically when you close the connection. However, buggy implementations may fail to do this properly, so it's best not to rely on that behavior. Close the objects yourself when you're done with them to avoid difficulties. 2.6 Moving Around Within a Result Set 2.6.1 Problem You want to iterate through a result set multiple times, or to move to arbitrary rows within the result. 2.6.2 Solution If your API has functions that provide these capabilities, use them. If not, fetch the result set into a data structure so that you can access the rows however you please. 2.6.3 Discussion Some APIs allow you to "rewind" a result set so you can iterate through its rows again. Some also allow you to move to arbitrary rows within the set, which in effect gives you random access to the rows. Our APIs offer these capabilities as follows: · Perl DBI and Python DB-API don't allow direct positioning within a result set. · PHP allows row positioning with the mysql_data_seek( ) function. Pass it a result set identifier and a row number (in the range from 0 to mysql_num_rows( )-1). Subsequent calls to row-fetching functions return rows sequentially beginning with the given row. PHP also provides a mysql_result( ) function that takes row and column indexes for random access to individual values within the result set. However, mysql_result( ) is slow and normally should not be used. · JDBC 2 introduces the concept of a "scrollable" result set, along with methods for moving back and forth among rows. This is not present in earlier versions of JDBC, although the MySQL Connector/J driver does happen to support next( ) and previous( ) methods even for JDBC 1.12. Whether or not a particular database-access API allows rewinding and positioning, your programs can achieve random access into a result set by fetching all rows from a result set and saving them into a data structure. For example, you can use a two-dimensional array that stores result rows and columns as elements of a matrix. Once you've done that, you can iterate through the result set multiple times or use its elements in random access fashion however you please. If your API provides a call that returns an entire result set in a single operation, it's relatively trivial to generate a matrix. (Perl and Python can do this.) Otherwise, you need to run a row-fetching loop and save the rows yourself. 2.7 Using Prepared Statements and Placeholders in Queries 2.7.1 Problem You want to write queries that are more generic and don't refer to specific data values, so that you can reuse them. 2.7.2 Solution Use your API's placeholder mechanism, if it has one. 2.7.3 Discussion One way to construct SQL statements from within a program is to put data values literally into the query string, as in these examples: SELECT * FROM profile WHERE age > 40 AND color = 'green' INSERT INTO profile (name,color) VALUES('Gary','blue') Some APIs provide an alternative that allows you to specify query strings that do not include literal data values. Using this approach, you write the statement using placeholders—special characters that indicate where the values go. One common placeholder character is ?, so the previous queries might be rewritten to use placeholders like this: SELECT * FROM profile WHERE age > ? AND color = ? INSERT INTO profile (name,color) VALUES(?,?) For APIs that support this kind of thing, you pass the string to the database to allow it to prepare a query plan. Then you supply data values and bind them to the placeholders when you execute the query. You can reuse the prepared query by binding different values to it each time it's executed. One of the benefits of prepared statements and placeholders is that parameter binding operations automatically handle escaping of characters such as quotes and backslashes that you have to worry about yourself if you put the data values into the query yourself. This can be especially useful if you're inserting binary data such as images into your database, or using data values with unknown content such as input submitted by a remote user through a form in a web page. Another benefit of prepared statements is that they encourage statement reuse. Statements become more generic because they contain placeholders rather than specific data values. If you're executing an operation over and over, you may be able to reuse a prepared statement and simply bind different data values to it each time you execute it. If so, you gain a performance benefit, at least for databases that support query planning. For example, if a program issues a particular type of SELECT statement several times while it runs, such a database can construct a plan for the statement, then reuse it each time, rather than rebuilding the plan over and over. MySQL doesn't build query plans, so you don't get any performance boost from using prepared statements. However, if you port a program to a database that does use query plans, you'll gain the advantage of prepared statements automatically if you've written your program from the outset to use them. You won't have to convert from non-prepared statements to enjoy that benefit. A third benefit is that code that uses placeholder-based queries can be easier to read, although that's somewhat subjective. As you read through this section, you might compare the queries used here with those from the previous section that did not use placeholders, to see which you prefer. 2.7.4 Perl To use placeholders in DBI scripts, put a ? in your query string at each location where you want to insert a data value, then bind the values to the query. You can bind values by passing them to do( ) or execute( ), or by calling a DBI method specifically intended for placeholder substitution. With do( ), pass the query string and the data values in the same call: my $count = $dbh->do ("UPDATE profile SET color = ? WHERE name = ?", undef, "green", "Mara"); The arguments after the query string should be undef followed by the data values, one value for each placeholder. (The undef argument that follows the query string is a historical artifact, but must be present.) With prepare( ) plus execute( ), pass the query string to prepare( ) to get a statement handle. Then use that handle to pass the data values via execute( ): my $sth = $dbh->prepare ("UPDATE profile SET color = ? WHERE name = ?"); my $count = $sth->execute ("green", "Mara"); You can use placeholders for SELECT statements, too. The following query looks for records having a name value that begins with "M": my $sth = $dbh->prepare ("SELECT * FROM profile WHERE name LIKE ?"); $sth->execute ("M%"); while (my $ref = $sth->fetchrow_hashref ( )) { print "id: $ref->{id}, name: $ref->{name}, cats: $ref->{cats}\n"; } $sth->finish ( ); A third way of binding values to placeholders is to use the bind_param( ) call. It takes two arguments, a placeholder position and a value to be bound to the placeholder at that position. (Placeholder positions begin with 1, not 0.) The previous two examples can be rewritten to use bind_param( ) as follows: my $sth = $dbh->prepare ("UPDATE profile SET color = ? WHERE name = ?"); $sth->bind_param (1, "green"); $sth->bind_param (2, "Mara"); my $count = $sth->execute ( ); my $sth = $dbh->prepare ("SELECT * FROM profile WHERE name LIKE ?"); $sth->bind_param (1, "M%"); $sth->execute ( ); while (my $ref = $sth->fetchrow_hashref ( )) { print "id: $ref->{id}, name: $ref->{name}, cats: $ref->{cats}\n"; } $sth->finish ( ); No matter which method you use for placeholders, don't put any quotes around the ? characters, not even for placeholders that represent strings. DBI adds quotes as necessary on its own. In fact, if you do put quotes around the placeholder character, DBI will interpret it as the literal string constant "?", not as a placeholder. The high-level retrieval methods such as selectrow_array( ) and selectall_arrayref( ) can be used with placeholders, too. Like the do( ) method, the arguments are the query string and undef, followed by the data values to be bound to the placeholders that occur in the query string. Here's an example: my $ref = $dbh->selectall_arrayref ( "SELECT name, birth, foods FROM profile WHERE id > ? AND color = ?", undef, 3, "green"); Generating a List of Placeholders When you want to use placeholders for a set of data values that may vary in size, you must construct a list of placeholder characters. For example, in Perl, the following statement creates a string consisting of n placeholder characters separated by commas: $str = join (",", ("?") x n); The x repetition operator, when applied to a list, produces n copies of the list, so the join( ) call joins these lists to produce a single string containing n comma- separated instances of the ? character. This is handy when you want to bind an array of data values to a list of placeholders in a query string, because the size of the array indicates how many placeholder characters are needed: $str = join (",", ("?") x @values); Another method of generating a list of placeholders that is perhaps less cryptic looks like this: $str = "?" if @values; $str .= ",?" for 1 .. @values-1; Yet a third method is as follows: $str = "?" if @values; for (my $i = 1; $i < @values; $i++) { $str .= ",?"; } That method's syntax is less Perl-specific and therefore easier to translate into other languages. For example, the equivalent method in Python looks like this: str = "" if len (values) > 0: str = "?" for i in range (1, len (values)): str = str + ",?" 2.7.5 PHP PHP provides no support for placeholders. See Recipe 2.9 to find out how to construct queries that refer to data values that may contain special characters. Or see Recipe 2.10, which develops a class-based interface for PHP that emulates placeholders. 2.7.6 Python Python's MySQLdb module implements the concept of placeholders by using format specifiers in the query string. To use placeholders, invoke the execute( ) method with two arguments: a query string containing format specifiers, and a sequence containing the values to be bound to the query string. The following query uses placeholders to search for records where the number of cats is less than 2 and the favorite color is green: try: cursor = conn.cursor ( ) cursor.execute ("SELECT * FROM profile WHERE cats < %s AND color = %s", \ (2, "green")) for row in cursor.fetchall ( ): print row print "%d rows were returned" % cursor.rowcount cursor.close ( ) except MySQLdb.Error, e: print "Oops, the query failed" print e If you have only a single value val to bind to a placeholder, you can write it as a sequence using the syntax (val,). The following UPDATE statement demonstrates this: try: cursor = conn.cursor ( ) cursor.execute ("UPDATE profile SET cats = cats+1 WHERE name = %s", \ ("Fred",)) print "%d rows were updated" % cursor.rowcount except MySQLdb.Error, e: print "Oops, the query failed" print e Some of the Python DB-API driver modules support several format specifiers (such as %d for integers and %f for floating-point numbers). With MySQLdb, you should use a placeholder of %s to format all data values as strings. MySQL will perform type conversion as necessary. If you want to place a literal % character into the query, use %% in the query string. Python's placeholder mechanism provides quotes around data values as necessary when they are bound to the query string, so you need not add them yourself. 2.7.7 Java JDBC provides support for placeholders if you use prepared statements rather than regular statements. Recall that the process for issuing regular statements is to create a Statement object and then pass the query string to one of the query-issuing functions executeUpdate( ), executeQuery( ), or execute( ). To use a prepared statement instead, create a PreparedStatement object by passing a query string containing ? placeholder characters to your connection object's prepareStatement( ) method. Then bind your data values to the statement using setXXX( ) methods. Finally, execute the statement by calling executeUpdate( ), executeQuery( ), or execute( ) with an empty argument list. Here is an example that uses executeUpdate( ) to issue a DELETE query: PreparedStatement s; int count; s = conn.prepareStatement ("DELETE FROM profile WHERE cats = ?"); s.setInt (1, 2); // bind a 2 to the first placeholder count = s.executeUpdate ( ); s.close ( ); // close statement System.out.println (count + " rows were deleted"); For a query that returns a result set, the process is similar, but you use executeQuery( ) instead: PreparedStatement s; s = conn.prepareStatement ("SELECT id, name, cats FROM profile" + " WHERE cats < ? AND color = ?"); s.setInt (1, 2); // bind 2 and "green" to first and second placeholders s.setString (2, "green"); s.executeQuery ( ); // ... process result set here ... s.close ( ); // close statement The setXXX( ) methods that bind data values to queries take two arguments: a placeholder position (beginning with 1, not 0) and the value to be bound to the placeholder. The type of the value should match the type in the setXXX( ) method name. For example, you should pass an integer value to setInt( ), not a string. Placeholder characters need no surrounding quotes in the query string. JDBC supplies quotes as necessary when it binds values to the placeholders. 2.8 Including Special Characters and NULL Values in Queries 2.8.1 Problem You've having trouble constructing queries that include data values containing special characters such as quotes or backslashes, or special values such as NULL. 2.8.2 Solution Use your API's placeholder mechanism or quoting function. 2.8.3 Discussion Up to this point, our queries have used "safe" data values requiring no special treatment. This section describes how to construct queries when you're using values that contain special characters such as quotes, backslashes, binary data, or values that are NULL. The difficulty with such values is as follows. Suppose you have the following INSERT query: INSERT INTO profile (name,birth,color,foods,cats) VALUES('Alison','1973-01-12','blue','eggroll',4); There's nothing unusual about that. But if you change the name column value to something like De'Mont that contains a single quote, the query becomes syntactically invalid: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De'Mont','1973-01-12','blue','eggroll',4); The problem is that there is a single quote inside a single-quoted string. To make the query legal, the quote could be escaped by preceding it either with a single quote or with a backslash: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De''Mont','1973-01-12','blue','eggroll',4); INSERT INTO profile (name,birth,color,foods,cats) VALUES('De\'Mont','1973-01-12','blue','eggroll',4); Alternatively, you could quote the name value itself within double quotes rather than within single quotes: INSERT INTO profile (name,birth,color,foods,cats) VALUES("De'Mont",'1973-01-12','blue','eggroll',4); Naturally, if you are writing a query literally in your program, you can escape or quote the name value by hand because you know what the value is. But if you're using a variable to provide the name value, you don't necessarily know what the variable's value is. Worse yet, single quote isn't the only character you must be prepared to deal with; double quotes and backslashes cause problems, too. And if you want to store binary data such as images or sound clips in your database, such values might contain anything—not just quotes or backslashes, but other characters such as nulls (zero-valued bytes). The need to handle special characters properly is particularly acute in a web environment where queries are constructed using form input (for example, if you're searching for records that match search terms entered by the remote user). You must be able to handle any kind of input in a general way, because you can't predict in advance what kind of information people will supply. In fact, it is not uncommon for malicious users to enter garbage values containing problematic characters in a deliberate attempt to break your scripts. The SQL NULL value is not a special character, but it too requires special treatment. In SQL, NULL indicates "no value." This can have several meanings depending on context, such as "unknown," "missing," "out of range," and so forth. Our queries thus far have not used NULL values, to avoid dealing with the complications that they introduce, but now it's time to address these issues. For example, if you don't know De'Mont's favorite color, you can set the color column to NULL—but not by writing the query like this: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De''Mont','1973-01-12','NULL','eggroll',4); Instead, the NULL value shouldn't have any surrounding quotes at all: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De''Mont','1973-01-12',NULL,'eggroll',4); If you were writing the query literally in your program, you'd simply write the word "NULL" without surrounding quotes. But if the color value comes from a variable, the proper action is not so obvious. You must know something about the variable's value to be able to determine whether or not to surround it with quotes when you construct the query. There are two general means at your disposal for dealing with special characters such as quotes and backslashes, and with special values such as NULL: · Use placeholders if your API supports them. Generally, this is the preferred method, because the API itself will do all or most of the work for you of providing quotes around values as necessary, quoting or escaping special characters within the data value, and possibly interpreting a special value to map onto NULL without surrounding quotes. Recipe 2.7 provides general background on placeholder support; you should read that section if you haven't already. · Use a quoting function if your API provides one for converting data values to a safe form that is suitable for use in query strings. The remainder of this section shows how to handle special characters for each API. The examples demonstrate how to insert a profile table record that contains De'Mont for the name value and NULL for the color value. The techniques shown work generally to handle any special characters, including those found in binary data. (The techniques are not limited to INSERT queries. They work for other kinds of statements as well, such as SELECT queries.) Examples showing specifically how to work with a particular kind of binary data—images—are provided in Chapter 17. A related issue not covered here is the inverse operation of transforming special characters in values returned from your database for display in various contexts. For example, if you're generating HTML pages that include values taken from your database, you have to convert < and > characters in those values to the HTML entities < and > to make sure they display properly. This topic is discussed in Chapter 16. 2.8.4 Perl DBI supports a placeholder mechanism for binding data values to queries, as discussed in Recipe 2.7. Using this mechanism, we can add the profile record for De'Mont by using do( ): my $count = $dbh->do ("INSERT INTO profile (name,birth,color,foods,cats) VALUES(?,?,?,?,?)", undef, "De'Mont", "1973-01-12", undef, "eggroll", 4); Alternatively, use prepare( ) plus execute( ): my $sth = $dbh->prepare ("INSERT INTO profile (name,birth,color,foods,cats) VALUES(?,?,?,?,?)"); my $count = $sth->execute ("De'Mont", "1973-01-12", undef, "eggroll", 4); In either case, the resulting query generated by DBI is as follows: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De\'Mont','1973-01-12',NULL,'eggroll','4') Note how DBI adds quotes around data values, even though there were none around the ? placeholder characters in the original query string. (The placeholder mechanism adds quotes around numeric values, too, but that's okay, because the MySQL server performs type conversion as necessary to convert strings to numbers.) Also note the DBI convention that when you bind undef to a placeholder, DBI puts a NULL into the query and correctly refrains from adding surrounding quotes. DBI also provides a quote( ) method as an alternative to using placeholders. quote( ) is a database handle method, so you must have a connection open to the server before you can use it. (This is because the proper quoting rules cannot be selected until the driver is known; some databases have different quoting rules than others.) Here's how to use quote( ) to create a query string for inserting a new record in the profile table: my $stmt = sprintf ( "INSERT INTO profile (name,birth,color,foods,cats) VALUES(%s,%s,%s,%s,%s)", $dbh->quote ("De'Mont"), $dbh->quote ("1973-01-12"), $dbh->quote (undef), $dbh->quote ("eggroll"), $dbh->quote (4)); my $count = $dbh->do ($stmt); The query string generated by this code is the same as when you use placeholders. The %s format specifiers are written without surrounding quotes because quote( ) provides them automatically as necessary: undef values are inserted as NULL without quotes, and non- undef values are inserted with quotes. 2.8.5 PHP PHP has no placeholder capability, but does provide an addslashes( ) function that you can use to make values safe for insertion into query strings. addslashes( ) escapes special characters such as quotes and backslashes, but does not add surrounding quotes around values; you must add them yourself. We also need a convention for specifying NULL values; let's try using unset( ) to force a variable to have "no value" (somewhat like Perl's undef value). Here is some PHP code for adding De'Mont's profile table record: unset ($null); # create a "null" value $stmt = sprintf (" INSERT INTO profile (name,birth,color,foods,cats) VALUES('%s','%s','%s','%s','%s')", addslashes ("De'Mont"), addslashes ("1973-01-12"), addslashes ($null), addslashes ("eggroll"), addslashes (4)); $result_id = mysql_query ($stmt, $conn_id); In the example, the %s format specifiers in the query string are surrounded with quotes because addslashes( ) doesn't provide them. Unfortunately, the resulting query string looks like this, which isn't quite correct: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De\'Mont','1973-01-12','','eggroll','4') The quote in the name field has been escaped properly, but the "null" (unset) value we passed for the color column turned into an empty string, not NULL. Let's fix this by writing a helper function sql_quote( ) to use in place of addslashes( ). sql_quote( ) is similar to addslashes( ), but returns NULL (without surrounding quotes) for unset values and adds quotes around the value otherwise. Here's what it looks like: function sql_quote ($str) { return (isset ($str) ? "'" . addslashes ($str) . "'" : "NULL"); } Because sql_quote( ) itself adds quote characters around the data value if they're needed, we can remove the quotes that surround the %s format specifiers in the query string and generate the INSERT statement like this: unset ($null); # create a "null" value $stmt = sprintf (" INSERT INTO profile (name,birth,color,foods,cats) VALUES(%s,%s,%s,%s,%s)", sql_quote ("De'Mont"), sql_quote ("1973-01-12"), sql_quote ($null), sql_quote ("eggroll"), sql_quote (4)); $result_id = mysql_query ($stmt, $conn_id); After making the preceding changes, the value of $stmt includes a properly unquoted NULL value: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De\'Mont','1973-01-12',NULL,'eggroll','4') If you're using PHP 4, you have some additional options for handling NULL values and special characters. First, PHP 4 has a special value NULL that is like an unset value, so you could use that in place of $null in the preceding code that generated the INSERT statement. (However, to write code that works for both PHP 3 and PHP 4, use an unset variable such as $null.) Second, as of PHP 4.0.3, an alternative to addslashes( ) is to use mysql_escape_string( ), which is based on the function of the same name in the MySQL C API. For example, you could rewrite sql_quote( ) to use mysql_escape_string( ) like this: function sql_quote ($str) { return (isset ($str) ? "'" . mysql_escape_string ($str) . "'" : "NULL"); } If you want a version that uses mysql_escape_string( ) if it's present and falls back to addslashes( ) otherwise, write sql_quote( ) like this: function sql_quote ($str) { if (!isset ($str)) return ("NULL"); $func = function_exists ("mysql_escape_string") ? "mysql_escape_string" : "addslashes"; return ("'" . $func ($str) . "'"); } Whichever version of sql_quote( ) you use, it's the kind of routine that is a good candidate for inclusion in a library file. I'll assume its availability for PHP scripts in the rest of this book. You can find it as part of the Cookbook_Utils.php file in the lib directory of the recipes distribution. To use the file, install it in the same location where you put Cookbook.php and reference it from scripts like this: include "Cookbook_Utils.php"; 2.8.6 Python Python provides a placeholder mechanism that you can use for handling special characters in data values, as described in Recipe 2.7. To add the profile table record for De'Mont, the code looks like this: try: cursor = conn.cursor ( ) cursor.execute (""" INSERT INTO profile (name,birth,color,foods,cats) VALUES(%s,%s,%s,%s,%s) """, ("De'Mont", "1973-01-12", None, "eggroll", 4)) print "%d row was inserted" % cursor.rowcount except: print "Oops, the query failed" The parameter binding mechanism adds quotes around data values where necessary. DB-API treats None as logically equivalent to the SQL NULL value, so you can bind None to a placeholder to produce a NULL in the query string. The query that is sent to the server by the preceding execute( ) call looks like this: INSERT INTO profile (name,birth,color,foods,cats) VALUES('De\'Mont','1973-01-12',NULL,'eggroll',4) With MySQLdb 0.9.1 or newer, an alternative method of quoting data values is to use the literal( ) method. To produce the INSERT statement for De'Mont by using literal( ), do this: try: cursor = conn.cursor ( ) str = """ INSERT INTO profile (name,birth,color,foods,cats) VALUES(%s,%s,%s,%s,%s) """ % \ (conn.literal ("De'Mont"), \ conn.literal ("1973-01-12"), \ conn.literal (None), \ conn.literal ("eggroll"), \ conn.literal (4)) cursor.execute (str) print "%d row was inserted" % cursor.rowcount except: print "Oops, the query failed" 2.8.7 Java Java provides a placeholder mechanism that you can use to handle special characters in data values, as described in Recipe 2.7. To add the profile table record for De'Mont, create a prepared statement, bind the data values to it, then execute the statement: PreparedStatement s; int count; s = conn.prepareStatement ( "INSERT INTO profile (name,birth,color,foods,cats)" + " VALUES(?,?,?,?,?)"); s.setString (1, "De'Mont"); s.setString (2, "1973-01-12"); s.setNull (3, java.sql.Types.CHAR); s.setString (4, "eggroll"); s.setInt (5, 4); count = s.executeUpdate ( ); s.close ( ); // close statement Each value-binding call here is chosen to match the data type of the column to which the value is bound: setString( ) to bind a string to the name column, setInt( ) to bind an integer to the cats column, and so forth. (Actually, I cheated a bit by using setString( ) to treat the date value for birth as a string.) The setXXX( ) calls add quotes around data values if necessary, so no quotes are needed around the ? placeholder characters in the query string. One difference between JDBC and the other APIs is that you don't specify a special value to bind a NULL to a placeholder by specifying some special value (such as undef in Perl or None in Python). Instead, you invoke a special method setNull( ), where the second argument indicates the type of the column (java.sql.Types.CHAR for a string, java.sql.Types.INTEGER for an integer, etc.). To achieve some uniformity in the value-binding calls, a helper function bindParam( ) can be defined that takes a Statement object, a placeholder position, and a data value. This allows the same function to be used to bind any data value. We can even use the convention that passing the Java null value binds a SQL NULL to the query. After rewriting the previous example to use bindParam( ), it looks like this: PreparedStatement s; int count; s = conn.prepareStatement ( "INSERT INTO profile (name,birth,color,foods,cats)" + " VALUES(?,?,?,?,?)"); bindParam (s, 1, "De'Mont"); bindParam (s, 2, "1973-01-12"); bindParam (s, 3, null); bindParam (s, 4, "eggroll"); bindParam (s, 5, 4); count = s.executeUpdate ( ); s.close ( ); // close statement The implementation of bindParam( ) requires multiple functions, because the third argument can be of different types, so we need one function for each type. The following code shows versions that handle integer and string data values (the string version handles null and binds it to NULL): public static void bindParam (PreparedStatement s, int pos, int val) { try { s.setInt (pos, val); } catch (Exception e) { /* catch and ignore */ } } public static void bindParam (PreparedStatement s, int pos, String val) { try { if (val == null) s.setNull (pos, java.sql.Types.CHAR); else s.setString (pos, val); } catch (Exception e) { /* catch and ignore */ } } To handle additional data types, you'd write other versions of bindParam( ) that accept arguments of the appropriate type. Special Characters in Database, Table, and Column Names In MySQL versions 3.23.6 and later, you can quote database, table, and column names by surrounding them with backquotes. This allows you to include characters in such names that normally would be illegal. For example, spaces in names are not allowed by default: mysql> CREATE TABLE my table (i INT); ERROR 1064 at line 1: You have an error in your SQL syntax near 'table (i INT)' at line 1 To include the space, protect the name with backquotes: mysql> CREATE TABLE `my table` (i INT); Query OK, 0 rows affected (0.04 sec) The backquote mechanism gives you wider latitude in choosing names, but makes it more difficult to write programs correctly. (When you actually use a backquoted name, you must remember to include the backquotes every time you refer to it.) Because of this additional bit of complexity, I prefer to avoid using such names, and I recommend that you don't use them, either. If you want to ignore that advice, a strategy you may find helpful in this situation is to define a variable that holds the name (including backquotes) and then use the variable whenever you need to refer to the name. For example, in Perl, you can do this: $tbl_name = "`my table`"; $dbh->do ("DELETE FROM $tbl_name"); 2.9 Handling NULL Values in Result Sets 2.9.1 Problem A query result includes NULL values, but you're not sure how to tell where they are. 2.9.2 Solution Your API probably has some value that represents NULL by convention. You just have to know what it is and how to test for it. 2.9.3 Discussion Recipe 2.9 described how to refer to NULL values when you send queries to the database. In this section, we'll deal instead with the question of how to recognize and process NULL values that are returned from the database. In general, this is a matter of knowing what special value the API maps NULL values onto, or what function to call. These values are shown in the following table: Language NULL-detection value or function Perl undef PHP an unset value Python None Java wasNull( ) The following sections show a very simple application of NULL value detection. The examples retrieve a result set and print all values in it, mapping NULL values onto the printable string "NULL". To make sure the profile table has a row that contains some NULL values, use mysql to issue the following INSERT statement, then issue the SELECT query to verify that the resulting row has the expected values: mysql> INSERT INTO profile (name) VALUES('Juan'); mysql> SELECT * FROM profile WHERE name = 'Juan'; +----+------+-------+-------+-------+------+ | id | name | birth | color | foods | cats | +----+------+-------+-------+-------+------+ | 11 | Juan | NULL | NULL | NULL | NULL | +----+------+-------+-------+-------+------+ The id column might contain a different number, but the other columns should appear as shown. 2.9.4 Perl In Perl DBI scripts, NULL is represented by undef. It's easy to detect such values using the defined( ) function, and it's particularly important to do so if you use the -w option on the #! line that begins your script. Otherwise, accessing undef values causes Perl to issue the following complaint: Use of uninitialized value To avoid this warning, test column values that might be undef with defined( ) before using them. The following code selects a few columns from the profile column and prints "NULL" for any undefined values in each row. This makes NULL values explicit in the output without activating any warning messages: my $sth = $dbh->prepare ("SELECT name, birth, foods FROM profile"); $sth->execute ( ); while (my $ref = $sth->fetchrow_hashref ( )) { printf "name: %s, birth: %s, foods: %s\n", defined ($ref->{name}) ? $ref->{name} : "NULL", defined ($ref->{birth}) ? $ref->{birth} : "NULL", defined ($ref->{foods}) ? $ref->{foods} : "NULL"; } Unfortunately, all that testing of column values is ponderous, and becomes worse the more columns there are. To avoid this, you can test and set undefined values in a loop prior to printing them. Then the amount of code to perform the tests is constant, not proportional to the number of columns to be tested. The loop also makes no reference to specific column names, so it can be copied and pasted to other programs more easily, or used as the basis for a utility routine: my $sth = $dbh->prepare ("SELECT name, birth, foods FROM profile"); $sth->execute ( ); while (my $ref = $sth->fetchrow_hashref ( )) { foreach my $key (keys (%{$ref})) { $ref->{$key} = "NULL" unless defined ($ref->{$key}); } printf "name: %s, birth: %s, foods: %s\n", $ref->{name}, $ref->{birth}, $ref->{foods}; } If you fetch rows into an array rather than into a hash, you can use map( ) to convert any undef values: my $sth = $dbh->prepare ("SELECT name, birth, foods FROM profile"); $sth->execute ( ); while (my @val = $sth->fetchrow_array ( )) { @val = map { defined ($_) ? $_ : "NULL" } @val; printf "name: %s, birth: %s, foods: %s\n", $val[0], $val[1], $val[2]; } 2.9.5 PHP PHP represents NULL values in result sets as unset values, so you can use the isset( ) function to detect NULL values in query results. The following code shows how to do this: $result_id = mysql_query ("SELECT name, birth, foods FROM profile", $conn_id); if (!$result_id) die ("Oops, the query failed\n"); while ($row = mysql_fetch_row ($result_id)) { while (list ($key, $value) = each ($row)) { if (!isset ($row[$key])) # test for unset value $row[$key] = "NULL"; } print ("name: $row[0], birth: $row[1], foods: $row[2]\n"); } mysql_free_result ($result_id); PHP 4 has a special value NULL that is like an unset value. If you can assume your scripts will run under PHP 4, you can test for NULL values like this: if ($row[$key] === NULL) # test for PHP NULL value $row[$key] = "NULL"; Note the use of the === "triple-equal" operator, which in PHP 4 means "exactly equal to." The usual == "equal to" comparison operator is not suitable here; with ==, the PHP NULL value, the empty string, and 0 all compare equal to each other. 2.9.6 Python Python DB-API programs represent NULL values in result sets using None. The following example shows how to detect NULL values: try: cursor = conn.cursor ( ) cursor.execute ("SELECT name, birth, foods FROM profile") for row in cursor.fetchall ( ): row = list (row) # convert non-mutable tuple to mutable list for i in range (0, len (row)): if row[i] == None: # is the column value NULL? row[i] = "NULL" print "name: %s, birth: %s, foods: %s" % (row[0], row[1], row[2]) cursor.close ( ) except: print "Oops, the query failed" The inner loop checks for NULL column values by looking for None and converts them to the string "NULL". Note how the example converts row to a mutable object prior to the loop; that is done because fetchall( ) returns rows as sequence values, which are non-mutable (read-only). 2.9.7 Java For JDBC programs, if it's possible for a column in a result set to contain NULL values, it's best to check for them explicitly. The way to do this is to fetch the value and then invoke wasNull( ), which returns true if the column is NULL and false otherwise. For example: Object obj = rs.getObject (index); if (rs.wasNull ( )) { /* the value's a NULL */ } The preceding example uses getObject( ), but the principle holds for other getXXX( ) calls as well. Here's an example that prints each row of a result set as a comma-separated list of values, with each NULL value printed as the string "NULL": Statement s = conn.createStatement ( ); s.executeQuery ("SELECT name, birth, foods FROM profile"); ResultSet rs = s.getResultSet ( ); ResultSetMetaData md = rs.getMetaData ( ); int ncols = md.getColumnCount ( ); while (rs.next ( )) // loop through rows of result set { for (int i = 0; i < ncols; i++) // loop through columns { String val = rs.getString (i+1); if (i > 0) System.out.print (", "); if (rs.wasNull ( )) System.out.print ("NULL"); else System.out.print (val); } System.out.println ( ); } rs.close ( ); // close result set s.close ( ); // close statement 2.10 Writing an Object-Oriented MySQL Interface for PHP 2.10.1 Problem You want an approach for writing PHP scripts that is less tied to PHP's native MySQL-specific functions. 2.10.2 Solution Use one of the abstract interfaces that are available, or write your own. 2.10.3 Discussion You may have noticed that the Perl, Python, and Java operations that connect to the MySQL server each return a value that allows you to process queries in an object-oriented manner. Perl has database and statement handles, Python has connection and cursor objects, and Java uses objects for everything in sight: connections, statements, result sets, and metadata. These object-oriented interfaces all are based on a two-level architecture. The top level of this architecture provides database-independent methods that implement database access in a portable way that's the same no matter which database management system you're using, be it MySQL, PostgreSQL, Oracle, or whatever. The lower level consists of a set of drivers, each of which implements the details for a particular database system. The two-level architecture allows application programs to use an abstract interface that is not tied to the details involved with accessing any particular database server. This enhances portability of your programs, because you just select a different lower-level driver to use a different type of database. That's the theory, at least. In practice, perfect portability can be somewhat elusive: · The interface methods provided by the top level of the architecture are consistent regardless of the driver you use, but it's still possible to issue SQL statements that contain constructs supported only by a particular server. For MySQL, a good example is the SHOW statement that provides information about database and table structure. If you use SHOW with a non-MySQL server, an error is the likely result. · Lower-level drivers often extend the abstract interface to make it more convenient to get at database-specific features. For example, the MySQL driver for DBI makes the most recent AUTO_INCREMENT value available as an attribute of the database handle so that you can access it as $dbh->{mysql_insertid}. These features often make it easier to write a program initially, but at the same time make it less portable and require some rewriting should you port the program for use with another database system. Despite these factors that compromise portability, the two-level architecture provides significant benefits for Perl, Python, and Java programmers. It would be nice to use this approach when writing PHP scripts, too, but PHP itself provides no such support. Its interface to MySQL consists of a set of functions, and these are inherently non-portable because their names all are of the form mysql_xxx( ). To work around this, you can write your own database abstraction mechanism. That is the purpose of this section. It shows how to write an object-oriented PHP interface that hides many MySQL-specific details and is relatively database independent—certainly more so than PHP's function-based MySQL interface. As discussed here, the interface is written specifically for MySQL, but if you want to adapt it for use with a different database, you should be able to do so by supplying a different set of underlying class methods. If you want to write PHP scripts in a database-independent fashion, but prefer not to write your own interface, you can use a third-party abstraction interface. One such is the database- access class that is a part of the PHP Extension and Add-on Repository (PEAR). PEAR is included with current releases of PHP 4. The following discussion shows how to write a MySQL_Access class that implements an object-oriented interface to MySQL, and a Cookbook_DB_Access class that is built on top of MySQL_Access but automatically supplies default values for connecting to the cookbook database. (If you're not familiar with PHP classes, you may want to consult the "Classes and Objects" chapter of the PHP manual for background information.) The primary goal of this class interface is to make it easier to use MySQL by reducing the number of operations your scripts must perform explicitly: · The interface automatically establishes a connection to the MySQL server if you issue a query without connecting first; you need never issue a connect call explicitly. The connection parameters must be specified somehow, of course, but as we'll see, that can be done automatically as well. · The interface provides automatic error checking for MySQL calls. This is more convenient than checking for them yourself, and helps eliminate one of the most common problems with PHP scripts: failure to check for database errors on a consistent basis. The default behavior is to exit with an error message when a problem occurs, but you can override that if you want to handle errors yourself. · When you reach the end of a result set while fetching rows, the class automatically releases the set. The class-based interface also provides a method for quoting data values to make them safe for use in queries, and a placeholder mechanism so you don't need to do any quoting at all if you don't want to. These capabilities are not present in PHP's native function-based interface. The following example illustrates how using an object-oriented interface changes the way you write PHP scripts to access MySQL, compared to writing function-based scripts. A script based on PHP's native function calls typically accesses MySQL something like this: if (!($conn_id = mysql_connect ("localhost", "cbuser", "cbpass"))) die ("Cannot connect to database\n"); if (!mysql_select_db ("cookbook", $conn_id)) die ("Cannot select database\n"); $query = "UPDATE profile SET cats=cats+1 WHERE name = 'Fred'"; $result_id = mysql_query ($query, $conn_id); if (!$result_id) die (mysql_error ($conn_id)); print (mysql_affected_rows ($conn_id) . " rows were updated\n"); $query = "SELECT id, name, cats FROM profile"; $result_id = mysql_query ($query, $conn_id); if (!$result_id) die (mysql_error ($conn_id)); while ($row = mysql_fetch_row ($result_id)) print ("id: $row[0], name: $row[1], cats: $row[2]\n"); mysql_free_result ($result_id); A first step toward eliminating some of that code is to replace the first few lines by calling the cookbook_connect( ) function from the PHP library file, Cookbook.php, developed in Recipe 2.4. That function encapsulates the connection and database selection operations: include "Cookbook.php"; $conn_id = cookbook_connect ( ); $query = "UPDATE profile SET cats=cats+1 WHERE name = 'Fred'"; $result_id = mysql_query ($query, $conn_id); if (!$result_id) die (mysql_error ($conn_id)); print (mysql_affected_rows ($conn_id) . " rows were updated\n"); $query = "SELECT id, name, cats FROM profile"; $result_id = mysql_query ($query, $conn_id); if (!$result_id) die (mysql_error ($conn_id)); while ($row = mysql_fetch_row ($result_id)) print ("id: $row[0], name: $row[1], cats: $row[2]\n"); mysql_free_result ($result_id); A class-based interface can carry encapsulation further and shorten the script even more by eliminating the need to connect explicitly, to check for errors, or to close the result set. All of that can be handled automatically: include "Cookbook_DB_Access.php"; $conn = new Cookbook_DB_Access; $query = "UPDATE profile SET cats=cats+1 WHERE name = 'Fred'"; $conn->issue_query ($query); print ($conn->num_rows . " rows were updated\n"); $query = "SELECT id, name, cats FROM profile"; $conn->issue_query ($query); while ($row = $conn->fetch_row ( )) print ("id: $row[0], name: $row[1], cats: $row[2]\n"); A class interface can make MySQL easier to use by reducing the amount of code you need to write when creating new scripts, but it has other benefits as well. For example, it can also serve as a recipe translation aid. Suppose a program in a later chapter is shown in Perl, but you'd rather use in it PHP and there is no PHP version on the Cookbook web site. Perl DBI is object oriented, so you'll likely find it easier to translate a Perl script into a PHP script that is object oriented, rather than into one that is function based. 2.10.4 Class Overview The class interface implementation uses the PHP recipes and techniques developed earlier in this chapter, so you should familiarize yourself with those. For example, the class interface needs to know how to make connections to the server and process queries, and we'll use include (library) files to encapsulate the interface so that it can be used easily from multiple PHP scripts. The interface shown here works only with PHP 4. This is something that is not true of PHP's native MySQL routines, which work both with PHP 3 and PHP 4. The restriction is necessitated by the use of a few constructs that are not available or do not work properly in PHP 3. Specifically, the interface assumes the availability of the include_once statement and the PHP NULL value. It also assumes that count( ) correctly counts unset values in arrays, which is true only for PHP 4. The implementation strategy involves two classes. The first is a generic base class MySQL_Access that provides the variables and methods needed for using MySQL. The second is a derived class Cookbook_DB_Access that has access to everything in the base class but automatically sets up connection parameters specifically for the cookbook database so we don't have to do that ourselves. An alternative implementation might use just a single class and hardwire the cookbook database parameters directly into it. However, writing the base class to be generic allows it to be used more easily for scripts that access a database other than cookbook. (For such scripts, you'd just write another derived class that uses the base class but provides a different set of connection parameters.) A PHP class definition begins with a class line that specifies the class name, then defines the variables and methods associated with the class. An outline of the base class, MySQL_Access, looks like this: class MySQL_Access { var $host_name = ""; var $user_name = ""; var $password = ""; var $db_name = ""; var $conn_id = 0; var $errno = 0; var $errstr = ""; var $halt_on_error = 1; var $query_pieces = array ( ); var $result_id = 0; var $num_rows = 0; var $row = array ( ); # ... method definitions ... } # end MySQL_Access The class definition begins with several variables that are used as follows: · The first few variables hold the parameters for connecting to the MySQL server ($host_name, $user_name, $password, and $db_name). These are empty initially and must be set before attempting a connection. · Once a connection is made, the connection identifier is stored in $conn_id. Its initial value, 0, means "no connection." This allows a class instance to determine whether or not it has connected to the database server yet. · $errno and $errstr hold error information; the class sets them after each MySQL operation to indicate the success or failure of the operation. The initial values, and the empty string, mean "no error." For errors that occur but not as a result of interacting with the server, $errno is set to -1, which is a nonzero error value never used by MySQL. This can happen, for example, if you use placeholder characters in a query string but don't provide the correct number of data values when you bind them to the placeholders. In that case, the class detects the error without sending anything to the server. · $halt_on_error determines whether or not to terminate script execution when an error occurs. The default is to do so. Scripts that want to perform their own error- checking can set this to zero. · $query_pieces is used to hold a query string for prepared statements and parameter binding. (I'll explain later why this variable is an array.) · $result_id, $num_rows, and $row are used during result set processing to hold the result set identifier, the number of rows changed by or returned by the query, and the current row of the result set. PHP Class Constructor Functions In PHP, you can designate a constructor function in a class definition to be called automatically when new class instances are created. This is done by giving the function the same name as the class. You might do this, for example, if you need to initialize an object's variables to non-constant values. (In PHP 4, object variables can only take constant initializers.) The MySQL_Access class has no constructor because its variables all have constant initial values. The "method definitions" line near the end of the class outline is where we'll put the functions that connect to the MySQL server, check for errors, issue queries, and so forth. We'll fill in that part shortly, but before doing so, let's get a sense of how the class can be used. We can put the code for the class in an include file, MySQL_Access.php, and install it in a directory that PHP searches when looking for include files (for example, /usr/local/apache/lib/php, as described in Recipe 2.4.) Then we can use the file by referencing it with an include statement, creating an instance of the class to get a connection object $conn, and setting up the connection parameters for that object: include "MySQL_Access.php"; # include the MySQL_Access class $conn = new MySQL_Access; # create new class object $conn->host_name = "localhost"; # initialize connection parameters $conn->db_name = "cookbook"; $conn->user_name = "cbuser"; $conn->password = "cbpass"; However, using the class this way wouldn't really make it very convenient to connect to the server, due to the need to write all those assignment statements that set the connection parameters. Here's where a derived class that uses the base class comes in handy, because the derived class can be written to set the parameters automatically. To that end, let's create a class, Cookbook_DB_Access, that extends MySQL_Access by supplying parameters for connecting to the cookbook database. Then you can write scripts that prepare to access the cookbook database with just two lines of code: include "Cookbook_DB_Access.php"; $conn = new Cookbook_DB_Access; The implementation of Cookbook_DB_Access is quite simple. Create a file, Cookbook_DB_Access.php, that looks like this: include_once "MySQL_Access.php"; class Cookbook_DB_Access extends MySQL_Access { # override default class variable values var $host_name = "localhost"; var $user_name = "cbuser"; var $password = "cbpass"; var $db_name = "cookbook"; } The class line names the class, Cookbook_DB_Access, and the extends clause indicates that it's based on the MySQL_Access class. Extending a class this way is called subclassing the base class, or creating a derived class from the base class. The new class definition is almost trivial, containing only variable assignments for connection parameters. These override the (empty) values that are supplied by the base class. The effect is that when you create an instance of the Cookbook_DB_Access class, you get an object that's just like a MySQL_Access object, except that the connection parameters are set automatically for connecting to the cookbook database. Now you can see more clearly why we left the connection parameters in the MySQL_Access class empty rather than setting them for accessing the cookbook database. By leaving them blank, we create a more generic class that can be extended for any number of databases by creating different derived classes. Cookbook_DB_Access is one such class. If you're writing a set of scripts that use a different database, derive another extended class that supplies appropriate connection parameters for that database. Then have the scripts use the second extended class rather than Cookbook_DB_Access.php. Incidentally, the reason that Cookbook_DB_Access.php includes MySQL_Access.php is so that you don't need to. When your scripts include Cookbook_DB_Access.php, they get MySQL_Access.php "for free." The include_once statement is used rather than include to prevent duplicate-definition problems from occurring if your scripts happen to include MySQL_Access.php anyway. 2.10.5 Connecting and Disconnecting Now we need to write the methods of the base class, MySQL_Access, that interact with MySQL. These go in the MySQL_Access.php source file. First, we need a connect( ) method that sets up a connection to the MySQL server: function connect ( ) { $this->errno = 0; # clear the error variables $this->errstr = ""; if ($this->conn_id == 0) # connect if not already connected { $this->conn_id = @mysql_connect ($this->host_name, $this->user_name, $this->password); # use mysql_errno( )/mysql_error( ) if they work for # connection errors; use $php_errormsg otherwise if (!$this->conn_id) { # mysql_errno( ) returns nonzero if it's # functional for connection errors if (mysql_errno ( )) { $this->errno = mysql_errno ( ); $this->errstr = mysql_error ( ); } else { $this->errno = -1; # use alternate values $this->errstr = $php_errormsg; } $this->error ("Cannot connect to server"); return (FALSE); } # select database if one has been specified if (isset ($this->db_name) && $this->db_name != "") { if (!@mysql_select_db ($this->db_name, $this->conn_id)) { $this->errno = mysql_errno ( ); $this->errstr = mysql_error ( ); $this->error ("Cannot select database"); return (FALSE); } } } return ($this->conn_id); } The connect( ) method checks for an existing connection and attempts to establish one only if it hasn't already done so. connect( ) does this so other class methods that require a connection can call this method to make sure there is one. Specifically, we can write the query-issuing method to call connect( ) before sending a query. That way, all a script has to do is create a class object and start issuing queries; the class methods automatically take care of making the connection for us. By writing the class this way, it becomes unnecessary for scripts that use the class ever to establish a connection explicitly. For a successful connection attempt, or if a connection is already in place, connect( ) returns the connection identifier (a non-FALSE value). If an error occurs, connect( ) calls error( ) and one of two things can happen: · If $halt_on_error is set, error( ) prints a message and terminates the script. · Otherwise, error( ) does nothing and returns to connect( ), which returns FALSE. Note that if a connection failure occurs, connect( ) tries to use mysql_errno( ) and mysql_error( ) if they are the versions provided in PHP 4.0.6 and up that return usable information for mysql_connect( ) errors (see Recipe 2.3). Otherwise, it sets $errno to -1 and $errstr to $php_errormsg. There is also a disconnect( ) method corresponding to connect( ) in case you want to disconnect explicitly. (Otherwise, PHP closes the connection for you when your script exits.) The method calls mysql_close( ) if a connection is open: function disconnect ( ) { if ($this->conn_id != 0) # there's a connection open; close it { mysql_close ($this->conn_id); $this->conn_id = 0; } return (TRUE); } 2.10.6 Error Handling MySQL_Access methods handle errors by calling the error( ) method. The behavior of this method depends on the value of the $halt_on_error variable. If $halt_on_error is true (nonzero), error( ) prints an error message and exits. This is the default behavior, which means you never need to check for errors if you don't want to. If you disable $halt_on_error by setting it to zero, error( ) simply returns to its caller, which then can pass back an error return status to its own caller. Thus, error-handling code within MySQL_Access typically looks like this: if (some error occurred) { $this->error ("some error occurred"); return (FALSE); } If $halt_on_error is enabled when an error occurs, error( ) is invoked and terminates the script. Otherwise, it returns and the return( ) statement that follows it is executed. To write code that does its own error checking, disable $halt_on_error. In that case, you may also want to access the $errno and $errstr variables, which hold the MySQL numeric error code and descriptive text message. The following example shows how to disable $halt_on_error for the duration of a single operation: $conn->halt_on_error = 0; print ("Test of error-trapping:\n"); if (!$conn->issue_query ($query_str)) print ("Hey, error $conn->errno occurred: $conn->errstr\n"); $conn->halt_on_error = 1; When error( ) prints a message, it also displays the values of the error variables if $errno is nonzero. error( ) converts the message to properly escaped HTML, on the assumption that the class will be used in a web environment: function error ($msg) { if (!$this->halt_on_error) # return silently return; $msg .= "\n"; if ($this->errno) # if an error code is known, include error info $msg .= sprintf ("Error: %s (%d)\n", $this->errstr, $this->errno); die (nl2br (htmlspecialchars ($msg))); } 2.10.7 Issuing Queries and Processing the Results Now we get to the heart of the matter, issuing queries. To execute a statement, pass it to issue_query( ): function issue_query ($query_str) { if (!$this->connect ( )) # establish connection to server if return (FALSE); # necessary $this->num_rows = 0; $this->result_id = mysql_query ($query_str, $this->conn_id); $this->errno = mysql_errno ( ); $this->errstr = mysql_error ( ); if ($this->errno) { $this->error ("Cannot execute query: $query_str"); return (FALSE); } # get number of affected rows for non-SELECT; this also returns # number of rows for a SELECT $this->num_rows = mysql_affected_rows ($this->conn_id); return ($this->result_id); } issue_query( ) first calls connect( ) to make sure that a connection has been established before it sends the query to the server. Then it executes the query, sets the error variables (which will be 0 and the empty string if no error occurs), and checks whether or not the query succeeded. If it failed, issue_query( ) takes the appropriate error-handling action. Otherwise, it sets $num_rows and the result set identifier becomes the return value. For a non-SELECT query, $num_rows indicates the number of rows changed by the query. For a SELECT query, it indicates the number of rows returned. (There's a little bit of cheating here. mysql_affected_rows( ) really is intended only for non-SELECT statements, but happens to return the number of rows in the result set for SELECT queries.) If a query produces a result set, you'll want to fetch its rows. PHP provides several functions for this, which were discussed in Recipe 2.5: mysql_fetch_row( ), mysql_fetch_array( ), and mysql_fetch_object( ). These functions can be used as the basis for corresponding MySQL_Access methods fetch_row( ), fetch_array( ), and fetch_object( ). Each of these methods fetches the next row and returns it, or, if there are no more rows left, releases the result set and returns FALSE. They also set the error variables automatically on every call. The fetch_row( ) method is shown here; fetch_array( ) and fetch_object( ) are very similar: # Fetch the next row as an array with numeric indexes function fetch_row ( ) { $this->row = mysql_fetch_row ($this->result_id); $this->errno = mysql_errno ( ); $this->errstr = mysql_error ( ); if ($this->errno) { $this->error ("fetch_row error"); return (FALSE); } if (is_array ($this->row)) return ($this->row); $this->free_result ( ); return (FALSE); } The free_result( ) method used by the row-fetching methods releases the result set, if there is one: function free_result ( ) { if ($this->result_id) mysql_free_result ($this->result_id); $this->result_id = 0; return (TRUE); } Freeing the result set automatically when the last record has been fetched is one way the class interface simplifies MySQL access, compared to the PHP function-based interface. However, any script that fetches only part of a result set should invoke free_result( ) itself to release the set explicitly. To determine whether or not a value from a result set represents a NULL value, compare it to the PHP NULL value by using the triple-equals operator: if ($val === NULL) { # $val is a NULL value } Alternatively, use isset( ): if (!isset ($val)) { # $val is a NULL value } At this point, enough machinery is present in the class interface that it is usable for writing scripts that issue queries and process the results: # instantiate connection object include "Cookbook_DB_Access.php"; $conn = new Cookbook_DB_Access; # issue query that returns no result set $query = "UPDATE profile SET cats=cats+1 WHERE name = 'Fred'"; $conn->issue_query ($query); print ($conn->num_rows . " rows were updated\n"); # issue queries that fetch rows, using each row-fetching method $query = "SELECT id, name, cats FROM profile"; $conn->issue_query ($query); while ($row = $conn->fetch_row ( )) print ("id: $row[0], name: $row[1], cats: $row[2]\n"); $conn->issue_query ($query); while ($row = $conn->fetch_array ( )) { print ("id: $row[0], name: $row[1], cats: $row[2]\n"); print ("id: $row[id], name: $row[name], cats: $row[cats]\n"); } $conn->issue_query ($query); while ($row = $conn->fetch_object ( )) print ("id: $row->id, name: $row->name, cats: $row->cats\n"); 2.10.8 Quoting and Placeholder Support In Recipe 2.9, we developed a PHP sql_quote( ) function for PHP to handle quoting, escaping, and NULL (unset) values, so that any value can be inserted easily into a query: function sql_quote ($str) { if (!isset ($str)) return ("NULL"); $func = function_exists ("mysql_escape_string") ? "mysql_escape_string" : "addslashes"; return ("'" . $func ($str) . "'"); } If we add sql_quote( ) to the MySQL_Access class, it becomes available automatically to any class instance as an object method and you can construct query strings that include properly quoted values like so: $stmt = sprintf ("INSERT INTO profile (name,birth,color,foods,cats) VALUES(%s,%s,%s,%s,%s)", $conn->sql_quote ("De'Mont"), $conn->sql_quote ("1973-01-12"), $conn->sql_quote (NULL), $conn->sql_quote ("eggroll"), $conn->sql_quote (4)); $conn->issue_query ($stmt); In fact, we can employ the sql_quote( ) method as the basis for a placeholder emulation mechanism, to be used as follows: 1. Begin by passing a query string to the prepare_query( ) method. 2. Indicate placeholders in the query string by using ? characters. 3. Execute the query and supply an array of values to be bound to the query, one value per placeholder. (To bind NULL to a placeholder, pass the PHP NULL value.) One way to perform parameter binding is to do a lot of pattern matching and substitution in the query string wherever ? occurs as a placeholder character. An easier approach is simply to break the query string at the ? characters, then glue the pieces back together at query execution time with the properly quoted data values inserted between the pieces. Splitting the query also is an easy way to find out how many placeholders there are (it's the number of pieces, minus one). That's useful for determining whether or not the proper number of data values is present when it comes time to bind those values to the placeholders. The prepare_query( ) method is quite simple. All it does is split up the query string at ? characters, placing the result into the $query_pieces array for later use at parameter- binding time: function prepare_query ($query) { $this->query_pieces = explode ("?", $query); return (TRUE); } We could invent new calls for binding data values to the query and for executing it, but it's also possible to modify issue_query( ) a little, to have it determine what to do by examining the type of its argument. If the argument is a string, it's interpreted as a query that should be executed directly (which is how issue_query( ) behaved before). If the argument is an array, it is assumed to contain data values to be bound to a previously prepared statement. With this change, issue_query( ) looks like this: function issue_query ($arg = "") { if ($arg == "") # if no argument, assume prepared statement $arg = array ( ); # with no values to be bound if (!$this->connect ( )) # establish connection to server if return (FALSE); # necessary if (is_string ($arg)) # $arg is a simple query $query_str = $arg; else if (is_array ($arg)) # $arg contains data values for placeholders { if (count ($arg) != count ($this->query_pieces) - 1) { $this->errno = -1; $this->errstr = "data value/placeholder count mismatch"; $this->error ("Cannot execute query"); return (FALSE); } # insert data values into query at placeholder # positions, quoting values as we go $query_str = $this->query_pieces[0]; for ($i = 0; $i < count ($arg); $i++) { $query_str .= $this->sql_quote ($arg[$i]) . $this->query_pieces[$i+1]; } } else # $arg is garbage { $this->errno = -1; $this->errstr = "unknown argument type to issue_query"; $this->error ("Cannot execute query"); return (FALSE); } $this->num_rows = 0; $this->result_id = mysql_query ($query_str, $this->conn_id); $this->errno = mysql_errno ( ); $this->errstr = mysql_error ( ); if ($this->errno) { $this->error ("Cannot execute query: $query_str"); return (FALSE); } # get number of affected rows for non-SELECT; this also returns # number of rows for a SELECT $this->num_rows = mysql_affected_rows ($this->conn_id); return ($this->result_id); } Now that quoting and placeholder support is in place, the class provides three ways of issuing queries. First, you can write out the entire query string literally and perform quoting, escaping, and NULL handling yourself: $conn->issue_query ("INSERT INTO profile (name,birth,color,foods,cats) VALUES('De\'Mont','1973-01-12',NULL,'eggroll','4')"); Second, you can use the sql_quote( ) method to insert data values into the query string: $stmt = sprintf ("INSERT INTO profile (name,birth,color,foods,cats) VALUES(%s,%s,%s,%s,%s)", $conn->sql_quote ("De'Mont"), $conn->sql_quote ("1973-01-12"), $conn->sql_quote (NULL), $conn->sql_quote ("eggroll"), $conn->sql_quote (4)); $conn->issue_query ($stmt); Third, you can use placeholders and let the class interface handle all the work of binding values to the query: $conn->prepare_query ("INSERT INTO profile (name,birth,color,foods,cats) VALUES(?,?,?,?,?)"); $conn->issue_query (array ("De'Mont", "1973-01-12", NULL, "eggroll", 4)); The MySQL_Access and Cookbook_DB_Access classes now provide a reasonably convenient means of writing PHP scripts that is easier to use than the native MySQL PHP calls. The class interface also includes placeholder support, something that PHP does not provide at all. The development of these classes illustrates how you can write your own interface that hides MySQL-specific details. The interface is not without its shortcomings, naturally. For example, it allows you to prepare only one statement at a time, unlike DBI and JDBC, which support multiple simultaneous prepared statements. Should you require such functionality, you might consider how to reimplement MySQL_Access to provide it. 2.11 Ways of Obtaining Connection Parameters 2.11.1 Problem You need to obtain connection parameters for a script so that it can connect to a MySQL server. 2.11.2 Solution There are lots of ways to do this. Take your pick. 2.11.3 Discussion Any program that connects to MySQL needs to specify connection parameters such as the username, password, and hostname. The recipes shown so far have put connection parameters directly into the code that attempts to establish the connection, but that is not the only way for your programs to obtain the parameters. This section briefly surveys some methods you can use, then shows how to implement two of them. · Hardwire the parameters into the program. The parameters can be given either in the main source file or in a library file that is used by the program. This is convenient because users need not enter the values themselves. The flip side, of course, is that it's not very flexible. To change the parameters, you must modify your program. · Ask for the parameters interactively. In a command-line environment, you can ask the user a series of questions. In a web or GUI environment, this might be done by presenting a form or dialog. Either way, this gets to be tedious for people who use the program frequently, due to the need to enter the parameters each time. · Get the parameters from the command line. This method can be used either for commands that you run interactively or that are run from within a script. Like the method of obtaining parameters interactively, this requires you to supply parameters each time you use MySQL, and can be similarly tiresome. (A factor that significantly mitigates this burden is that many shells allow you to recall commands from your history list for reexecution.) · Get the parameters from the execution environment. The most common way of using this method is to set the appropriate environment variables in one of your shell's startup files (such as .cshrc for csh; .tcshrc for tcsh; or .profile for sh, bash, and ksh). Programs that you run during your login session then can get parameter values by examining their environment. · Get the parameters from a separate file. With this method, you store information such as the username and password in a file that programs can read before connecting to the MySQL server. Reading parameters from a file that's separate from your program gives you the benefit of not having to enter them each time you use the program, while allowing you to avoid hardwiring the values into the program itself. This is especially convenient for interactive programs, because then you need not enter parameters each time you run the program. Also, storing the values in a file allows you to centralize parameters for use by multiple programs, and you can use the file access mode for security purposes. For example, you can keep other users from reading the file by setting its mode to allow access only to yourself. The MySQL client library itself supports an option file mechanism, although not all APIs provide access to it. For those that don't, workarounds may exist. (As an example, Java supports the use of properties files and supplies utility routines for reading them.) · Use a combination of methods. It's often useful to combine some of the preceding methods, to afford users the option of providing parameters different ways. For example, MySQL clients such as mysql and mysqladmin look for option files in several locations and read any that are present. Then they check the command-line arguments for further parameters. This allows users to specify connection parameters in an option file or on the command line. These methods of obtaining connection parameters do involve some security issues. Briefly summarized, these issues are: · Any method that stores connection parameters in a file may result in compromise unless the file is protected against read access by unauthorized users. This is true whether parameters are stored in a source file, an option file, or a script that invokes a command and specifies the parameters on the command line. (Web scripts that can be read only by the web server don't qualify as secure if other users have administrative access to the server.) · Parameters specified on the command line or in environment variables are not particularly secure. While a program is executing, its command-line arguments and environment may be visible to other users who run process status commands such as ps -e. In particular, storing the password in an environment variable perhaps is best limited to use in situations where you're the only user on the machine or you trust all other users. The rest of this section shows how to process command-line arguments to get connection parameters, and how to read parameters from option files. 2.11.4 Getting Parameters from the Command Line The usual MySQL convention for command-line arguments (that is, the convention followed by standard MySQL clients such as mysql) is to allow parameters to be specified using either a short option or a long option. For example, the username cbuser can be specified either as -u cbuser (or -ucbuser) or --user=cbuser. In addition, for the options that specify the password (-p or --password), the password value may be omitted after the option name to indicate that the program should prompt for the password interactively. The next set of example programs shows how to process command arguments to obtain the hostname, username, and password. The standard flags for these are -h or --host, -u or -- user, and -p or --password. You can write your own code to iterate through the argument list, but in general, it's much easier to use existing option-processing modules written for that purpose. The programs presented here are implemented using a getopt( )-style function for each API, with the exception of PHP. Insofar as possible, the examples mimic the behavior of the standard MySQL clients. (No example program is provided for PHP, because few PHP scripts are written for use from the command line.) 2.11.4.1 Perl Perl passes command-line arguments to scripts in the @ARGV array, which can be processed using the GetOptions( ) function of the Getopt::Long module. The following program shows how to parse the command arguments for connection parameters. If a password option is specified with no following argument, the script prompts the user for the password value. #! /usr/bin/perl -w # cmdline.pl - demonstrate command-line option parsing in Perl use strict; use DBI; use Getopt::Long; $Getopt::Long::ignorecase = 0; # options are case sensitive $Getopt::Long::bundling = 1; # allow short options to be bundled # connection parameters - all missing (undef) by default my ($host_name, $password, $user_name); GetOptions ( # =s means a string argument is required after the option # :s means a string argument is optional after the option "host|h=s" => \$host_name, "password|p:s" => \$password, "user|u=s" => \$user_name ) or exit (1); # no error message needed; GetOptions( ) prints its own # solicit password if option specified without option value if (defined ($password) && $password eq "") { # turn off echoing but don't interfere with STDIN open (TTY, "/dev/tty") or die "Cannot open terminal\n"; system ("stty -echo < /dev/tty"); print STDERR "Enter password: "; chomp ($password = ); system ("stty echo < /dev/tty"); close (TTY); print STDERR "\n"; } # construct data source name my $dsn = "DBI:mysql:database=cookbook"; $dsn .= ";host=$host_name" if defined ($host_name); # connect to server my $dbh = DBI->connect ($dsn, $user_name, $password, {PrintError => 0, RaiseError => 1}); print "Connected\n"; $dbh->disconnect ( ); print "Disconnected\n"; exit (0); The arguments to GetOptions( ) are pairs of option specifiers and references to the script variables into which option values should be placed. An option specifier lists both the long and short forms of the option (without leading dashes), followed by =s if the option requires a following argument or :s if it may be followed by an argument. For example, "host|h=s" allows both --host and -h and indicates that a string argument is required following the option. You need not pass the @ARGV array because GetOptions( ) uses it implicitly. When GetOptions( ) returns, @ARGV contains any remaining arguments following the last option. The Getopt::Long module's $bundling variable affects the interpretation of arguments that begin with a single dash, such as -u. Normally, we'd like to accept both -u cbuser and - ucbuser as the same thing, because that's how the standard MySQL clients act. However, if $bundling is zero (the default value), GetOptions( ) interprets -ucbuser as a single option named "ucbuser". By setting $bundling to nonzero, GetOptions( ) understands both -u cbuser and -ucbuser the same way. This happens because it interprets an option beginning with a single dash character by character, on the basis that several single-character options may be bundled together. For example, when it sees -ucbuser, it looks at the u, then checks whether or not the option takes a following argument. If not, the next character is interpreted as another option letter. Otherwise, the rest of the string is taken as the option's value. For -ucbuser, u does take an argument, so GetOptions( ) interprets cbuser as the option value. One problem with GetOptions( ) is that it doesn't support -p without a password the same way as the standard MySQL client programs. If -p is followed by another option, GetOptions( ) correctly determines that there is no password value present. But if -p is followed by a non-option argument, it misinterprets that argument as the password. The result is that these two invocations of cmdline.pl are not quite equivalent: % cmdline.pl -h localhost -p -u cbuser xyz Enter password: % cmdline.pl -h localhost -u cbuser -p xyz DBI->connect(database=cookbook;host=localhost) failed: Access denied for user: 'cbuser@localhost' (Using password: YES) at ./cmdline.pl line 40 For the first command, GetOptions( ) determines that no password is present and the script prompts for one. In the second command, GetOptions( ) has taken xyz as the password value. A second problem with cmdline.pl is that the password-prompting code is Unix specific and doesn't work under Windows. You could try using Term::ReadKey, which is a standard Perl module, but it doesn't work under Windows, either. (If you have a good password prompter for Windows, you might consider sending it to me for inclusion in the recipes distribution.) 2.11.4.2 PHP PHP provides little support for option processing from the command line because it is used predominantly in a web environment where command-line arguments are not widely used. Hence, I'm providing no getopt( )-style example for PHP. If you want to go ahead and write your own argument processing routine, use the $argv array containing the arguments and the $argc variable indicating the number of arguments. $argv[0] is the program name, and $argv[1] to $argv[$argc-1] are the following arguments. The following code illustrates how to access these variables: print ("Number of arguments: $argc\n"); print ("Program name: $argv[0]\n"); print ("Arguments following program name:\n"); if ($argc == 1) print ("None\n"); else { for ($i = 1; $i < $argc; $i++) print ("$i: $argv[$i]\n"); } 2.11.4.3 Python Python passes command arguments to scripts as a list in the sys.argv variable. You can access this variable by importing the sys module, then process its contents with getopt( ) if you also import the getopt module. The following program illustrates how to get parameters from the command arguments and use them for establishing a connection to the server: #! /usr/bin/python # cmdline.py - demonstrate command-line option parsing in Python import sys import getopt import MySQLdb try: opts, args = getopt.getopt (sys.argv[1:], "h:p:u:", [ "host=", "password=", "user=" ]) except getopt.error, e: # print program name and text of error message print "%s: %s" % (sys.argv[0], e) sys.exit (1) # default connection parameter values host_name = password = user_name = "" # iterate through options, extracting whatever values are present for opt, arg in opts: if opt in ("-h", "--host"): host_name = arg elif opt in ("-p", "--password"): password = arg elif opt in ("-u", "--user"): user_name = arg try: conn = MySQLdb.connect (db = "cookbook", host = host_name, user = user_name, passwd = password) print "Connected" except MySQLdb.Error, e: print "Cannot connect to server" print "Error:", e.args[1] print "Code:", e.args[0] sys.exit (1) conn.close ( ) print "Disconnected" sys.exit (0) getopt( ) takes either two or three arguments: · A list of command arguments. This should not include the program name, sys.argv[0]. You can use sys.argv[1:] to refer to the list of arguments that follow the program name. · A string naming the short option letters. Any of these may be followed by a colon character (:) to indicate that the option requires a following argument that specifies the option's value. · An optional list of long option names. Each name may be followed by = to indicate that the option requires a following argument. getopt( ) returns two values. The first is a list of option/value pairs, and the second is a list of any remaining arguments following the last option. cmdline.py iterates through the option list to determine which options are present and what their values are. Note that although you do not specify leading dashes in the option names passed to getopt( ), the names returned from that function do include leading dashes. cmdline.py doesn't prompt for a missing password, because the getopt( ) module doesn't provide any way to specify that an option's argument is optional. Unfortunately, this means the -p and --password arguments cannot be specified without a password value. 2.11.4.4 Java Java passes command-line arguments to programs in the array that you name in the main( ) declaration. The following declaration uses args for that array: public static void main (String[ ] args) A Getopt class for parsing arguments in Java is available at http://www.urbanophile.com/arenn/coding/download.html Install this class somewhere and make sure its installation directory is named in the value of your CLASSPATH environment variable. Then you can use Getopt as shown in the following example program: // Cmdline.java - demonstrate command-line option parsing in Java import java.io.*; import java.sql.*; import gnu.getopt.*; // need this for the Getopt class public class Cmdline { public static void main (String[ ] args) { Connection conn = null; String url = null; String hostName = null; String password = null; String userName = null; boolean promptForPassword = false; LongOpt[ ] longOpt = new LongOpt[3]; int c; longOpt[0] = new LongOpt ("host", LongOpt.REQUIRED_ARGUMENT, null, 'h'); longOpt[1] = new LongOpt ("password", LongOpt.OPTIONAL_ARGUMENT, null, 'p'); longOpt[2] = new LongOpt ("user", LongOpt.REQUIRED_ARGUMENT, null, 'u'); // instantiate option-processing object, then // loop until there are no more options Getopt g = new Getopt ("Cmdline", args, "h:p::u:", longOpt); while ((c = g.getopt ( )) != -1) { switch (c) { case 'h': hostName = g.getOptarg ( ); break; case 'p': // if password option was given with no following // value, need to prompt for the password password = g.getOptarg ( ); if (password == null) promptForPassword = true; break; case 'u': userName = g.getOptarg ( ); break; case ':': // a required argument is missing case '?': // some other error occurred // no error message needed; getopt( ) prints its own System.exit (1); } } if (password == null && promptForPassword) { try { DataInputStream s = new DataInputStream (System.in); System.err.print ("Enter password: "); // really should turn off character echoing here... password = s.readLine ( ); } catch (Exception e) { System.err.println ("Error reading password"); System.exit (1); } } try { // construct URL, noting whether or not hostName // was given; if not, MySQL will assume localhost if (hostName == null) hostName = ""; url = "jdbc:mysql://" + hostName + "/cookbook"; Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); conn = DriverManager.getConnection (url, userName, password); System.out.println ("Connected"); } catch (Exception e) { System.err.println ("Cannot connect to server"); } finally { if (conn != null) { try { conn.close ( ); System.out.println ("Disconnected"); } catch (Exception e) { } } } } } As the example program demonstrates, you prepare to parse arguments by instantiating a new Getopt object to which you pass the program's arguments and information describing the options the program allows. Then you call getopt( ) in a loop until it returns -1 to indicate that no more options are present. Each time through the loop, getopt( ) returns a value indicating which option it's seen, and getOptarg( ) may be called to obtain the option's argument, if necessary. (getOptarg( ) returns null if no following argument was provided.) When you create an instance of the Getopt( ) class, pass it either three or four arguments: · The program name; this is used for error messages. · The argument array named in your main( ) declaration. · A string listing the short option letters (without leading dashes). Any of these may be followed by a colon (:) to indicate that the option requires a following argument, or by a double colon (::) to indicate that a following argument is optional. · An optional array that contains long option information. To specify long options, you must set up an array of LongOpt objects. Each of these describes a single option, using four parameters: o The option name as a string (without leading dashes). o A value indicating whether the option takes a following argument. This value may be LongOpt.NO_ARGUMENT, LongOpt.REQUIRED_ARGUMENT, or LongOpt.OPTIONAL_ARGUMENT. o A StringBuffer object or null. getopt( ) determines how to use this value based on the fourth parameter of the LongOpt object. o A value to be used when the option is encountered. This value becomes the return value of getopt( ) if the StringBuffer object named in the third parameter is null. If the buffer is non-null, getopt( ) returns zero after placing a string representation of the fourth parameter into the buffer. The example program uses null as the StringBuffer parameter for each long option object and the corresponding short option letter as the fourth parameter. This is an easy way to cause getopt( ) to return the short option letter for both the short and long options, so that you can handle them with the same case statement. After getopt( ) returns -1 to indicate that no more options were found in the argument array, getOptind( ) returns the index of the first argument following the last option. The following code fragment shows one way to access the remaining arguments: for (int i = g.getOptind ( ); i < args.length; i++) System.out.println (args[i]); The Getopt class offers other option-processing behavior in addition to what I've described here. Read the documentation included with the class for more information. One deficiency of Cmdline.java that you may want to address is that it doesn't disable character echoing while it's reading the password. 2.11.5 Getting Parameters from Option Files If your API allows it, you can specify connection parameters in a MySQL option file and the API will read the parameters from the file for you. For APIs that do not support option files directly, you may be able to arrange to read other types of files in which parameters are stored, or to write your own functions that read option files. The format of option files was described in Chapter 1. I'll assume that you've read the discussion there and concentrate here on how to use option files from within programs. Under Unix, user-specific options are specified by convention in ~/.my.cnf (that is, in the .my.cnf file in your home directory). However, the MySQL option file mechanism can look in several different files. The standard search order is /etc/my.cnf, the my.cnf file in the server's default data directory, and the ~/.my.cnf file for the current user. Under Windows, the search order is the my.ini file in the Windows system directory, C:\my.cnf, and the my.cnf file in the server's default data directory. If multiple option files exist and a parameter is specified in several of them, the last value found takes precedence. However, it's not an error for any given option file not to exist. MySQL option files will not be used by your own programs unless you tell them to do so. Perl and Python provide direct API support for reading option files; simply indicate that you want to use them at the time that you connect to the server. It's possible to specify that only a particular file should be read, or that the standard search order should be used to look for multiple option files. PHP and Java do not support option files. As a workaround for PHP, we'll write a simple option file parsing function. For Java, we'll adopt a different approach that uses properties files. Although the conventional name under Unix for the user-specific option file is .my.cnf in the current user's home directory, there's no rule your programs must use this particular file. You can name an option file anything you like and put it wherever you want. For example, you might set up a file /usr/local/apache/lib/cb.cnf for use by web scripts that access the cookbook database. Under some circumstances, you may even want to create multiple files. Then, from within any given script, you can select the file that's appropriate for the type of permissions the script needs. For example, you might have one option file, cb.cnf, that lists parameters for a full-access MySQL account, and another file, cb-ro.cnf, that lists connection parameters for an account that needs only read-only access to MySQL. Another possibility is to list multiple groups within the same option file and have your scripts select options from the appropriate group. C API Support for Option Files The Perl and Python APIs are built using the C API, and option file support was not added to the C client library until MySQL 3.22.10. This means that even for Perl and Python, you must have MySQL 3.22.10 or later to use option files from within your own programs. Historically, the database name has not been a parameter you get from an option file. (Programs typically provide this value themselves or expect the user to specify it.) As of MySQL 3.23.6, support was added to the C client library to look for option file lines of the form database=db_name, but the examples in this section do not use this fact. 2.11.5.1 Perl Perl DBI scripts can use option files if you have DBD::mysql 1.21.06 or later. To take advantage of this, place the appropriate option specifiers in the third component of the data source name string: · To specify an option group, use mysql_read_default_group=groupname. This tells MySQL to search the standard option files for options in the named group and in the [client] group. The groupname value should be written without the square brackets that are part of the line that begins the group. For example, if a group in an option file begins with a [my_prog] line, specify my_prog as the groupname value. To search the standard files but look only in the [client] group, groupname should be client. · To name a specific option file, use mysql_read_default_file=filename in the DSN. When you do this, MySQL looks only in that file, and only for options in the [client] group. · If you specify both an option file and an option group, MySQL reads only the named file, but looks for options both in the named group and in the [client] group. The following example tells MySQL to use the standard option file search order to look for options in both the [cookbook] and [client] groups: # basic DSN my $dsn = "DBI:mysql:database=cookbook"; # look in standard option files; use [cookbook] and [client] groups $dsn .= ";mysql_read_default_group=cookbook"; my $dbh = DBI->connect ($dsn, undef, undef, { PrintError => 0, RaiseError => 1 }); The next example explicitly names the option file located in $ENV{HOME}, the home directory of the user running the script. Thus, MySQL will look only in that file and will use options from the [client] group: # basic DSN my $dsn = "DBI:mysql:database=cookbook"; # look in user-specific option file owned by the current user $dsn .= ";mysql_read_default_file=$ENV{HOME}/.my.cnf"; my $dbh = DBI->connect ($dsn, undef, undef, { PrintError => 0, RaiseError => 1 }); If you pass an empty value (undef or the empty string) for the username or password arguments of the connect( ) call, connect( ) uses whatever values are found in the option file or files. A nonempty username or password in the connect( ) call overrides any option file value. Similarly, a host named in the DSN overrides any option file value. You can use this behavior to allow DBI scripts to obtain connection parameters both from option files as well as from the command line as follows: 1. Create $host_name, $user_name, and $password variables and initialize them to undef. Then parse the command- line arguments to set the variables to non-undef values if the corresponding options are present on the command line. (See the Perl script earlier in this section to see how this is done.) 2. After parsing the command arguments, construct the DSN string and call connect( ). Use mysql_read_default_group and mysql_read_default_file in the DSN to specify how you want option files to be used, and, if $host_name is not undef, add host=$host_name to the DSN. In addition, pass $user_name and $password as the username and password arguments to connect( ). These will be undef by default; if they were set from the command-line arguments, they will have non-undef values that override any option file values. If a script follows this procedure, parameters given by the user on the command line are passed to connect( ) and take precedence over the contents of option files. 2.11.5.2 PHP PHP has no native support for using MySQL option files, at least at the moment. To work around that limitation, use a function that reads an option file, such as the read_mysql_option_file( ) function shown below. It takes as arguments the name of an option file and an option group name or an array containing group names. (Group names should be named without square brackets.) Then it reads any options present in the file for the named group or groups. If no option group argument is given, the function looks by default in the [client] group. The return value is an array of option name/value pairs, or FALSE if an error occurs. It is not an error for the file not to exist. function read_mysql_option_file ($filename, $group_list = "client") { if (is_string ($group_list)) # convert string to array $group_list = array ($group_list); if (!is_array ($group_list)) # hmm ... garbage argument? return (FALSE); $opt = array ( ); # option name/value array if (!($fp = fopen ($filename, "r"))) # if file does not exist, return ($opt); # return an empty list $in_named_group = 0; # set non-zero while processing a named group while ($s = fgets ($fp, 1024)) { $s = trim ($s); if (ereg ("^[#;]", $s)) # skip comments continue; if (ereg ("^\[([^]]+)]", $s, $arg)) # option group line? { # check whether we're in one of the desired groups $in_named_group = 0; reset ($group_list); while (list ($key, $group_name) = each ($group_list)) { if ($arg[1] == $group_name) { $in_named_group = 1; # we are break; } } continue; } if (!$in_named_group) # we're not in a desired continue; # group, skip the line if (ereg ("^([^ \t=]+)[ \t]*=[ \t]*(.*)", $s, $arg)) $opt[$arg[1]] = $arg[2]; # name=value else if (ereg ("^([^ \t]+)", $s, $arg)) $opt[$arg[1]] = ""; # name only # else line is malformed } return ($opt); } Here are a couple of examples showing how to use read_mysql_option_file( ). The first reads a user's option file to get the [client] group parameters, then uses them to connect to the server. The second reads the system-wide option file and prints the server startup parameters that are found there (that is, the parameters in the [mysqld] and [server] groups): $opt = read_mysql_option_file ("/u/paul/.my.cnf"); $link = @mysql_connect ($opt["host"], $opt["user"], $opt["password"]); $opt = read_mysql_option_file ("/etc/my.cnf", array ("mysqld", "server")); while (list ($name, $value) = each ($opt)) print ("$name => $value\n"); If you're using the MySQL_Access interface that was developed in Recipe 2.10, you might think about how to extend the class by implementing a derived class that gets the username, password, and hostname from an option file. You could also give this derived class the ability to search multiple files, which is an aspect of the usual option file behavior that read_mysql_option_file( ) does not provide. 2.11.5.3 Python The MySQLdb module for DB-API provides direct support for using MySQL option files. Specify an option file or option group using read_default_file or read_default_group arguments to the connect( ) method. These two arguments act the same way as the mysql_read_default_file and mysql_read_default_group options for the Perl DBI connect( ) method (see the Perl discussion earlier in this section). To use the standard option file search order to look for options in both the [cookbook] and [client] groups, do something like this: try: conn = MySQLdb.connect (db = "cookbook", read_default_group = "cookbook") print "Connected" except: print "Cannot connect to server" sys.exit (1) The following example shows how to use the .my.cnf file in the current user's home directory to obtain parameters from the [client]group:[8] [8] You must import the os module to access os.environ. try: option_file = os.environ["HOME"] + "/" + ".my.cnf" conn = MySQLdb.connect (db = "cookbook", read_default_file = option_file) print "Connected" except: print "Cannot connect to server" sys.exit (1) 2.11.5.4 Java The MySQL Connector/J JDBC driver doesn't support option files. However, the Java class library provides support for reading properties files that contain lines in name=value format. This is somewhat similar to MySQL option file format, although there are some differences (for example, properties files do not allow [groupname] lines). Here is a simple properties file: # this file lists parameters for connecting to the MySQL server user=cbuser password=cbpass host=localhost The following program, ReadPropsFile.java, shows one way to read a properties file named Cookbook.properties to obtain connection parameters. The file must be in a directory named in your CLASSPATH variable, or else you must specify it using a full pathname (the example shown here assumes the file is in a CLASSPATH directory): import java.sql.*; import java.util.*; // need this for properties file support public class ReadPropsFile { public static void main (String[ ] args) { Connection conn = null; String url = null; String propsFile = "Cookbook.properties"; Properties props = new Properties ( ); try { props.load (ReadPropsFile.class.getResourceAsStream (propsFile)); } catch (Exception e) { System.err.println ("Cannot read properties file"); System.exit (1); } try { // construct connection URL, encoding username // and password as parameters at the end url = "jdbc:mysql://" + props.getProperty ("host") + "/cookbook" + "?user=" + props.getProperty ("user") + "&password=" + props.getProperty ("password"); Class.forName ("com.mysql.jdbc.Driver").newInstance ( ); conn = DriverManager.getConnection (url); System.out.println ("Connected"); } catch (Exception e) { System.err.println ("Cannot connect to server"); } finally { try { if (conn != null) { conn.close ( ); System.out.println ("Disconnected"); } } catch (SQLException e) { /* ignore close errors */ } } } } If you want getProperty() to return a particular default value when the named property is not found, pass that value as a second argument. For example, to use localhost as the default host value, call getProperty() like this: String hostName = props.getProperty ("host", "localhost"); The Cookbook.class library file developed earlier in the chapter (Recipe 2.4) includes a propsConnect() routine that is based on the concepts discussed here. To use it, set up the contents of the properties file, Cookbook.properties, and copy the file to the same location where you installed Cookbook.class. Then you can establish a connection within a program by importing the Cookbook class and calling Cookbook.propsConnect() rather than by calling Cookbook.connect(). 2.12 Conclusion and Words of Advice This chapter discusses the basic operations provided by each of our APIs for handling various aspects of interacting with the MySQL server. These operations allow you to write programs that issue any kind of query and retrieve the results. Up to this point, we've used simple queries because the focus is on the APIs rather than on SQL. The next chapter focuses on SQL instead, to show how to ask the database server more complex questions. Before you proceed, it would be a good idea to reset the profile table used in this chapter to a known state. Several queries in later chapters use this table; by reinitializing it, you'll get the same results displayed in those chapters when you run the queries shown there. To reset the table, change location into the tables directory of the recipes distribution and run the following commands: % mysql cookbook < profile.sql % mysql cookbook < profile2.sql Chapter 3. Record Selection Techniques Section 3.1. Introduction Section 3.2. Specifying Which Columns to Display Section 3.3. Avoiding Output Column Order Problems When Writing Programs Section 3.4. Giving Names to Output Columns Section 3.5. Using Column Aliases to Make Programs Easier to Write Section 3.6. Combining Columns to Construct Composite Values Section 3.7. Specifying Which Rows to Select Section 3.8. WHERE Clauses and Column Aliases Section 3.9. Displaying Comparisons to Find Out How Something Works Section 3.10. Reversing or Negating Query Conditions Section 3.11. Removing Duplicate Rows Section 3.12. Working with NULL Values Section 3.13. Negating a Condition on a Column That Contains NULL Values Section 3.14. Writing Comparisons Involving NULL in Programs Section 3.15. Mapping NULL Values to Other Values for Display Section 3.16. Sorting a Result Set Section 3.17. Selecting Records from the Beginning or End of a Result Set Section 3.18. Pulling a Section from the Middle of a Result Set Section 3.19. Choosing Appropriate LIMIT Values Section 3.20. Calculating LIMIT Values from Expressions Section 3.21. What to Do When LIMIT Requires the "Wrong" Sort Order Section 3.22. Selecting a Result Set into an Existing Table Section 3.23. Creating a Destination Table on the Fly from a Result Set Section 3.24. Moving Records Between Tables Safely Section 3.25. Creating Temporary Tables Section 3.26. Cloning a Table Exactly Section 3.27. Generating Unique Table Names 3.1 Introduction This chapter focuses on the SELECT statement that is used for retrieving information from a database. It provides some essential background that shows various ways you can use SELECT to tell MySQL what you want to see. You should find the chapter helpful if your SQL background is limited or if you want to find out about the MySQL-specific extensions to SELECT syntax. However, there are so many ways to write SELECT queries that we'll necessarily touch on just a few. You may wish to consult the MySQL Reference Manual or a MySQL text for more information about the syntax of SELECT, as well as the functions and operators that you can use for extracting and manipulating data. SELECT gives you control over several aspects of record retrieval: · Which table to use · Which columns to display from the table · What names to give the columns · Which rows to retrieve from the table · How to sort the rows Many useful queries are quite simple and don't specify all those things. For example, some forms of SELECT don't even name a table—a fact used in Recipe 1.32, which discusses how to use mysql as a calculator. Other non-table-based queries are useful for purposes such as checking what version of the server you're running or the name of the current database: mysql> SELECT VERSION( ), DATABASE( ); +-------------+------------+ | VERSION( ) | DATABASE( )| +-------------+------------+ | 3.23.51-log | cookbook | +-------------+------------+ However, to answer more involved questions, normally you'll need to pull information from one or more tables. Many of the examples in this chapter use a table named mail, which contains columns used to maintain a log of mail message traffic between users on a set of hosts. Its definition looks like this: CREATE TABLE mail ( t DATETIME, # when message was sent srcuser CHAR(8), # sender (source user and host) srchost CHAR(20), dstuser CHAR(8), # recipient (destination user and host) dsthost CHAR(20), size BIGINT, # message size in bytes INDEX (t) ); And its contents look like this: +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | | 2001-05-14 09:31:37 | gene | venus | barb | mars | 2291 | | 2001-05-14 11:52:17 | phil | mars | tricia | saturn | 5781 | | 2001-05-14 14:42:21 | barb | venus | barb | venus | 98151 | | 2001-05-14 17:03:01 | tricia | saturn | phil | venus | 2394482 | | 2001-05-15 07:17:48 | gene | mars | gene | saturn | 3824 | | 2001-05-15 08:50:57 | phil | venus | phil | venus | 978 | | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-15 17:35:31 | gene | saturn | gene | mars | 3856 | | 2001-05-16 09:00:28 | gene | venus | barb | mars | 613 | | 2001-05-16 23:04:19 | phil | venus | barb | venus | 10294 | | 2001-05-17 12:49:23 | phil | mars | tricia | saturn | 873 | | 2001-05-19 22:21:51 | gene | saturn | gene | venus | 23992 | +---------------------+---------+---------+---------+---------+---------+ To create the mail table and load its contents, change location into the tables directory of the recipes distribution and run this command: % mysql cookbook < mail.sql This chapter also uses other tables from time to time. Some of these were used in previous chapters, while others are new. For any that you need to create, do so the same way as for the mail table, using scripts in the tables directory. In addition, the text for many of the scripts and programs used in the chapter may be found in the select directory. You can use the files there to try out the examples more easily. Many of the queries shown here can be tried out with mysql, which you can read about in Chapter 1. Some of the examples issue queries from within the context of a programming language. See Chapter 2 for background on programming techniques. 3.2 Specifying Which Columns to Display 3.2.1 Problem You want to display some or all of the columns from a table. 3.2.2 Solution Use * as a shortcut that selects all columns. Or name the columns you want to see explicitly. 3.2.3 Discussion To indicate what kind of information you want to see from a table, name a column or a list of columns and the table to use. The easiest way to select output columns is to use the * specifier, which is a shortcut for naming all the columns in a table: mysql> SELECT * FROM mail; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | ... Alternatively, you can list the columns explicitly: mysql> SELECT t, srcuser, srchost, dstuser, dsthost, size FROM mail; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | ... It's certainly easier to use * than to write out a list of column names. However, with *, there is no guarantee about the order in which columns will be returned. (The server returns them in the order they are listed in the table definition, but this may change if you change the definition. See Chapter 8.) Thus, one advantage of naming the columns explicitly is that you can place them in whatever order you want. Suppose you want hostnames to appear before usernames, rather than after. To accomplish this, name the columns as follows: mysql> SELECT t, srchost, srcuser, dsthost, dstuser, size FROM mail; +---------------------+---------+---------+---------+---------+---------+ | t | srchost | srcuser | dsthost | dstuser | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | saturn | barb | mars | tricia | 58274 | | 2001-05-12 12:48:13 | mars | tricia | venus | gene | 194925 | | 2001-05-12 15:02:49 | mars | phil | saturn | phil | 1048 | | 2001-05-13 13:59:18 | saturn | barb | venus | tricia | 271 | ... Another advantage of naming the columns compared to using * is that you can name just those columns you want to see and omit those in which you have no interest: mysql> SELECT size FROM mail; +---------+ | size | +---------+ | 58274 | | 194925 | | 1048 | | 271 | ... mysql> SELECT t, srcuser, srchost, size FROM mail; +---------------------+---------+---------+---------+ | t | srcuser | srchost | size | +---------------------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | 58274 | | 2001-05-12 12:48:13 | tricia | mars | 194925 | | 2001-05-12 15:02:49 | phil | mars | 1048 | | 2001-05-13 13:59:18 | barb | saturn | 271 | ... 3.3 Avoiding Output Column Order Problems When Writing Programs 3.3.1 Problem You're issuing a SELECT * query from within a program, and the columns don't come back in the order you expect. 3.3.2 Solution When you use * to select columns, all bets are off; you can't assume anything about the order in which they'll be returned. Either name the columns explicitly in the order you want, or retrieve them into a data structure that makes their order irrelevant. 3.3.3 Discussion The examples in the previous section illustrate the differences between using * versus a list of names to specify output columns when issuing SELECT statements from within the mysql program. The difference between approaches also may be significant when issuing queries through an API from within your own programs, depending on how you fetch result set rows. If you select output columns using *, the server returns them using the order in which they are listed in the table definition—an order that may change if the table structure is modified. If you fetch rows into an array, this non-determinacy of output column order makes it impossible to know which column each array element corresponds to. By naming output columns explicitly, you can fetch rows into an array with confidence that the columns will appear in the array in the same order that you named them in the query. On the other hand, your API may allow you to fetch rows into a structure containing elements that are accessed by name. (For example, in Perl you can use a hash; in PHP you can use an associative array or an object.) If you do this, you can issue a SELECT * query and then access structure members by referring to the column names in any order you want. In this case, there is effectively no difference between selecting columns with * or by naming them explicitly: If you can access values by name within your program, their order within result set rows is irrelevant. This fact makes it tempting to take the easy way out by using SELECT * for all your queries, even if you're not actually going to use every column. Nevertheless, it's more efficient to name specifically only the columns you want so that the server doesn't send you information you're just going to ignore. (An example that explains in more detail why you may want to avoid retrieving certain columns is given in Recipe 9.9, in Recipe 9.9.10.") 3.4 Giving Names to Output Columns 3.4.1 Problem You don't like the names of the columns in your query result. 3.4.2 Solution Supply names of your own choosing using column aliases. 3.4.3 Discussion Whenever you retrieve a result set, MySQL gives every output column a name. (That's how the mysql program gets the names that you see displayed as the initial row of column headers in result set output.) MySQL assigns default names to output columns, but if the defaults are not suitable, you can use column aliases to specify your own names. This section explains aliases and shows how to use them to assign column names in queries. If you're writing a program that needs to retrieve information about column names, see Recipe 9.3. If an output column in a result set comes directly from a table, MySQL uses the table column name for the result set column name. For example, the following statement selects three table columns, the names of which become the corresponding output column names: mysql> SELECT t, srcuser, size FROM mail; +---------------------+---------+---------+ | t | srcuser | size | +---------------------+---------+---------+ | 2001-05-11 10:15:08 | barb | 58274 | | 2001-05-12 12:48:13 | tricia | 194925 | | 2001-05-12 15:02:49 | phil | 1048 | | 2001-05-13 13:59:18 | barb | 271 | ... If you generate a column by evaluating an expression, the expression itself is the column name. This can produce rather long and unwieldy names in result sets, as illustrated by the following query that uses an expression to reformat the t column of the mail table: mysql> SELECT -> CONCAT(MONTHNAME(t),' ',DAYOFMONTH(t),', ',YEAR(t)), -> srcuser, size FROM mail; +-----------------------------------------------------+---------+---------+ | CONCAT(MONTHNAME(t),' ',DAYOFMONTH(t),', ',YEAR(t)) | srcuser | size | +-----------------------------------------------------+---------+---------+ | May 11, 2001 | barb | 58274 | | May 12, 2001 | tricia | 194925 | | May 12, 2001 | phil | 1048 | | May 13, 2001 | barb | 271 | ... The preceding example uses a query that is specifically contrived to illustrate how awful- looking column names can be. The reason it's contrived is that you probably wouldn't really write the query that way—the same result can be produced more easily using MySQL's DATE_FORMAT( ) function. But even with DATE_FORMAT( ), the column header is still ugly: mysql> SELECT -> DATE_FORMAT(t,'%M %e, %Y'), -> srcuser, size FROM mail; +----------------------------+---------+---------+ | DATE_FORMAT(t,'%M %e, %Y') | srcuser | size | +----------------------------+---------+---------+ | May 11, 2001 | barb | 58274 | | May 12, 2001 | tricia | 194925 | | May 12, 2001 | phil | 1048 | | May 13, 2001 | barb | 271 | ... To give a result set column a name of your own choosing, use AS name to specify a column alias. The following query retrieves the same result as the previous one, but renames the first column to date_sent: mysql> SELECT -> DATE_FORMAT(t,'%M %e, %Y') AS date_sent, -> srcuser, size FROM mail; +--------------+---------+---------+ | date_sent | srcuser | size | +--------------+---------+---------+ | May 11, 2001 | barb | 58274 | | May 12, 2001 | tricia | 194925 | | May 12, 2001 | phil | 1048 | | May 13, 2001 | barb | 271 | ... You can see that the alias makes the column name more concise, easier to read, and more meaningful. If you want to use a descriptive phrase, an alias can consist of several words. (Aliases can be fairly arbitrary, although they are subject to a few restrictions such as that they must be quoted if they are SQL keywords, contain spaces or other special characters, or are entirely numeric.) The following query retrieves the same data values as the preceding one but uses phrases to name the output columns: mysql> SELECT -> DATE_FORMAT(t,'%M %e, %Y') AS 'Date of message', -> srcuser AS 'Message sender', size AS 'Number of bytes' FROM mail; +-----------------+----------------+-----------------+ | Date of message | Message sender | Number of bytes | +-----------------+----------------+-----------------+ | May 11, 2001 | barb | 58274 | | May 12, 2001 | tricia | 194925 | | May 12, 2001 | phil | 1048 | | May 13, 2001 | barb | 271 | ... Aliases can be applied to any result set column, not just those that come from tables: mysql> SELECT '1+1+1' AS 'The expression', 1+1+1 AS 'The result'; +----------------+------------+ | The expression | The result | +----------------+------------+ | 1+1+1 | 3 | +----------------+------------+ Here, the value of the first column is '1+1+1' (quoted so that it is treated as a string), and the value of the second column is 1+1+1 (without quotes so that MySQL treats it as an expression and evaluates it). The aliases are descriptive phrases that help to make clear the relationship between the two column values. If you try using a single-word alias and MySQL complains about it, the alias probably is a reserved word. Quoting it should make it legal: mysql> SELECT 1 AS INTEGER; You have an error in your SQL syntax near 'INTEGER' at line 1 mysql> SELECT 1 AS 'INTEGER'; +---------+ | INTEGER | +---------+ | 1 | +---------+ 3.5 Using Column Aliases to Make Programs Easier to Write 3.5.1 Problem You're trying to refer to a column by name from within a program, but the column is calculated from an expression. Consequently, it's difficult to use. 3.5.2 Solution Use an alias to give the column a simpler name. 3.5.3 Discussion If you're writing a program that fetches rows into an array and accesses them by numeric column indexes, the presence or absence of column aliases makes no difference, because aliases don't change the positions of columns within the result set. However, aliases make a big difference if you're accessing output columns by name, because aliases change those names. You can exploit this fact to give your program easier names to work with. For example, if your query displays reformatted message time values from the mail table using the expression DATE_FORMAT(t,'%M %e, %Y'), that expression is also the name you'd have to use when referring to the output column. That's not very convenient. If you use AS date_sent to give the column an alias, you can refer to it a lot more easily using the name date_sent. Here's an example that shows how a Perl DBI script might process such values: $sth = $dbh->prepare ( "SELECT srcuser, DATE_FORMAT(t,'%M %e, %Y') AS date_sent FROM mail"); $sth->execute ( ); while (my $ref = $sth->fetchrow_hashref ( )) { printf "user: %s, date sent: %s\n", $ref->{srcuser}, $ref->{date_sent}; } In Java, you'd do something like this: Statement s = conn.createStatement ( ); s.executeQuery ("SELECT srcuser," + " DATE_FORMAT(t,'%M %e, %Y') AS date_sent" + " FROM mail"); ResultSet rs = s.getResultSet ( ); while (rs.next ( )) // loop through rows of result set { String name = rs.getString ("srcuser"); String dateSent = rs.getString ("date_sent"); System.out.println ("user: " + name + ", date sent: " + dateSent); } rs.close ( ); s.close ( ); In PHP, retrieve result set rows using mysql_fetch_array( ) or mysql_fetch_object( ) to fetch rows into a data structure that contains named elements. With Python, use a cursor class that causes rows to be returned as dictionaries containing key/value pairs where the keys are the column names. (See Recipe 2.5.) 3.6 Combining Columns to Construct Composite Values 3.6.1 Problem You want to display values that are constructed from multiple table columns. 3.6.2 Solution One way to do this is to use CONCAT( ). You might also want to give the column a nicer name by using an alias. 3.6.3 Discussion Column values may be combined to produce composite output values. For example, this expression concatenates srcuser and srchost values into email address format: CONCAT(srcuser,'@',srchost) Such expressions tend to produce ugly column names, which is yet another reason why column aliases are useful. The following query uses the aliases sender and recipient to name output columns that are constructed by combining usernames and hostnames into email addresses: mysql> SELECT -> DATE_FORMAT(t,'%M %e, %Y') AS date_sent, -> CONCAT(srcuser,'@',srchost) AS sender, -> CONCAT(dstuser,'@',dsthost) AS recipient, -> size FROM mail; +--------------+---------------+---------------+---------+ | date_sent | sender | recipient | size | +--------------+---------------+---------------+---------+ | May 11, 2001 | barb@saturn | tricia@mars | 58274 | | May 12, 2001 | tricia@mars | gene@venus | 194925 | | May 12, 2001 | phil@mars | phil@saturn | 1048 | | May 13, 2001 | barb@saturn | tricia@venus | 271 | ... .7 Specifying Which Rows to Select 3.7.1 Problem You don't want to see all the rows from a table, just some of them. 3.7.2 Solution Add a WHERE clause to the query that indicates to the server which rows to return. 3.7.3 Discussion Unless you qualify or restrict a SELECT query in some way, it retrieves every row in your table, which may be a lot more information than you really want to see. To be more precise about the rows to select, provide a WHERE clause that specifies one or more conditions that rows must match. Conditions can perform tests for equality, inequality, or relative ordering. For some column types such as strings, you can use pattern matches. The following queries select columns from rows containing srchost values that are exactly equal to the string 'venus', that are lexically less than the string 'pluto', or that begin with the letter 's': mysql> SELECT t, srcuser, srchost FROM mail WHERE srchost = 'venus'; +---------------------+---------+---------+ | t | srcuser | srchost | +---------------------+---------+---------+ | 2001-05-14 09:31:37 | gene | venus | | 2001-05-14 14:42:21 | barb | venus | | 2001-05-15 08:50:57 | phil | venus | | 2001-05-16 09:00:28 | gene | venus | | 2001-05-16 23:04:19 | phil | venus | +---------------------+---------+---------+ mysql> SELECT t, srcuser, srchost FROM mail WHERE srchost < 'pluto'; +---------------------+---------+---------+ | t | srcuser | srchost | +---------------------+---------+---------+ | 2001-05-12 12:48:13 | tricia | mars | | 2001-05-12 15:02:49 | phil | mars | | 2001-05-14 11:52:17 | phil | mars | | 2001-05-15 07:17:48 | gene | mars | | 2001-05-15 10:25:52 | gene | mars | | 2001-05-17 12:49:23 | phil | mars | +---------------------+---------+---------+ mysql> SELECT t, srcuser, srchost FROM mail WHERE srchost LIKE 's%'; +---------------------+---------+---------+ | t | srcuser | srchost | +---------------------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | | 2001-05-13 13:59:18 | barb | saturn | | 2001-05-14 17:03:01 | tricia | saturn | | 2001-05-15 17:35:31 | gene | saturn | | 2001-05-19 22:21:51 | gene | saturn | +---------------------+---------+---------+ WHERE clauses can test multiple conditions. The following statement looks for rows where the srcuser column has any of three different values. (It asks the question, "When did gene, barb, or phil send mail?"): mysql> SELECT t, srcuser, dstuser FROM mail -> WHERE srcuser = 'gene' OR srcuser = 'barb' OR srcuser = 'phil'; +---------------------+---------+---------+ | t | srcuser | dstuser | +---------------------+---------+---------+ | 2001-05-11 10:15:08 | barb | tricia | | 2001-05-12 15:02:49 | phil | phil | | 2001-05-13 13:59:18 | barb | tricia | | 2001-05-14 09:31:37 | gene | barb | ... Queries such as the preceding one that test a given column to see if it has any of several different values often can be written more easily by using the IN( ) operator. IN( ) is true if the column is equal to any value in its argument list: mysql> SELECT t, srcuser, dstuser FROM mail -> WHERE srcuser IN ('gene','barb','phil'); +---------------------+---------+---------+ | t | srcuser | dstuser | +---------------------+---------+---------+ | 2001-05-11 10:15:08 | barb | tricia | | 2001-05-12 15:02:49 | phil | phil | | 2001-05-13 13:59:18 | barb | tricia | | 2001-05-14 09:31:37 | gene | barb | ... Different conditions can test different columns. This query finds messages sent by barb to tricia: mysql> SELECT * FROM mail WHERE srcuser = 'barb' AND dstuser = 'tricia'; +---------------------+---------+---------+---------+---------+-------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+-------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | +---------------------+---------+---------+---------+---------+-------+ Comparisons need only be legal syntactically; they need not make any sense semantically. The comparison in the following query doesn't have a particularly obvious meaning, but MySQL will happily execute it:[1] [1] If you try issuing the query to see what it returns, how do you account for the result? SELECT * FROM mail WHERE srcuser + dsthost < size Are Queries That Return No Rows Failed Queries? If you issue a SELECT statement and get no rows back, has the query failed? It depends. If the lack of a result set is due to a problem such as that the statement is syntactically invalid or refers to nonexisting tables or columns, the query did indeed fail, because it could not even be executed. In this case, some sort of error condition should occur and you should investigate why your program is attempting to issue a malformed statement. If the query executes without error but returns nothing, it simply means that the query's WHERE clause matched no rows: mysql> SELECT * FROM mail WHERE srcuser = 'no-such-user'; Empty set (0.01 sec) This is not a failed query. It ran successfully and produced a result; the result just happens to be empty because no rows have a srcuser value of no-such-user. Columns need not be compared to literal values. You can test a column against other columns. Suppose you have a cd table lying around that contains year, artist, and title columns:[2] [2] It's not unlikely you'll have such a table if you've been reading other database books. Many of these have you go through the exercise of creating a database to keep track of your CD collection, a scenario that seems to rank second in popularity only to parts-and-suppliers examples. mysql> SELECT year, artist, title FROM cd; +------+-----------------+-----------------------+ | year | artist | title | +------+-----------------+-----------------------+ | 1990 | Iona | Iona | | 1992 | Charlie Peacock | Lie Down in the Grass | | 1993 | Iona | Beyond These Shores | | 1987 | The 77s | The 77s | | 1990 | Michael Gettel | Return | | 1989 | Richard Souther | Cross Currents | | 1996 | Charlie Peacock | strangelanguage | | 1982 | Undercover | Undercover | ... If so, you can find all your eponymous CDs (those with artist and title the same) by performing a comparison of one column within the table to another: mysql> SELECT year, artist, title FROM cd WHERE artist = title; +------+------------+------------+ | year | artist | title | +------+------------+------------+ | 1990 | Iona | Iona | | 1987 | The 77s | The 77s | | 1982 | Undercover | Undercover | +------+------------+------------+ A special case of within-table column comparison occurs when you want to compare a column to itself rather than to a different column. Suppose you collect stamps and list your collection in a stamp table that contains columns for each stamp's ID number and the year it was issued. If you know that a particular stamp has an ID number 42 and want to use the value in its year column to find the other stamps in your collection that were issued in the same year, you'd do so by using year-to-year comparison—in effect, comparing the year column to itself: mysql> SELECT stamp.* FROM stamp, stamp AS stamp2 -> WHERE stamp.year = stamp2.year AND stamp2.id = 42 AND stamp.id != 42; +-----+------+-------------------------+ | id | year | description | +-----+------+-------------------------+ | 97 | 1987 | 1-cent transition stamp | | 161 | 1987 | aviation stamp | +-----+------+-------------------------+ This kind of query involves a self-join, table aliases, and column references that are qualified using the table name. But that's more than I want to go into here. Those topics are covered in Chapter 12. 3.8 WHERE Clauses and Column Aliases 3.8.1 Problem You want to refer to a column alias in a WHERE clause. 3.8.2 Solution Sorry, you cannot. 3.8.3 Discussion You cannot refer to column aliases in a WHERE clause. Thus, the following query is illegal: mysql> SELECT t, srcuser, dstuser, size/1024 AS kilobytes -> FROM mail WHERE kilobytes > 500; ERROR 1054 at line 1: Unknown column 'kilobytes' in 'where clause' The error occurs because aliases name output columns, whereas a WHERE clause operates on input columns to determine which rows to select for output. To make the query legal, replace the alias in the WHERE clause with the column or expression that the alias represents: mysql> SELECT t, srcuser, dstuser, size/1024 AS kilobytes -> FROM mail WHERE size/1024 > 500; +---------------------+---------+---------+-----------+ | t | srcuser | dstuser | kilobytes | +---------------------+---------+---------+-----------+ | 2001-05-14 17:03:01 | tricia | phil | 2338.36 | | 2001-05-15 10:25:52 | gene | tricia | 975.13 | +---------------------+---------+---------+-----------+ 3.9 Displaying Comparisons to Find Out How Something Works 3.9.1 Problem You're curious about how a comparison in a WHERE clause works. Or perhaps about why it doesn't seem to be working. 3.9.2 Solution Display the result of the comparison to get more information about it. This is a useful diagnostic or debugging technique. 3.9.3 Discussion Normally you put comparison operations in the WHERE clause of a query and use them to determine which records to display: mysql> SELECT * FROM mail WHERE srcuser < 'c' AND size > 5000; +---------------------+---------+---------+---------+---------+-------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+-------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-14 14:42:21 | barb | venus | barb | venus | 98151 | +---------------------+---------+---------+---------+---------+-------+ But sometimes it's desirable to see the result of the comparison itself (for example, if you're not sure that the comparison is working the way you expect it to). To do this, just put the comparison expression in the output column list, perhaps including the values that you're comparing as well: mysql> SELECT srcuser, srcuser < 'c', size, size > 5000 FROM mail; +---------+---------------+---------+-------------+ | srcuser | srcuser < 'c' | size | size > 5000 | +---------+---------------+---------+-------------+ | barb | 1 | 58274 | 1 | | tricia | 0 | 194925 | 1 | | phil | 0 | 1048 | 0 | | barb | 1 | 271 | 0 | ... This technique of displaying comparison results is particularly useful for writing queries that check how a test works without using a table: mysql> SELECT 'a' = 'A'; +-----------+ | 'a' = 'A' | +-----------+ | 1 | +-----------+ This query result tells you that string comparisons are not by default case sensitive, which is a useful thing to know. 3.10 Reversing or Negating Query Conditions 3.10.1 Problem You know how to write a query to answer a given question; now you want to ask the opposite question. 3.10.2 Solution Reverse the conditions in the WHERE clause by using negation operators. 3.10.3 Discussion The WHERE conditions in a query can be negated to ask the opposite questions. The following query determines when users sent mail to themselves: mysql> SELECT * FROM mail WHERE srcuser = dstuser; +---------------------+---------+---------+---------+---------+-------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+-------+ | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-14 14:42:21 | barb | venus | barb | venus | 98151 | | 2001-05-15 07:17:48 | gene | mars | gene | saturn | 3824 | | 2001-05-15 08:50:57 | phil | venus | phil | venus | 978 | | 2001-05-15 17:35:31 | gene | saturn | gene | mars | 3856 | | 2001-05-19 22:21:51 | gene | saturn | gene | venus | 23992 | +---------------------+---------+---------+---------+---------+-------+ To reverse this query, to find records where users sent mail to someone other than themselves, change the comparison operator from = (equal to) to != (not equal to): mysql> SELECT * FROM mail WHERE srcuser != dstuser; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | | 2001-05-14 09:31:37 | gene | venus | barb | mars | 2291 | ... A more complex query using two conditions might ask when people sent mail to themselves on the same machine: mysql> SELECT * FROM mail WHERE srcuser = dstuser AND srchost = dsthost; +---------------------+---------+---------+---------+---------+-------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+-------+ | 2001-05-14 14:42:21 | barb | venus | barb | venus | 98151 | | 2001-05-15 08:50:57 | phil | venus | phil | venus | 978 | +---------------------+---------+---------+---------+---------+-------+ Reversing the conditions for this query involves not only changing the = operators to !=, but changing the AND to OR: mysql> SELECT * FROM mail WHERE srcuser != dstuser OR srchost != dsthost; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | ... You may find it easier just to put the entire original expression in parentheses and negate the whole thing with NOT: mysql> SELECT * FROM mail WHERE NOT (srcuser = dstuser AND srchost = dsthost); +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | ... 3.10.4 See Also If a column involved in a condition may contain NULL values, reversing the condition is a little trickier. See Recipe 3.13 for details. 3.11 Removing Duplicate Rows 3.11.1 Problem Output from a query contains duplicate records. You want to eliminate them. 3.11.2 Solution Use DISTINCT. 3.11.3 Discussion Some queries produce results containing duplicate records. For example, to see who sent mail, you could query the mail table like this: mysql> SELECT srcuser FROM mail; +---------+ | srcuser | +---------+ | barb | | tricia | | phil | | barb | | gene | | phil | | barb | | tricia | | gene | | phil | | gene | | gene | | gene | | phil | | phil | | gene | +---------+ But that result is heavily redundant. Adding DISTINCT to the query removes the duplicate records, producing a set of unique values: mysql> SELECT DISTINCT srcuser FROM mail; +---------+ | srcuser | +---------+ | barb | | tricia | | phil | | gene | +---------+ DISTINCT works with multiple-column output, too. The following query shows which dates are represented in the mail table: mysql> SELECT DISTINCT YEAR(t), MONTH(t), DAYOFMONTH(t) FROM mail; +---------+----------+---------------+ | YEAR(t) | MONTH(t) | DAYOFMONTH(t) | +---------+----------+---------------+ | 2001 | 5 | 11 | | 2001 | 5 | 12 | | 2001 | 5 | 13 | | 2001 | 5 | 14 | | 2001 | 5 | 15 | | 2001 | 5 | 16 | | 2001 | 5 | 17 | | 2001 | 5 | 19 | +---------+----------+---------------+ To count the number of unique values, do this: mysql> SELECT COUNT(DISTINCT srcuser) FROM mail; +-------------------------+ | COUNT(DISTINCT srcuser) | +-------------------------+ | 4 | +-------------------------+ COUNT(DISTINCT) requires MySQL 3.23.2 or higher. 3.11.4 See Also DISTINCT is revisited in Chapter 7. Duplicate removal is discussed in more detail in Chapter 14. 3.12 Working with NULL Values 3.12.1 Problem You're trying to compare column values to NULL, but it isn't working. 3.12.2 Solution You have to use the proper comparison operators: IS NULL, IS NOT NULL, or <=>. 3.12.3 Discussion Conditions involving NULL are special. You cannot use = NULL or != NULL to look for NULL values in columns. Such comparisons always fail because it's impossible to tell whether or not they are true. Even NULL = NULL fails. (Why? Because you can't determine whether one unknown value is the same as another unknown value.) To look for columns that are or are not NULL, use IS NULL or IS NOT NULL. Suppose a table taxpayer contains taxpayer names and ID numbers, where a NULL ID indicates that the value is unknown: mysql> SELECT * FROM taxpayer; +---------+--------+ | name | id | +---------+--------+ | bernina | 198-48 | | bertha | NULL | | ben | NULL | | bill | 475-83 | +---------+--------+ You can see that = and != do not work with NULL values as follows: mysql> SELECT * FROM taxpayer WHERE id = NULL; Empty set (0.00 sec) mysql> SELECT * FROM taxpayer WHERE id != NULL; Empty set (0.01 sec) To find records where the id column is or is not NULL, the queries should be written like this: mysql> SELECT * FROM taxpayer WHERE id IS NULL; +--------+------+ | name | id | +--------+------+ | bertha | NULL | | ben | NULL | +--------+------+ mysql> SELECT * FROM taxpayer WHERE id IS NOT NULL; +---------+--------+ | name | id | +---------+--------+ | bernina | 198-48 | | bill | 475-83 | +---------+--------+ As of MySQL 3.23, you can also use <=> to compare values, which (unlike the = operator) is true even for two NULL values: mysql> SELECT NULL = NULL, NULL <=> NULL; +-------------+---------------+ | NULL = NULL | NULL <=> NULL | +-------------+---------------+ | NULL | 1 | +-------------+---------------+ 3.12.4 See Also NULL values also behave specially with respect to sorting and summary operations. See Recipe 6.6 and Recipe 7.9. 3.13 Negating a Condition on a Column That Contains NULL Values 3.13.1 Problem You're trying to negate a condition that involves NULL, but it's not working. 3.13.2 Solution NULL is special in negations, just like it is otherwise. Perhaps even more so. 3.13.3 Discussion Recipe 3.10 pointed out that you can reverse query conditions, either by changing comparison operators and Boolean operators, or by using NOT. These techniques may not work if a column can contain NULL. Recall that the taxpayer table from Recipe 3.12 looks like this: +---------+--------+ | name | id | +---------+--------+ | bernina | 198-48 | | bertha | NULL | | ben | NULL | | bill | 475-83 | +---------+--------+ Now suppose you have a query that finds records with taxpayer ID values that are lexically less than 200-00: mysql> SELECT * FROM taxpayer WHERE id < '200-00'; +---------+--------+ | name | id | +---------+--------+ | bernina | 198-48 | +---------+--------+ Reversing this condition by using >= rather than < may not give you the results you want. It depends on what information you want to obtain. If you want to select only records with non- NULL ID values, >= is indeed the proper test: mysql> SELECT * FROM taxpayer WHERE id >= '200-00'; +------+--------+ | name | id | +------+--------+ | bill | 475-83 | +------+--------+ But if you want all the records not selected by the original query, simply reversing the operator will not work. NULL values fail comparisons both with < and with >=, so you must add an additional clause specifically for them: mysql> SELECT * FROM taxpayer WHERE id >= '200-00' OR id IS NULL; +--------+--------+ | name | id | +--------+--------+ | bertha | NULL | | ben | NULL | | bill | 475-83 | +--------+--------+ 3.14 Writing Comparisons Involving NULL in Programs 3.14.1 Problem You're writing a program that issues a query, but it fails for NULL values. 3.14.2 Solution Try writing the comparison selectively for NULL and non-NULL values. 3.14.3 Discussion The need to use different comparison operators for NULL values than for non-NULL values leads to a subtle danger when constructing query strings within programs. If you have a value stored in a variable that might represent a NULL value, you must account for that if you use the value in comparisons. For example, in Perl, undef represents a NULL value, so to construct a statement that finds records in the taxpayer table matching some arbitrary value in an $id variable, you cannot do this: $sth = $dbh->prepare ("SELECT * FROM taxpayer WHERE id = ?"); $sth->execute ($id); The statement fails when $id is undef, because the resulting query becomes: SELECT * FROM taxpayer WHERE id = NULL That statement returns no records—a comparison of = NULL always fails. To take into account the possibility that $id may be undef, construct the query using the appropriate comparison operator like this: $operator = (defined ($id) ? "=" : "IS"); $sth = $dbh->prepare ("SELECT * FROM taxpayer WHERE id $operator ?"); $sth->execute ($id); This results in queries as follows for $id values of undef (NULL) or 43 (not NULL): SELECT * FROM taxpayer WHERE id IS NULL SELECT * FROM taxpayer WHERE id = 43 For inequality tests, set $operator like this instead: $operator = (defined ($id) ? "!=" : "IS NOT"); 3.15 Mapping NULL Values to Other Values for Display 3.15.1 Problem A query's output includes NULL values, but you'd rather see something more meaningful, like "Unknown." 3.15.2 Solution Convert NULL values selectively to another value when displaying them. You can also use this technique to catch divide-by-zero errors. 3.15.3 Discussion Sometimes it's useful to display NULL values using some other distinctive value that has more meaning in the context of your application. If NULL id values in the taxpayer table mean "unknown," you can display that label by using IF( ) to map them onto the string Unknown: mysql> SELECT name, IF(id IS NULL,'Unknown', id) AS 'id' FROM taxpayer; +---------+---------+ | name | id | +---------+---------+ | bernina | 198-48 | | bertha | Unknown | | ben | Unknown | | bill | 475-83 | +---------+---------+ Actually, this technique works for any kind of value, but it's especially useful with NULL values because they tend to be given a variety of meanings: unknown, missing, not yet determined, out of range, and so forth. The query can be written more concisely using IFNULL( ), which tests its first argument and returns it if it's not NULL, or returns its second argument otherwise: mysql> SELECT name, IFNULL(id,'Unknown') AS 'id' FROM taxpayer; +---------+---------+ | name | id | +---------+---------+ | bernina | 198-48 | | bertha | Unknown | | ben | Unknown | | bill | 475-83 | +---------+---------+ In other words, these two tests are equivalent: IF(expr1 IS NOT NULL,expr1,expr2) IFNULL(expr1,expr2) From a readability standpoint, IF( ) often is easier to understand than IFNULL( ). From a computational perspective, IFNULL( ) is more efficient because expr1 never need be evaluated twice, as sometimes happens with IF( ). IF( ) and IFNULL( ) are especially useful for catching divide-by-zero operations and mapping them onto something else. For example, batting averages for baseball players are calculated as the ratio of hits to at-bats. But if a player has no at-bats, the ratio is undefined: mysql> SET @hits = 0, @atbats = 0; mysql> SELECT @hits, @atbats, @hits/@atbats AS 'batting average'; +-------+---------+-----------------+ | @hits | @atbats | batting average | +-------+---------+-----------------+ | 0 | 0 | NULL | +-------+---------+-----------------+ To handle that case by displaying zero, do this: mysql> SET @hits = 0, @atbats = 0; mysql> SELECT @hits, @atbats, IFNULL(@hits/@atbats,0) AS 'batting average'; +-------+---------+-----------------+ | @hits | @atbats | batting average | +-------+---------+-----------------+ | 0 | 0 | 0 | +-------+---------+-----------------+ Earned run average calculations for a pitcher with no innings pitched can be treated the same way. Other common uses for this idiom are as follows: IFNULL(expr,'Missing') IFNULL(expr,'N/A') IFNULL(expr,'Unknown') 3.16 Sorting a Result Set 3.16.1 Problem Your query results aren't sorted the way you want. 3.16.2 Solution MySQL can't read your mind. Add an ORDER BY clause to tell it exactly how you want things sorted. 3.16.3 Discussion When you select rows, the MySQL server is free to return them in any order, unless you instruct it otherwise by saying how to sort the result. There are lots of ways to use sorting techniques. Chapter 6 explores this topic further. Briefly, you sort a result set by adding an ORDER BY clause that names the column or columns you want to sort by: mysql> SELECT * FROM mail WHERE size > 100000 ORDER BY size; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-14 17:03:01 | tricia | saturn | phil | venus | 2394482 | +---------------------+---------+---------+---------+---------+---------+ mysql> SELECT * FROM mail WHERE dstuser = 'tricia' -> ORDER BY srchost, srcuser; +---------------------+---------+---------+---------+---------+--------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+--------+ | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-14 11:52:17 | phil | mars | tricia | saturn | 5781 | | 2001-05-17 12:49:23 | phil | mars | tricia | saturn | 873 | | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | +---------------------+---------+---------+---------+---------+--------+ To sort a column in reverse (descending) order, add the keyword DESC after its name in the ORDER BY clause: mysql> SELECT * FROM mail WHERE size > 50000 ORDER BY size DESC; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-14 17:03:01 | tricia | saturn | phil | venus | 2394482 | | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-14 14:42:21 | barb | venus | barb | venus | 98151 | | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | +---------------------+---------+---------+---------+---------+---------+ 3.17 Selecting Records from the Beginning or End of a Result Set 3.17.1 Problem You want to see only certain rows from a result set, like the first one or the last five. 3.17.2 Solution Use a LIMIT clause, perhaps in conjunction with an ORDER BY clause. 3.17.3 Discussion MySQL supports a LIMIT clause that tells the server to return only part of a result set. LIMIT is a MySQL-specific extension to SQL that is extremely valuable when your result set contains more rows than you want to see at a time. It allows you to retrieve just the first part of a result set or an arbitrary section of the set. Typically, LIMIT is used for the following kinds of problems: · Answering questions about first or last, largest or smallest, newest or oldest, least or more expensive, and so forth. · Splitting a result set into sections so that you can process it one piece at a time. This technique is common in web applications for displaying a large search result across several pages. Showing the result in sections allows display of smaller pages that are easier to understand. The following examples use the profile table that was introduced in Chapter 2. Its contents look like this: mysql> SELECT * FROM profile; +----+---------+------------+-------+-----------------------+------+ | id | name | birth | color | foods | cats | +----+---------+------------+-------+-----------------------+------+ | 1 | Fred | 1970-04-13 | black | lutefisk,fadge,pizza | 0 | | 2 | Mort | 1969-09-30 | white | burrito,curry,eggroll | 3 | | 3 | Brit | 1957-12-01 | red | burrito,curry,pizza | 1 | | 4 | Carl | 1973-11-02 | red | eggroll,pizza | 4 | | 5 | Sean | 1963-07-04 | blue | burrito,curry | 5 | | 6 | Alan | 1965-02-14 | red | curry,fadge | 1 | | 7 | Mara | 1968-09-17 | green | lutefisk,fadge | 1 | | 8 | Shepard | 1975-09-02 | black | curry,pizza | 2 | | 9 | Dick | 1952-08-20 | green | lutefisk,fadge | 0 | | 10 | Tony | 1960-05-01 | white | burrito,pizza | 0 | +----+---------+------------+-------+-----------------------+------+ To select the first n records of a query result, add LIMIT n to the end of your SELECT statement: mysql> SELECT * FROM profile LIMIT 1; +----+------+------------+-------+----------------------+------+ | id | name | birth | color | foods | cats | +----+------+------------+-------+----------------------+------+ | 1 | Fred | 1970-04-13 | black | lutefisk,fadge,pizza | 0 | +----+------+------------+-------+----------------------+------+ mysql> SELECT * FROM profile LIMIT 5; +----+------+------------+-------+-----------------------+------+ | id | name | birth | color | foods | cats | +----+------+------------+-------+-----------------------+------+ | 1 | Fred | 1970-04-13 | black | lutefisk,fadge,pizza | 0 | | 2 | Mort | 1969-09-30 | white | burrito,curry,eggroll | 3 | | 3 | Brit | 1957-12-01 | red | burrito,curry,pizza | 1 | | 4 | Carl | 1973-11-02 | red | eggroll,pizza | 4 | | 5 | Sean | 1963-07-04 | blue | burrito,curry | 5 | +----+------+------------+-------+-----------------------+------+ However, because the rows in these query results aren't sorted into any particular order, they may not be very meaningful. A more common technique is to use ORDER BY to sort the result set. Then you can use LIMIT to find smallest and largest values. For example, to find the row with the minimum (earliest) birth date, sort by the birth column, then add LIMIT 1 to retrieve the first row: mysql> SELECT * FROM profile ORDER BY birth LIMIT 1; +----+------+------------+-------+----------------+------+ | id | name | birth | color | foods | cats | +----+------+------------+-------+----------------+------+ | 9 | Dick | 1952-08-20 | green | lutefisk,fadge | 0 | +----+------+------------+-------+----------------+------+ This works because MySQL processes the ORDER BY clause to sort the rows first, then applies LIMIT. To find the row with the most recent birth date, the query is similar, except that you sort in descending order: mysql> SELECT * FROM profile ORDER BY birth DESC LIMIT 1; +----+---------+------------+-------+-------------+------+ | id | name | birth | color | foods | cats | +----+---------+------------+-------+-------------+------+ | 8 | Shepard | 1975-09-02 | black | curry,pizza | 2 | +----+---------+------------+-------+-------------+------+ You can obtain the same information by running these queries without LIMIT and ignoring everything but the first row. The advantage of using LIMIT is that the server returns just the first record and the extra rows don't travel over the network at all. This is much more efficient than retrieving an entire result set, only to discard all but one row. The sort column or columns can be whatever you like. To find the row for the person with the most cats, sort by the cats column: mysql> SELECT * FROM profile ORDER BY cats DESC LIMIT 1; +----+------+------------+-------+---------------+------+ | id | name | birth | color | foods | cats | +----+------+------------+-------+---------------+------+ | 5 | Sean | 1963-07-04 | blue | burrito,curry | 5 | +----+------+------------+-------+---------------+------+ However, be aware that using LIMIT n to select the "n smallest" or "n largest" values may not yield quite the results you expect. See Recipe 3.19 for some discussion on framing LIMIT queries appropriately. To find the earliest birthday within the calendar year, sort by the month and day of the birth values: mysql> SELECT name, DATE_FORMAT(birth,'%m-%e') AS birthday -> FROM profile ORDER BY birthday LIMIT 1; +------+----------+ | name | birthday | +------+----------+ | Alan | 02-14 | +------+----------+ Note that LIMIT n really means "return at most n rows." If you specify LIMIT 10 and the result set has only 3 rows, the server returns 3 rows. 3.17.4 See Also You can use LIMIT in combination with RAND( ) to make random selections from a set of items. See Chapter 13. As of MySQL 3.22.7, you can use LIMIT to restrict the effect of a DELETE statement to a subset of the rows that would otherwise be deleted. As of MySQL 3.23.3, the same is true for UPDATE. This can be useful in conjunction with a WHERE clause. For example, if a table contains five instances of a record, you can select them in a DELETE statement with an appropriate WHERE clause, then remove the duplicates by adding LIMIT 4 to the end of the statement. This leaves only one copy of the record. For more information about uses of LIMIT in duplicate record removal, see Chapter 14. 3.18 Pulling a Section from the Middle of a Result Set 3.18.1 Problem You don't want the first or last rows of a result set. Instead, you want to pull a section of rows out of the middle of the set, such as rows 21 through 40. 3.18.2 Solution That's still a job for LIMIT. But you need to tell it the starting position within the result set in addition to the number of rows you want. 3.18.3 Discussion LIMIT n tells the server to return the first n rows of a result set. LIMIT also has a two- argument form that allows you to pick out any arbitrary section of rows from a result. The arguments indicate how many rows to skip and how many to return. This means that you can use LIMIT to do such things as skip two rows and return the next, thus answering questions such as "what is the third-smallest or third-largest value?," something that's more difficult with MIN( ) or MAX( ): mysql> SELECT * FROM profile ORDER BY birth LIMIT 2,1; +----+------+------------+-------+---------------+------+ | id | name | birth | color | foods | cats | +----+------+------------+-------+---------------+------+ | 10 | Tony | 1960-05-01 | white | burrito,pizza | 0 | +----+------+------------+-------+---------------+------+ mysql> SELECT * FROM profile ORDER BY birth DESC LIMIT 2,1; +----+------+------------+-------+----------------------+------+ | id | name | birth | color | foods | cats | +----+------+------------+-------+----------------------+------+ | 1 | Fred | 1970-04-13 | black | lutefisk,fadge,pizza | 0 | +----+------+------------+-------+----------------------+------+ The two-argument form of LIMIT also makes it possible to partition a result set into smaller sections. For example, to retrieve 20 rows at a time from a result, issue the same SELECT statement repeatedly, but vary the LIMIT clauses like so: SELECT ... FROM ... ORDER BY ... LIMIT 0, 20; retrieve first 20 rows SELECT ... FROM ... ORDER BY ... LIMIT 20, 20; skip 20 rows, retrieve next 20 SELECT ... FROM ... ORDER BY ... LIMIT 40, 20; skip 40 rows, retrieve next 20 etc. Web developers often use LIMIT this way to split a large search result into smaller, more manageable pieces so that it can be presented over several pages. We'll discuss this technique further in Recipe 18.11. If you want to know how large a result set is so that you can determine how many sections there are, you can issue a COUNT( ) query first. Use a WHERE clause that is the same as for the queries you'll use to retrieve the rows. For example, if you want to display profile table records in name order four at a time, you can find out how many there are with the following query: mysql> SELECT COUNT(*) FROM profile; +----------+ | COUNT(*) | +----------+ | 10 | +----------+ That tells you you'll have three sets of rows (although the last one will have fewer than four records), which you can retrieve as follows: SELECT * FROM profile ORDER BY name LIMIT 0, 4; SELECT * FROM profile ORDER BY name LIMIT 4, 4; SELECT * FROM profile ORDER BY name LIMIT 8, 4; Beginning with MySQL 4.0, you can fetch a part of a result set, but also find out how big the result would have been without the LIMIT clause. For example, to fetch the first four records from the profile table and then obtain the size of the full result, run these queries: SELECT SQL_CALC_FOUND_ROWS * FROM profile ORDER BY name LIMIT 4; SELECT FOUND_ROWS( ); The keyword SQL_CALC_FOUND_ROWS in the first query tells MySQL to calculate the size of the entire result set even though the query requests that only part of it be returned. The row count is available by calling FOUND_ROWS( ). If that function returns a value greater than four, there are other records yet to be retrieved. 3.19 Choosing Appropriate LIMIT Values 3.19.1 Problem LIMIT doesn't seem to do what you want it to. 3.19.2 Solution Be sure you understand what question you're asking. It may be that LIMIT is exposing some interesting subtleties in your data that you have not considered or are not aware of. 3.19.3 Discussion LIMIT n is useful in conjunction with ORDER BY for selecting smallest or largest values from a result set. But does that actually give you the rows with the n smallest or largest values? Not necessarily! It does if your rows contain unique values, but not if there are duplicates. You may find it necessary to run a preliminary query first to help you choose the proper LIMIT value. To see why this is, consider the following dataset, which shows the American League pitchers who won 15 or more games during the 2001 baseball season: mysql> SELECT name, wins FROM al_winner -> ORDER BY wins DESC, name; +----------------+------+ | name | wins | +----------------+------+ | Mulder, Mark | 21 | | Clemens, Roger | 20 | | Moyer, Jamie | 20 | | Garcia, Freddy | 18 | | Hudson, Tim | 18 | | Abbott, Paul | 17 | | Mays, Joe | 17 | | Mussina, Mike | 17 | | Sabathia, C.C. | 17 | | Zito, Barry | 17 | | Buehrle, Mark | 16 | | Milton, Eric | 15 | | Pettitte, Andy | 15 | | Radke, Brad | 15 | | Sele, Aaron | 15 | +----------------+------+ If you want to know who won the most games, adding LIMIT 1 to the preceding query will give you the correct answer, because the maximum value is 21 and there is only one pitcher with that value (Mark Mulder). But what if you want the four highest game winners? The proper queries depend on what you mean by that, which can have various interpretations: · If you just want the first four rows, sort the records and add LIMIT 4: mysql> SELECT name, wins FROM al_winner -> ORDER BY wins DESC, name -> LIMIT 4; +----------------+------+ | name | wins | +----------------+------+ | Mulder, Mark | 21 | | Clemens, Roger | 20 | | Moyer, Jamie | 20 | | Garcia, Freddy | 18 | +----------------+------+ That may not suit your purposes because LIMIT imposes a cutoff that occurs in the middle of a set of pitchers with the same number of wins (Tim Hudson also won 18 games). · To avoid making a cutoff in the middle of a set of rows with the same value, select rows with values greater than or equal to the value in the fourth row. Find out what that value is with LIMIT, then use it in the WHERE clause of a second query to select rows: mysql> SELECT wins FROM al_winner -> ORDER BY wins DESC, name -> LIMIT 3, 1; +------+ | wins | +------+ | 18 | +------+ mysql> SELECT name, wins FROM al_winner -> WHERE wins >= 18 -> ORDER BY wins DESC, name; +----------------+------+ | name | wins | +----------------+------+ | Mulder, Mark | 21 | | Clemens, Roger | 20 | | Moyer, Jamie | 20 | | Garcia, Freddy | 18 | | Hudson, Tim | 18 | +----------------+------+ · If you want to know all the pitchers with the four largest wins values, another approach is needed. Determine the fourth-largest value with DISTINCT and LIMIT, then use it to select rows: mysql> SELECT DISTINCT wins FROM al_winner -> ORDER BY wins DESC, name -> LIMIT 3, 1; +------+ | wins | +------+ | 17 | +------+ mysql> SELECT name, wins FROM al_winner -> WHERE wins >= 17 -> ORDER BY wins DESC, name; +----------------+------+ | name | wins | +----------------+------+ | Mulder, Mark | 21 | | Clemens, Roger | 20 | | Moyer, Jamie | 20 | | Garcia, Freddy | 18 | | Hudson, Tim | 18 | | Abbott, Paul | 17 | | Mays, Joe | 17 | | Mussina, Mike | 17 | | Sabathia, C.C. | 17 | | Zito, Barry | 17 | +----------------+------+ For this dataset, each method yields a different result. The moral is that the way you use LIMIT may require some thought about what you really want to know. 3.20 Calculating LIMIT Values from Expressions 3.20.1 Problem You want to use expressions to specify the arguments for LIMIT. 3.20.2 Solution Sadly, you cannot. You can use only literal integers—unless you issue the query from within a program, in which case you can evaluate the expressions yourself and stick the resulting values into the query string. 3.20.3 Discussion Arguments to LIMIT must be literal integers, not expressions. Statements such as the following are illegal: SELECT * FROM profile LIMIT 5+5; SELECT * FROM profile LIMIT @skip_count, @show_count; The same "no expressions allowed" principle applies if you're using an expression to calculate a LIMIT value in a program that constructs a query string. You must evaluate the expression first, then place the resulting value in the query. For example, if you produce a query string in Perl (or PHP) as follows, an error will result when you attempt to execute the query: $str = "SELECT * FROM profile LIMIT $x + $y"; To avoid the problem, evaluate the expression first: $z = $x + $y; $str = "SELECT * FROM profile LIMIT $z"; Or do this (but don't omit the parentheses or the expression won't evaluate properly): $str = "SELECT * FROM profile LIMIT " . ($x + $y); If you're constructing a two-argument LIMIT clause, evaluate both expressions before placing them into the query string. 3.21 What to Do When LIMIT Requires the "Wrong" Sort Order 3.21.1 Problem LIMIT usually works best in conjunction with an ORDER BY clause that sorts rows. But sometimes the sort order is the opposite of what you want for the final result. 3.21.2 Solution Rewrite the query, or write a program that retrieves the rows and sorts them into the order you want. 3.21.3 Discussion If you want the last four records of a result set, you can obtain them easily by sorting the set in reverse order and using LIMIT 4. For example, the following query returns the names and birth dates for the four people in the profile table who were born most recently: mysql> SELECT name, birth FROM profile ORDER BY birth DESC LIMIT 4; +---------+------------+ | name | birth | +---------+------------+ | Shepard | 1975-09-02 | | Carl | 1973-11-02 | | Fred | 1970-04-13 | | Mort | 1969-09-30 | +---------+------------+ But that requires sorting the birth values in descending order to place them at the head of the result set. What if you want them in ascending order instead? One way to solve this problem is to use two queries. First, use COUNT( ) to find out how many rows are in the table: mysql> SELECT COUNT(*) FROM profile; +----------+ | COUNT(*) | +----------+ | 10 | +----------+ Then, sort the values in ascending order and use the two-argument form of LIMIT to skip all but the last four records: mysql> SELECT name, birth FROM profile ORDER BY birth LIMIT 6, 4; +---------+------------+ | name | birth | +---------+------------+ | Mort | 1969-09-30 | | Fred | 1970-04-13 | | Carl | 1973-11-02 | | Shepard | 1975-09-02 | +---------+------------+ Single-query solutions to this problem may be available if you're issuing queries from within a program and can manipulate the query result. For example, if you fetch the values into a data structure, you can reverse the order of the values in the structure. Here is some Perl code that demonstrates this approach: my $stmt = "SELECT name, birth FROM profile ORDER BY birth DESC LIMIT 4"; # fetch values into a data structure my $ref = $dbh->selectall_arrayref ($stmt); # reverse the order of the items in the structure my @val = reverse (@{$ref}); # use $val[$i] to get a reference to row $i, then use # $val[$i]->[0] and $val[$i]->[1] to access column values Alternatively, you can simply iterate through the structure in reverse order: my $stmt = "SELECT name, birth FROM profile ORDER BY birth DESC LIMIT 4"; # fetch values into a data structure my $ref = $dbh->selectall_arrayref ($stmt); # iterate through the structure in reverse order my $row_count = @{$ref}; for (my $i = $row_count - 1; $i >= 0; $i--) { # use $ref->[$i]->[0] and $ref->[$i]->[1] here... } 3.22 Selecting a Result Set into an Existing Table 3.22.1 Problem You want to run a SELECT query but save the results into another table rather than displaying them. 3.22.2 Solution If the other table exists, use INSERT INTO ... SELECT, described here. If the table doesn't exist, skip ahead to Recipe 3.23. 3.22.3 Discussion The MySQL server normally returns the result of a SELECT statement to the client that issued the statement. For example, when you run a query from within mysql, the server returns the result to mysql, which in turn displays it to you on the screen. It's also possible to send the results of a SELECT statement directly into another table. Copying records from one table to another is useful in a number of ways: · If you're developing an algorithm that modifies a table, it's safer to work with a copy of a table so that you need not worry about the consequences of mistakes. Also, if the original table is large, creating a partial copy can speed the development process because queries run against it will take less time. · For data-loading operations that work with information that might be malformed, you can load new records into a temporary table, perform some preliminary checks, and correct the records as necessary. When you're satisfied the new records are okay, copy them from the temporary table into your main table. · Some applications maintain a large repository table and a smaller working table into which records are inserted on a regular basis, copying the working table records to the repository periodically and clearing the working table. · If you're performing a number of similar summary operations on a large table, it may be more efficient to select summary information once into a second table and use that for further analysis, rather than running expensive summary operations repeatedly on the original table. This section shows how to use INSERT ... SELECT to retrieve a result set for insertion into an existing table. The next section discusses CREATE TABLE ... SELECT, a statement available as of MySQL 3.23 that allows you to create a table on the fly directly from a query result. The table names src_tbl and dst_tbl in the examples refer to the source table from which rows are selected and the destination table into which they are stored. If the destination table already exists, use INSERT ... SELECT to copy the result set into it. For example, if dst_tbl contains an integer column i and a string column s, the following statement copies rows from src_tbl into dst_tbl, assigning column val to i and column name to s: INSERT INTO dst_tbl (i, s) SELECT val, name FROM src_tbl; The number of columns to be inserted must match the number of selected columns, and the correspondence between sets of columns is established by position rather than name. In the special case that you want to copy all columns from one table to another, you can shorten the statement to this form: INSERT INTO dst_tbl SELECT * FROM src_tbl; To copy only certain rows, add a WHERE clause that selects the rows you want: INSERT INTO dst_tbl SELECT * FROM src_tbl WHERE val > 100 AND name LIKE 'A%'; It's not necessary to copy column values without modification from the source table into the destination table. The SELECT statement can produce values from expressions, too. For example, the following query counts the number of times each name occurs in src_tbl and stores both the counts and the names in dst_tbl: INSERT INTO dst_tbl (i, s) SELECT COUNT(*), name FROM src_tbl GROUP BY name; When you use INSERT ... SELECT, you cannot use the same table both as a source and a destination. 3.23 Creating a Destination Table on the Fly from a Result Set 3.23.1 Problem You want to run a SELECT query and save the result set into another table, but that table doesn't exist yet. 3.23.2 Solution Create the destination table first, or create it directly from the result of the SELECT. 3.23.3 Discussion If the destination table does not exist, you can create it first with a CREATE TABLE statement, then copy rows into it with INSERT ... SELECT as described in Recipe 3.22. This technique works for any version of MySQL. In MySQL 3.23 and up, a second option is to use CREATE TABLE ... SELECT, which creates the destination table directly from the result of a SELECT. For example, to create dst_tbl and copy the entire contents of src_tbl into it, do this: CREATE TABLE dst_tbl SELECT * FROM src_tbl; MySQL creates the columns in dst_tbl based on the name, number, and type of the columns in src_tbl. Add an appropriate WHERE clause, should you wish to copy only certain rows. If you want to create an empty table, use a WHERE clause that is always false: CREATE TABLE dst_tbl SELECT * FROM src_tbl WHERE 0; To copy only some of the columns, name the ones you want in the SELECT part of the statement. For example, if src_tbl contains columns a, b, c, and d, you can copy just b and d like this: CREATE TABLE dst_tbl SELECT b, d FROM src_tbl; To create columns in a different order than that in which they appear in the source table, just name them in the desired order. If the source table contains columns a, b, and c, but you want them to appear in the destination table in the order c, a, and b, do this: CREATE TABLE dst_tbl SELECT c, a, b FROM src_tbl; To create additional columns in the destination table besides those selected from the source table, provide appropriate column definitions in the CREATE TABLE part of the statement. The following statement creates id as an AUTO_INCREMENT column in dst_tbl, and adds columns a, b, and c from src_tbl: CREATE TABLE dst_tbl ( id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) ) SELECT a, b, c FROM src_tbl; The resulting table contains four columns in the order id, a, b, c. Defined columns are assigned their default values. (This means that id, being an AUTO_INCREMENT column, will be assigned successive sequence numbers starting from one. See Recipe 11.2.) If you derive a column's values from an expression, it's prudent to provide an alias to give the column a name. Suppose src_tbl contains invoice information listing items in each invoice. Then the following statement generates a summary of each invoice named in the table, along with the total cost of its items. The second column includes an alias because the default name for an expression is the expression itself, which is difficult to work with: CREATE TABLE dst_tbl SELECT inv_no, SUM(unit_cost*quantity) AS total_cost FROM src_tbl GROUP BY inv_no; In fact, prior to MySQL 3.23.6, the alias is required, not just advisable; column naming rules are stricter and an expression is not a legal name for a column in a table. CREATE TABLE ... SELECT is extremely convenient, but does have some limitations. These stem primarily from the fact that the information available from a result set is not as extensive as what you can specify in a CREATE TABLE statement. If you derive a table column from an expression, for example, MySQL has no idea whether or not the column should be indexed or what its default value is. If it's important to include this information in the destination table, use the following techniques: · If you want indexes in the destination table, you can specify them explicitly. For example, if src_tbl has a PRIMARY KEY on the id column, and a multiple-column index on state and city, you can specify them for dst_tbl as well: · CREATE TABLE dst_tbl (PRIMARY KEY (id), INDEX(state,city)) SELECT * FROM src_tbl; · Column attributes such as AUTO_INCREMENT and a column's default value are not copied to the destination table. To preserve these attributes, create the table, then use ALTER TABLE to apply the appropriate modifications to the column definition. For example, if src_tbl has an id column that is not only a PRIMARY KEY but an AUTO_INCREMENT column, copy the table, then modify it: · CREATE TABLE dst_tbl (PRIMARY KEY (id)) SELECT * FROM src_tbl; ALTER TABLE dst_tbl MODIFY id INT UNSIGNED NOT NULL AUTO_INCREMENT; · If you want to make the destination table an exact copy of the source table, use the cloning technique described in Recipe 3.26. 3.24 Moving Records Between Tables Safely 3.24.1 Problem You're moving records by copying them from one table to another and then deleting them from the original table. But some records seem to be getting lost. 3.24.2 Solution Be careful to delete exactly the same set of records from the source table that you copied to the destination table. 3.24.3 Discussion Applications that copy rows from one table to another can do so with a single operation, such as INSERT ... SELECT to retrieve the relevant rows from the source table and add them to the destination table. If an application needs to move (rather than copy) rows, the procedure is a little more complicated: After copying the rows to the destination table, you must remove them from the source table. Conceptually, this is nothing more than INSERT ... SELECT followed by DELETE. In practice, the operation may require more care, because it's necessary to select exactly the same set of rows in the source table for both the INSERT and DELETE statements. If other clients insert new rows into the source table after you issue the INSERT and before you issue the DELETE, this can be tricky. To illustrate, suppose you have an application that uses a working log table worklog into which records are entered on a continual basis, and a long-term repository log table repolog. Periodically, you move worklog records into repolog to keep the size of the working log small, and so that clients can issue possibly long-running log analysis queries on the repository without blocking processes that create new records in the working log.[3] [3] If you use a MyISAM log table that you only insert into and never delete from or modify, you can run queries on the table without preventing other clients from inserting new log records at the end of the table. How do you properly move records from worklog to repolog in this situation, given that worklog is subject to ongoing insert activity? The obvious (but incorrect) way is to issue an INSERT ... SELECT statement to copy all the worklog records into repolog, followed by a DELETE to remove them from worklog: INSERT INTO repolog SELECT * FROM worklog; DELETE FROM worklog; This is a perfectly workable strategy when you're certain nobody else will insert any records into worklog during the time between the two statements. But if other clients insert new records in that period, they'll be deleted without ever having been copied, and you'll lose records. If the tables hold logs of web page requests, that may not be such a big deal, but if they're logs of financial transactions, you could have a serious problem. What can you do to keep from losing records? Two possibilities are to issue both statements within a transaction, or to lock both tables while you're using them. These techniques are covered in Chapter 15. However, either one might block other clients longer than you'd prefer, because you tie up the tables for the duration of both queries. An alternative strategy is to move only those records that are older than some cutoff point. For example, if the log records have a column t containing a timestamp, you can limit the scope of the selected records to all those created before today. Then it won't matter whether new records are added to worklog between the copy and delete operations. Be sure to specify the cutoff properly, though. Here's a method that fails under some circumstances: INSERT INTO repolog SELECT * FROM worklog WHERE t < CURDATE( ); DELETE FROM worklog WHERE t < CURDATE( ); This won't work if you happen to issue the INSERT statement at one second before midnight and the SELECT statement one second later. The value of CURDATE( ) will differ for the two statements, and the DELETE operation may remove too many records. If you're going to use a cutoff, make sure it has a fixed value, not one that may change between statements. For example, a SQL variable can be used to save the value of CURDATE( ) in a form that won't change as time passes: SET @cutoff = CURDATE( ); INSERT INTO repolog SELECT * FROM worklog WHERE t < @cutoff; DELETE FROM worklog WHERE t < @cutoff; This ensures that both statements use the same cutoff value so that the DELETE operation doesn't remove records that it shouldn't. 3.25 Creating Temporary Tables 3.25.1 Problem You need a table only for a short time, then you want it to disappear automatically. 3.25.2 Solution Create a TEMPORARY table and let MySQL take care of clobbering it. 3.25.3 Discussion Some operations require a table that exists only temporarily and that should disappear when it's no longer needed. You can of course issue a DROP TABLE statement explicitly to remove a table when you're done with it. Another option, available in MySQL 3.23.2 and up, is to use CREATE TEMPORARY TABLE. This statement is just like CREATE TABLE except that it creates a transient table that disappears when your connection to the server closes, if you haven't already removed it yourself. This is extremely useful behavior because you need not remember to remove the table. MySQL drops it for you automatically. Temporary tables are connection-specific, so several clients each can create a temporary table having the same name without interfering with each other. This makes it easier to write applications that use transient tables, because you need not ensure that the tables have unique names for each client. (See Recipe 3.27 for further discussion of this issue.) Another property of temporary tables is that they can be created with the same name as a permanent table. In this case, the temporary table "hides" the permanent table for the duration of its existence, which can be useful for making a copy of a table that you can modify without affecting the original by mistake. The DELETE statement in the following set of queries removes records from a temporary mail table, leaving the original permanent one unaffected: mysql> CREATE TEMPORARY TABLE mail SELECT * FROM mail; mysql> SELECT COUNT(*) FROM mail; +----------+ | COUNT(*) | +----------+ | 16 | +----------+ mysql> DELETE FROM mail; mysql> SELECT COUNT(*) FROM mail; +----------+ | COUNT(*) | +----------+ | 0 | +----------+ mysql> DROP TABLE mail; mysql> SELECT COUNT(*) FROM mail; +----------+ | COUNT(*) | +----------+ | 16 | +----------+ Although temporary tables created with CREATE TEMPORARY TABLE have the preceding benefits, keep the following caveats in mind: · If you want to reuse the temporary table within a given session, you'll still need to drop it explicitly before recreating it. It's only the last use within a session that you need no explicit DROP TABLE for. (If you've already created a temporary table with a given name, attempting to create a second one with that name results in an error.) · Some APIs support persistent connections in a web environment. Use of these prevents temporary tables from being dropped as you expect when your script ends, because the web server keeps the connection open for reuse by other scripts. (The server may close the connection eventually, but you have no control over when that happens.) This means it can be prudent to issue the following statement prior to creating a temporary table, just in case it's still hanging around from the previous execution of the script: DROP TABLE IF EXISTS tbl_name · If you modify a temporary table that "hides" a permanent table with the same name, be sure to test for errors resulting from dropped connections. If a client program automatically reconnects after a dropped connection, you'll be modifying the original table after the reconnect. 3.26 Cloning a Table Exactly 3.26.1 Problem You need an exact copy of a table, and CREATE TABLE ... SELECT doesn't suit your purposes because the copy must include the same indexes, default values, and so forth. 3.26.2 Solution Use SHOW CREATE TABLE to get a CREATE TABLE statement that specifies the source table's structure, indexes and all. Then modify the statement to change the table name to that of the clone table and execute the statement. If you need the table contents copied as well, issue an INSERT INTO ... SELECT statement, too. 3.26.3 Discussion Because CREATE TABLE ... SELECT does not copy indexes or the full set of column attributes, it doesn't necessarily create a destination table as an exact copy of the source table. Because of that, you might find it more useful to issue a SHOW CREATE TABLE query for the source table. This statement is available as of MySQL 3.23.20; it returns a row containing the table name and a CREATE TABLE statement that corresponds to the table's structure—including its indexes (keys), column attributes, and table type: mysql> SHOW CREATE TABLE mail\G *************************** 1. row *************************** Table: mail Create Table: CREATE TABLE `mail` ( `t` datetime default NULL, `srcuser` char(8) default NULL, `srchost` char(20) default NULL, `dstuser` char(8) default NULL, `dsthost` char(20) default NULL, `size` bigint(20) default NULL, KEY `t` (`t`) ) TYPE=MyISAM By issuing a SHOW CREATE TABLE statement from within a program and performing a string replacement to change the table name, you obtain a statement that can be executed to create a new table with the same structure as the original. The following Python function takes three arguments (a connection object, and the names of the source and destination tables). It retrieves the CREATE TABLE statement for the source table, modifies it to name the destination table, and returns the result: # Generate a CREATE TABLE statement to create dst_tbl with the same # structure as the existing table src_tbl. Return None if an error # occurs. Requires the re module. def gen_clone_query (conn, src_tbl, dst_tbl): try: cursor = conn.cursor ( ) cursor.execute ("SHOW CREATE TABLE " + src_tbl) row = cursor.fetchone ( ) cursor.close ( ) if row == None: query = None else: # Replace src_tbl with dst_tbl in the CREATE TABLE statement query = re.sub ("CREATE TABLE .*`" + src_tbl + "`", "CREATE TABLE `" + dst_tbl + "`", row[1]) except: query = None return query You can execute the resulting statement as is to create the new table if you like: query = gen_clone_query (conn, old_tbl, new_tbl) cursor = conn.cursor ( ) cursor.execute (query) cursor.close ( ) Or you can get more creative. For example, to create a temporary table rather than a permanent one, change CREATE to CREATE TEMPORARY before executing the statement: query = gen_clone_query (conn, old_tbl, new_tbl) query = re.sub ("CREATE ", "CREATE TEMPORARY ", query) cursor = conn.cursor ( ) cursor.execute (query) cursor.close ( ) Executing the statement returned by gen_clone_query( ) creates an empty copy of the source table. To copy the contents as well, do something like this after creating the copy: cursor = conn.cursor ( ) cursor.execute ("INSERT INTO " + new_tbl + " SELECT * FROM " + old_tbl) cursor.close ( ) Prior to MySQL 3.23.50, there are a few attributes that you can specify in a CREATE TABLE statement that SHOW CREATE TABLE does not display. If your source table was created with any of these attributes, the cloning technique shown here will create a destination table that does not have quite the same structure. table that does not have quite the same structure. 3.27 Generating Unique Table Names 3.27.1 Problem You need to create a table with a name that is guaranteed not to exist already. 3.27.2 Solution If you can create a TEMPORARY table, it doesn't matter if the name exists already. Otherwise, try to generate a value that is unique to your client program and incorporate it into the table name. 3.27.3 Discussion MySQL is a multiple-client database server, so if a given script that creates a transient table might be invoked by several clients simultaneously, you must take care to keep multiple invocations of the script from fighting over the same table name. If the script creates tables using CREATE TEMPORARY TABLE, there is no problem because different clients can create temporary tables having the same name without clashing. If you can't use CREATE TEMPORARY TABLE because the server version is older than 3.23.2, you should make sure that each invocation of the script creates a uniquely named table. To do this, incorporate into the name some value that is guaranteed to be unique per invocation. A timestamp won't work, because it's easily possible for two instances of a script to be invoked within the same second. A random number may be somewhat better. For example, in Java, you can use the java.util.Random( ) class to create a table name like this: import java.util.Random; import java.lang.Math; Random rand = new Random ( ); int n = rand.nextInt ( ); // generate random number n = Math.abs (n); // take absolute value String tblName = "tmp_tbl_" + n; Unfortunately, random numbers only reduce the possibility of name clashes, they do not eliminate it. Process ID (PID) values are a better source of unique values. PIDs are reused over time, but never for two processes at the same time, so a given PID is guaranteed to be unique among the set of currently executing processes. You can use this fact to create unique table names as follows: Perl: my $tbl_name = "tmp_tbl_$$"; PHP: $tbl_name = "tmp_tbl_" . posix_getpid ( ); Python: import os tbl_name = "tmp_tbl_%d" % os.getpid ( ) Note that even if you create a table name using a value like a PID that is guaranteed to be unique to a given script invocation, there may still be a chance that the table will exist. This can happen if a previous invocation of the script with the same PID created a table with the same name, but crashed before removing the table. On the other hand, any such table cannot still be in use because it will have been created by a process that is no longer running. Under these circumstances, it's safe to remove the table if it does exist by issuing the following statement: DROP TABLE IF EXISTS tbl_name Then you can go ahead and create the new table. Chapter 4. Working with Strings Section 4.1. Introduction Section 4.2. Writing Strings That Include Quotes or Special Characters Section 4.3. Preserving Trailing Spaces in String Columns Section 4.4. Testing String Equality or Relative Ordering Section 4.5. Decomposing or Combining Strings Section 4.6. Checking Whether a String Contains a Substring Section 4.7. Pattern Matching with SQL Patterns Section 4.8. Pattern Matching with Regular Expressions Section 4.9. Matching Pattern Metacharacters Literally Section 4.10. Controlling Case Sensitivity in String Comparisons Section 4.11. Controlling Case Sensitivity in Pattern Matching Section 4.12. Using FULLTEXT Searches Section 4.13. Using a FULLTEXT Search with Short Words Section 4.14. Requiring or Excluding FULLTEXT Search Words Section 4.15. Performing Phrase Searches with a FULLTEXT Index 4.1 Introduction Like most data types, strings can be compared for equality or inequality or relative ordering. However, strings have some additional properties to consider: · Strings can be case sensitive (or not), which can affect the outcome of string operations. · You can compare entire strings, or just parts of them by extracting substrings. · You can apply pattern-matching operations to look for strings that have a certain structure. This chapter discusses several useful string operations you can perform, including how to account for whether or not strings are case sensitive. The following table, metal, is used in several sections of this chapter: mysql> SELECT * FROM metal; +----------+ | name | +----------+ | copper | | gold | | iron | | lead | | mercury | | platinum | | silver | | tin | +----------+ The table is very simple, containing only a single string column: CREATE TABLE metal ( name VARCHAR(20) ); You can create the table using the metal.sql script in the tables directory of the recipes distribution. 4.1.1 Types of Strings MySQL can operate on regular strings or binary strings. "Binary" in this context has little to do with the presence of non-ASCII values, so it's useful right at the outset to make a distinction: · Binary data may contain bytes that lie outside the usual range of printable ASCII characters. · A binary string in MySQL is one that MySQL treats as case sensitive in comparisons. For binary strings, the characters A and a are considered different. For non-binary strings, they're considered the same. A binary column type is one that contains binary strings. Some of MySQL's column types are binary (case sensitive) and others are not, as illustrated here: Column type Binary/case sensitive CHAR, VARCHAR No CHAR BINARY, VARCHAR BINARY Yes TEXT No BLOB Yes ENUM, SET No 4.2 Writing Strings That Include Quotes or Special Characters 4.2.1 Problem You want to write a quoted string, but it contains quote characters or other special characters, and MySQL rejects it. 4.2.2 Solution Learn the syntax rules that govern the interpretation of strings in queries. 4.2.3 Discussion To write a string in a SQL statement, surround it with quote characters: mysql> SELECT 'hello, world'; +--------------+ | hello, world | +--------------+ | hello, world | +--------------+ But sometimes you need to write a string that includes a quote character, and if you just put the quote into the string as is, a syntax error results: mysql> SELECT 'I'm asleep'; ERROR 1064 at line 1: You have an error in your SQL syntax near 'asleep'' at line 1 You can deal with this several ways: · MySQL, unlike some SQL engines, allows you to quote strings with either single quotes or double quotes, so you can enclose a string containing single quotes within double quotes: mysql> SELECT "I'm asleep"; +------------+ | I'm asleep | +------------+ | I'm asleep | +------------+ This works in reverse, too; a string containing double quotes can be enclosed within single quotes: mysql> SELECT 'He said, "Boo!"'; +-----------------+ | He said, "Boo!" | +-----------------+ | He said, "Boo!" | +-----------------+ · To include a quote character within a string that is quoted by the same kind of quote, either double the quote or precede it with a backslash. When MySQL reads the query string, it will strip off the extra quote or the backslash: mysql> SELECT 'I''m asleep', 'I\'m wide awake'; +------------+----------------+ | I'm asleep | I'm wide awake | +------------+----------------+ | I'm asleep | I'm wide awake | +------------+----------------+ 1 row in set (0.00 sec) mysql> SELECT "He said, ""Boo!""", "And I said, \"Yikes!\""; +-----------------+----------------------+ | He said, "Boo!" | And I said, "Yikes!" | +-----------------+----------------------+ | He said, "Boo!" | And I said, "Yikes!" | +-----------------+----------------------+ A backslash turns off the special meaning of the following character. (It causes a temporary escape from normal string processing rules, so sequences such as \' and \" are called escape sequences.) This means that backslash itself is special, so to write a literal backslash within a string, you must double it: mysql> SELECT 'Install MySQL in C:\\mysql on Windows'; +--------------------------------------+ | Install MySQL in C:\mysql on Windows | +--------------------------------------+ | Install MySQL in C:\mysql on Windows | +--------------------------------------+ Other escape sequences recognized by MySQL are \b (backspace), \n (newline, also called linefeed), \r (carriage return), \t (tab), and \0 (ASCII NUL). 4.2.4 See Also Use of escape sequences for writing string values is best limited to text values. Values such as images that contain arbitrary data also must have any special characters escaped if you want to include them in a query string, but trying to enter an image value by typing it in is too painful even to think about. You should construct such queries from within a program where you can use the placeholder mechanism provided by the language's MySQL API. See Recipe 2.7. 4.3 Preserving Trailing Spaces in String Columns 4.3.1 Problem MySQL strips trailing spaces from strings, but you want to preserve them. 4.3.2 Solution Use a different column type. 4.3.3 Discussion If you store a string that contains trailing spaces into the database, you may find that they're gone when you retrieve the value. This is the normal MySQL behavior for CHAR and VARCHAR columns; the server returns values from both types of columns without trailing spaces. If you want to preserve trailing spaces, use one of the TEXT or BLOB column types. (The TEXT types are not case sensitive, the BLOB types are.) The following example illustrates the difference in behavior for VARCHAR and TEXT columns: mysql> CREATE TABLE t (c VARCHAR(255)); mysql> INSERT INTO t (c) VALUES('abc '); mysql> SELECT c, LENGTH(c) FROM t; +------+-----------+ | c | LENGTH(c) | +------+-----------+ | abc | 3 | +------+-----------+ mysql> DROP TABLE t; mysql> CREATE TABLE t (c TEXT); mysql> INSERT INTO t (c) VALUES('abc '); mysql> SELECT c, LENGTH(c) FROM t; +------------+-----------+ | c | LENGTH(c) | +------------+-----------+ | abc | 10 | +------------+-----------+ There are plans to introduce a VARCHAR type that retains trailing spaces in a future version of MySQL. 4.4 Testing String Equality or Relative Ordering 4.4.1 Problem You want to know whether strings are equal or unequal, or which one appears first in lexical order. 4.4.2 Solution Use a comparison operator. 4.4.3 Discussion Strings are subject to the usual equality and inequality comparisons: mysql> SELECT name, name = 'lead', name != 'lead' FROM metal; +----------+---------------+----------------+ | name | name = 'lead' | name != 'lead' | +----------+---------------+----------------+ | copper | 0 | 1 | | gold | 0 | 1 | | iron | 0 | 1 | | lead | 1 | 0 | | mercury | 0 | 1 | | platinum | 0 | 1 | | silver | 0 | 1 | | tin | 0 | 1 | +----------+---------------+----------------+ You can also use relational operators such as <, <=, >=, and > to test strings for lexical ordering: mysql> SELECT name, name < 'lead', name > 'lead' FROM metal; +----------+---------------+---------------+ | name | name < 'lead' | name > 'lead' | +----------+---------------+---------------+ | copper | 1 | 0 | | gold | 1 | 0 | | iron | 1 | 0 | | lead | 0 | 0 | | mercury | 0 | 1 | | platinum | 0 | 1 | | silver | 0 | 1 | | tin | 0 | 1 | +----------+---------------+---------------+ To find out whether a string lies within a given range of values (inclusive), you can combine two comparisons: mysql> SELECT name, 'iron' <= name AND name <= 'platinum' FROM metal; +----------+---------------------------------------+ | name | 'iron' <= name AND name <= 'platinum' | +----------+---------------------------------------+ | copper | 0 | | gold | 0 | | iron | 1 | | lead | 1 | | mercury | 1 | | platinum | 1 | | silver | 0 | | tin | 0 | +----------+---------------------------------------+ You can also use the BETWEEN operator for inclusive-range testing. The following query is equivalent to the one just shown: SELECT name, name BETWEEN 'iron' AND 'platinum' FROM metal; 4.4.4 See Also The outcome of a string comparison may be affected by whether or not the operands are binary strings, as discussed in Recipe 4.10. 4.5 Decomposing or Combining Strings 4.5.1 Problem You want to break apart a string to extract a substring or combine strings to form a larger string. 4.5.2 Solution To obtain a piece of a string, use a substring-extraction function. To combine strings, use CONCAT( ). 4.5.3 Discussion Parts of strings can be extracted and displayed. For example, LEFT( ), MID( ), and RIGHT( ) extract substrings from the left, middle, or right part of a string: mysql> SELECT name, LEFT(name,2), MID(name,3,1), RIGHT(name,3) FROM metal; +----------+--------------+---------------+---------------+ | name | LEFT(name,2) | MID(name,3,1) | RIGHT(name,3) | +----------+--------------+---------------+---------------+ | copper | co | p | per | | gold | go | l | old | | iron | ir | o | ron | | lead | le | a | ead | | mercury | me | r | ury | | platinum | pl | a | num | | silver | si | l | ver | | tin | ti | n | tin | +----------+--------------+---------------+---------------+ For LEFT( ) and RIGHT( ), the second argument indicates how many characters to return from the left or right end of the string. For MID( ), the second argument is the starting position of the substring you want (beginning from 1) and the third argument indicates how many characters to return. The SUBSTRING( ) function takes a string and a starting position, returning everything to the right of the position.[1] [1] MID( ) acts the same way if you omit its third argument, because MID( ) is actually a synonym for SUBSTRING( ). mysql> SELECT name, SUBSTRING(name,4), MID(name,4) FROM metal; +----------+-------------------+-------------+ | name | SUBSTRING(name,4) | MID(name,4) | +----------+-------------------+-------------+ | copper | per | per | | gold | d | d | | iron | n | n | | lead | d | d | | mercury | cury | cury | | platinum | tinum | tinum | | silver | ver | ver | | tin | | | +----------+-------------------+-------------+ To return everything to the right or left of a given character, use SUBSTRING_INDEX(str,c,n). It searches into a string str for the n-th occurrence of the character c and returns everything to its left. If n is negative, the search for c starts from the right and returns everything to the right of the character: mysql> SELECT name, -> SUBSTRING_INDEX(name,'r',2), -> SUBSTRING_INDEX(name,'i',-1) -> FROM metal; +----------+-----------------------------+------------------------------+ | name | SUBSTRING_INDEX(name,'r',2) | SUBSTRING_INDEX(name,'i',-1) | +----------+-----------------------------+------------------------------+ | copper | copper | copper | | gold | gold | gold | | iron | iron | ron | | lead | lead | lead | | mercury | mercu | mercury | | platinum | platinum | num | | silver | silver | lver | | tin | tin | n | +----------+-----------------------------+------------------------------+ Note that if there is no n-th occurrence of the character, SUBSTRING_INDEX( ) returns the entire string. SUBSTRING_INDEX( ) is case sensitive. Substrings can be used for purposes other than display, such as to perform comparisons. The following query finds metal names having a first letter that lies in the last half of the alphabet: mysql> SELECT name from metal WHERE LEFT(name,1) >= 'n'; +----------+ | name | +----------+ | platinum | | silver | | tin | +----------+ To combine strings rather than pull them apart, use the CONCAT( ) function. It concatenates all its arguments and returns the result: mysql> SELECT CONCAT('Hello, ',USER( ),', welcome to MySQL!') AS greeting; +------------------------------------------+ | greeting | +------------------------------------------+ | Hello, paul@localhost, welcome to MySQL! | +------------------------------------------+ mysql> SELECT CONCAT(name,' ends in "d": ',IF(RIGHT(name,1)='d','YES','NO')) -> AS 'ends in "d"?' -> FROM metal; +--------------------------+ | ends in "d"? | +--------------------------+ | copper ends in "d": NO | | gold ends in "d": YES | | iron ends in "d": NO | | lead ends in "d": YES | | mercury ends in "d": NO | | platinum ends in "d": NO | | silver ends in "d": NO | | tin ends in "d": NO | +--------------------------+ Concatenation can be useful for modifying column values "in place." For example, the following UPDATE statement adds a string to the end of each name value in the metal table: mysql> UPDATE metal SET name = CONCAT(name,'ide'); mysql> SELECT name FROM metal; +-------------+ | name | +-------------+ | copperide | | goldide | | ironide | | leadide | | mercuryide | | platinumide | | silveride | | tinide | +-------------+ To undo the operation, strip off the last three characters (the LENGTH( ) function returns the length of a string): mysql> UPDATE metal SET name = LEFT(name,LENGTH(name)-3); mysql> SELECT name FROM metal; +----------+ | name | +----------+ | copper | | gold | | iron | | lead | | mercury | | platinum | | silver | | tin | +----------+ The concept of modifying a column in place can be applied to ENUM or SET values as well, which usually can be treated as string values even though they are stored internally as numbers. For example, to concatenate a SET element to an existing SET column, use CONCAT( ) to add the new value to the existing value, preceded by a comma. But remember to account for the possibility that the existing value might be NULL or the empty string. In that case, set the column value equal to the new element, without the leading comma: UPDATE tbl_name SET set_col = IF(set_col IS NULL OR set_col = '',val,CONCAT(set_col,',',val)); 4.6 Checking Whether a String Contains a Substring 4.6.1 Problem You want to know whether a given string occurs within another string. 4.6.2 Solution Use LOCATE( ). 4.6.3 Discussion The LOCATE( ) function takes two arguments representing the substring that you're looking for and the string in which to look for it. The return value is the position at which the substring occurs, or 0 if it's not present. An optional third argument may be given to indicate the position within the string at which to start looking. mysql> SELECT name, LOCATE('in',name), LOCATE('in',name,3) FROM metal; +----------+-------------------+---------------------+ | name | LOCATE('in',name) | LOCATE('in',name,3) | +----------+-------------------+---------------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 0 | 0 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 5 | 5 | | silver | 0 | 0 | | tin | 2 | 0 | +----------+-------------------+---------------------+ LOCATE( ) is not case sensitive as of MySQL 4.0.0, and is case sensitive before that. 4.7 Pattern Matching with SQL Patterns 4.7.1 Problem You want to perform a pattern match rather than a literal comparison. 4.7.2 Solution Use the LIKE operator and a SQL pattern, described in this section. Or use a regular expression pattern match, described in Recipe 4.8. 4.7.3 Discussion Patterns are strings that contain special characters. These are known as metacharacters because they stand for something other than themselves. MySQL provides two kinds of pattern matching. One is based on SQL patterns and the other on regular expressions. SQL patterns are more standard among different database systems, but regular expressions are more powerful. The two kinds of pattern match uses different operators and different sets of metacharacters. This section describes SQL patterns; Recipe 4.8 describes regular expressions. SQL pattern matching uses the LIKE and NOT LIKE operators rather than = and != to perform matching against a pattern string. Patterns may contain two special metacharacters: _ matches any single character, and % matches any sequence of characters, including the empty string. You can use these characters to create patterns that match a wide variety of values: · Strings that begin with a particular substring: · mysql> SELECT name FROM metal WHERE name LIKE 'co%'; · +--------+ · | name | · +--------+ · | copper | +--------+ · Strings that end with a particular substring: · mysql> SELECT name FROM metal WHERE name LIKE '%er'; · +--------+ · | name | · +--------+ · | copper | · | silver | +--------+ · Strings that contain a particular substring anywhere: · mysql> SELECT name FROM metal WHERE name LIKE '%er%'; · +---------+ · | name | · +---------+ · | copper | · | mercury | · | silver | +---------+ · Strings that contain a substring at a specific position (the pattern matches only if pp occurs at the third position of the name column): · mysql> SELECT name FROM metal where name LIKE '_ _pp%'; · +--------+ · | name | · +--------+ · | copper | +--------+ A SQL pattern matches successfully only if it matches the entire comparison value. Thus, of the following two pattern matches, only the second succeeds: 'abc' LIKE 'b' 'abc' LIKE '%b%' To reverse the sense of a pattern match, use NOT LIKE. The following query finds strings that contain no i characters: mysql> SELECT name FROM metal WHERE name NOT LIKE '%i%'; +---------+ | name | +---------+ | copper | | gold | | lead | | mercury | +---------+ SQL patterns do not match NULL values. This is true both for LIKE and NOT LIKE: mysql> SELECT NULL LIKE '%', NULL NOT LIKE '%'; +---------------+-------------------+ | NULL LIKE '%' | NULL NOT LIKE '%' | +---------------+-------------------+ | NULL | NULL | +---------------+-------------------+ In some cases, pattern matches are equivalent to substring comparisons. For example, using patterns to find strings at one end or the other of a string is like using LEFT( ) or RIGHT( ): Pattern match Substring comparison str LIKE 'abc%' LEFT(str,3) = 'abc' str LIKE '%abc' RIGHT(str,3) = 'abc' If you're matching against a column that is indexed and you have a choice of using a pattern or an equivalent LEFT( ) expression, you'll likely find that the pattern match is faster. MySQL can use the index to narrow the search for a pattern that begins with a literal string; with LEFT( ), it cannot. Using Patterns with Non-String Values Unlike some other databases, MySQL allows pattern matches to be applied to numeric or date values, which can sometimes be useful. The following table shows some ways to test a DATE value d using function calls that extract date parts and using the equivalent pattern matches. The pairs of expressions are true for dates occurring in the year 1976, in the month of April, or on the first day of the month: Function value test Pattern match test YEAR(d) = 1976 d LIKE '1976-%' MONTH(d) = 4 d LIKE '%-04-%' DAYOFMONTH(d) = 1 d LIKE '%-01' 4.8 Pattern Matching with Regular Expressions 4.8.1 Problem You want to perform a pattern match rather than a literal comparison. 4.8.2 Solution Use the REGEXP operator and a regular expression pattern, described in this section. Or use a SQL pattern, described in Recipe 4.7. 4.8.3 Discussion SQL patterns (see Recipe 4.7) are likely to be implemented by other database systems, so they're reasonably portable beyond MySQL. On the other hand, they're somewhat limited. For example, you can easily write a SQL pattern %abc% to find strings that contain abc, but you cannot write a single SQL pattern to identify strings that contain any of the characters a, b, or c. Nor can you match string content based on character types such as letters or digits. For such operations, MySQL supports another type of pattern matching operation based on regular expressions and the REGEXP operator (or NOT REGEXP to reverse the sense of the match).[2] REGEXP matching uses a different set of pattern elements than % and _ (neither of which is special in regular expressions): [2] RLIKE is a synomym for REGEXP. This is for mSQL (miniSQL) compatibility and may make it easier to port queries from mSQL to MySQL. Pattern What the pattern matches ^ Beginning of string $ End of string . Any single character [...] Any character listed between the square brackets [^...] Any character not listed between the square brackets p1|p2|p3 Alternation; matches any of the patterns p1, p2, or p3 * Zero or more instances of preceding element + One or more instances of preceding element {n} n instances of preceding element {m,n} m through n instances of preceding element You may already be familiar with these regular expression pattern characters, because many of them are the same as those used by vi, grep, sed, and other Unix utilities that support regular expressions. Most of them are used also in the regular expressions understood by Perl, PHP, and Python. (For example, Chapter 10 discuss pattern matching in Perl scripts.) For Java, the Jakarta ORO or Regexp class libraries provide matching capabilities that use these characters as well. The previous section on SQL patterns showed how to match substrings at the beginning or end of a string, or at an arbitrary or specific position within a string. You can do the same things with regular expressions: · Strings that begin with a particular substring: · mysql> SELECT name FROM metal WHERE name REGEXP '^co'; · +--------+ · | name | · +--------+ · | copper | +--------+ · Strings that end with a particular substring: · mysql> SELECT name FROM metal WHERE name REGEXP 'er$'; · +--------+ · | name | · +--------+ · | copper | · | silver | +--------+ · Strings that contain a particular substring at any position: · mysql> SELECT name FROM metal WHERE name REGEXP 'er'; · +---------+ · | name | · +---------+ · | copper | · | mercury | · | silver | +---------+ · Strings that contain a particular substring at a specific position: · mysql> SELECT name FROM metal WHERE name REGEXP '^..pp'; · +--------+ · | name | · +--------+ · | copper | +--------+ In addition, regular expressions have other capabilities and can perform kinds of matches that SQL patterns cannot. For example, regular expressions can contain character classes, which match any character in the class: · To write a character class, list the characters you want the class to match inside square brackets. Thus, the pattern [abc] matches either a, b, or c. · Classes may indicate ranges of characters by using a dash between the beginning and end of the range. [a-z] matches any letter, [0-9] matches digits, and [a-z0-9] matches letters or digits. · To negate a character class ("match any character but these"), begin the list with a ^ character. For example, [^0-9] matches anything but digits. MySQL's regular expression capabilities also support POSIX character classes. These match specific character sets, as described in the following table. POSIX class What the class matches [:alnum:] Alphabetic and numeric characters [:alpha:] Alphabetic characters [:blank:] Whitespace (space or tab characters) [:cntrl:] Control characters [:digit:] Digits [:graph:] Graphic (non-blank) characters [:lower:] Lowercase alphabetic characters [:print:] Graphic or space characters [:punct:] Punctuation characters [:space:] Space, tab, newline, carriage return [:upper:] Uppercase alphabetic characters [:xdigit:] Hexadecimal digits (0-9, a-f, A-F) POSIX classes are intended for use within character classes, so you use them within square brackets. The following expression matches values that contain any hexadecimal digit character: mysql> SELECT name, name REGEXP '[[:xdigit:]]' FROM metal; +----------+----------------------------+ | name | name REGEXP '[[:xdigit:]]' | +----------+----------------------------+ | copper | 1 | | gold | 1 | | iron | 0 | | lead | 1 | | mercury | 1 | | platinum | 1 | | silver | 1 | | tin | 0 | +----------+----------------------------+ Regular expressions can contain alternations. The syntax looks like this: alternative1|alternative2|... An alternation is similar to a character class in the sense that it matches if any of the alternatives match. But unlike a character class, the alternatives are not limited to single characters—they can be strings or even patterns. For example, the following alternation matches strings that begin with a vowel or end with er: mysql> SELECT name FROM metal WHERE name REGEXP '^[aeiou]|er$'; +--------+ | name | +--------+ | copper | | iron | | silver | +--------+ Parentheses may be used to group alternations. For example, if you want to match strings that consist entirely of digits or entirely of letters, you might try this pattern, using an alternation: mysql> SELECT '0m' REGEXP '^[[:digit:]]+|[[:alpha:]]+$'; +-------------------------------------------+ | '0m' REGEXP '^[[:digit:]]+|[[:alpha:]]+$' | +-------------------------------------------+ | 1 | +-------------------------------------------+ But as the query result shows, the pattern doesn't work. That's because the ^ groups with the first alternative, and the $ groups with the second alternative. So the pattern actually matches strings that begin with one or more digits, or strings that end with one or more letters. However, if you group the alternatives within parentheses, the ^ and $ will apply to both of them and the pattern will act as you expect: mysql> SELECT '0m' REGEXP '^([[:digit:]]+|[[:alpha:]]+)$'; +---------------------------------------------+ | '0m' REGEXP '^([[:digit:]]+|[[:alpha:]]+)$' | +---------------------------------------------+ | 0 | +---------------------------------------------+ Unlike SQL pattern matches, which are successful only if the pattern matches the entire comparison value, regular expressions are successful if the pattern matches anywhere within the value. The following two pattern matches are equivalent in the sense that each one succeeds only for strings that contain a b character, but the first is more efficient because the pattern is simpler: 'abc' REGEXP 'b' 'abc' REGEXP '^.*b.*$' Regular expressions do not match NULL values. This is true both for REGEXP and for NOT REGEXP: mysql> SELECT NULL REGEXP '.*', NULL NOT REGEXP '.*'; +------------------+----------------------+ | NULL REGEXP '.*' | NULL NOT REGEXP '.*' | +------------------+----------------------+ | NULL | NULL | +------------------+----------------------+ The fact that a regular expression matches a string if the pattern is found anywhere in the string means you must take care not to inadvertently specify a pattern that matches the empty string. If you do, it will match any non-NULL value at all. For example, the pattern a* matches any number of a characters, even none. If your goal is to match only strings containing nonempty sequences of a characters, use a+ instead. The + requires one or more instances of the preceding pattern element for a match. As with SQL pattern matches performed using LIKE, regular expression matches performed with REGEXP sometimes are equivalent to substring comparisons. The ^ and $ metacharacters serve much the same purpose as LEFT( ) or RIGHT( ), at least if you're looking for literal strings: Pattern match Substring comparison str REGEXP '^abc' LEFT(str,3) = 'abc' str REGEXP 'abc$' RIGHT(str,3) = 'abc' For non-literal strings, it's typically not possible to construct an equivalent substring comparison. For example, to match strings that begin with any nonempty sequence of digits, you can use this pattern match: str REGEXP '^[0-9]+' That is something that LEFT( ) cannot do (and neither can LIKE, for that matter). 4.9 Matching Pattern Metacharacters Literally 4.9.1 Problem You want to perform a pattern match for a literal instance of a character that's special in patterns. 4.9.2 Solution Escape the special character with a backslash. Or maybe two. 4.9.3 Discussion Pattern matching is based on the use of metacharacters that have a special meaning and thus stand for something other than themselves. This means that to match a literal instance of a metacharacter, you must turn off its special meaning somehow. Do this by using a backslash character (\). Assume that a table metachar contains the following rows: mysql> SELECT c FROM metachar; +------+ | c | +------+ | % | | _ | | . | | ^ | | $ | | \ | +------+ A pattern consisting only of either SQL metacharacter matches all the values in the table, not just the metacharacter itself: mysql> SELECT c, c LIKE '%', c LIKE '_' FROM metachar; +------+------------+------------+ | c | c LIKE '%' | c LIKE '_' | +------+------------+------------+ | % | 1 | 1 | | _ | 1 | 1 | | . | 1 | 1 | | ^ | 1 | 1 | | $ | 1 | 1 | | \ | 1 | 1 | +------+------------+------------+ To match a literal instance of a SQL pattern metacharacter, precede it with a backslash: mysql> SELECT c, c LIKE '\%', c LIKE '\_' FROM metachar; +------+-------------+-------------+ | c | c LIKE '\%' | c LIKE '\_' | +------+-------------+-------------+ | % | 1 | 0 | | _ | 0 | 1 | | . | 0 | 0 | | ^ | 0 | 0 | | $ | 0 | 0 | | \ | 0 | 0 | +------+-------------+-------------+ The principle is somewhat similar for matching regular expression metacharacters. For example, each of the following regular expressions matches every row in the table: mysql> SELECT c, c REGEXP '.', c REGEXP '^', c REGEXP '$' FROM metachar; +------+--------------+--------------+--------------+ | c | c REGEXP '.' | c REGEXP '^' | c REGEXP '$' | +------+--------------+--------------+--------------+ | % | 1 | 1 | 1 | | _ | 1 | 1 | 1 | | . | 1 | 1 | 1 | | ^ | 1 | 1 | 1 | | $ | 1 | 1 | 1 | | \ | 1 | 1 | 1 | +------+--------------+--------------+--------------+ To match the metacharacters literally, just add a backslash, right? Well, try it: mysql> SELECT c, c REGEXP '\.', c REGEXP '\^', c REGEXP '\$' FROM metachar; +------+---------------+---------------+---------------+ | c | c REGEXP '\.' | c REGEXP '\^' | c REGEXP '\$' | +------+---------------+---------------+---------------+ | % | 1 | 1 | 1 | | _ | 1 | 1 | 1 | | . | 1 | 1 | 1 | | ^ | 1 | 1 | 1 | | $ | 1 | 1 | 1 | | \ | 1 | 1 | 1 | +------+---------------+---------------+---------------+ It didn't work, because regular expressions are processed a bit differently than SQL patterns. With REGEXP, you need a double backslash to match a metacharacter literally: mysql> SELECT c, c REGEXP '\\.', c REGEXP '\\^', c REGEXP '\\$' FROM metachar; +------+----------------+----------------+----------------+ | c | c REGEXP '\\.' | c REGEXP '\\^' | c REGEXP '\\$' | +------+----------------+----------------+----------------+ | % | 0 | 0 | 0 | | _ | 0 | 0 | 0 | | . | 1 | 0 | 0 | | ^ | 0 | 1 | 0 | | $ | 0 | 0 | 1 | | \ | 0 | 0 | 0 | +------+----------------+----------------+----------------+ Because backslash suppresses the special meaning of metacharacters, backslash itself is special. To match a backslash literally, use double backslashes in SQL patterns or quadruple backslashes in regular expressions: mysql> SELECT c, c LIKE '\\', c REGEXP '\' FROM metachar; +------+-------------+-----------------+ | c | c LIKE '\\' | c REGEXP '\\\\' | +------+-------------+-----------------+ | % | 0 | 0 | | _ | 0 | 0 | | . | 0 | 0 | | ^ | 0 | 0 | | $ | 0 | 0 | | \ | 1 | 1 | +------+-------------+-----------------+ It's even worse trying to figure out how many backslashes to use when you're issuing a query from within a program. It's more than likely that backslashes are also special to your programming language, in which case you'll need to double each one. Within a character class, use these marks to include literal instances of the following class constructor characters: · To include a literal ] character, list it first. · To include a literal - character, list it first or last. · To include a literal ^ character, list it somewhere other than as the first character. · To include a literal \ character, double it. 4.10 Controlling Case Sensitivity in String Comparisons 4.10.1 Problem A string comparison is case sensitive when you don't want it to be, or vice versa. 4.10.2 Solution Alter the case sensitivity of the strings. 4.10.3 Discussion The examples in previous sections were performed without regard to lettercase. But sometimes you need to make sure a string operation is case sensitive that would not otherwise be, or vice versa. This section describes how to do that for ordinary comparisons. Recipe 4.11 covers case sensitivity in pattern-matching operations. String comparisons in MySQL are not case sensitive by default: mysql> SELECT name, name = 'lead', name = 'LEAD' FROM metal; +----------+---------------+---------------+ | name | name = 'lead' | name = 'LEAD' | +----------+---------------+---------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 0 | 0 | | lead | 1 | 1 | | mercury | 0 | 0 | | platinum | 0 | 0 | | silver | 0 | 0 | | tin | 0 | 0 | +----------+---------------+---------------+ The lack of case sensitivity also applies to relative ordering comparisons: mysql> SELECT name, name < 'lead', name < 'LEAD' FROM metal; +----------+---------------+---------------+ | name | name < 'lead' | name < 'LEAD' | +----------+---------------+---------------+ | copper | 1 | 1 | | gold | 1 | 1 | | iron | 1 | 1 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 0 | 0 | | silver | 0 | 0 | | tin | 0 | 0 | +----------+---------------+---------------+ If you're familiar with the ASCII collating order, you know that lowercase letters have higher ASCII codes than uppercase letters, so the results in the second comparison column of the preceding query may surprise you. Those results reflect that string ordering is done by default without regard for lettercase, so A and a both are considered lexically less than B. String comparisons are case sensitive only if at least one of the operands is a binary string. To control case sensitivity in string comparisons, use the following techniques: · To make a string comparison case sensitive that normally would not be, cast (convert) one of the strings to binary form by using the BINARY keyword. It doesn't matter which of the strings you make binary. As long as one of them is, the comparison will be case sensitive: mysql> SELECT name, name = BINARY 'lead', BINARY name = 'LEAD' FROM metal; +----------+----------------------+----------------------+ | name | name = BINARY 'lead' | BINARY name = 'LEAD' | +----------+----------------------+----------------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 0 | 0 | | lead | 1 | 0 | | mercury | 0 | 0 | | platinum | 0 | 0 | | silver | 0 | 0 | | tin | 0 | 0 | +----------+----------------------+----------------------+ BINARY is available as a cast operator as of MySQL 3.23. · To make a string comparison not case sensitive that normally would be, convert both strings to the same lettercase using UPPER( ) or LOWER( ): mysql> SELECT UPPER('A'), UPPER('b'), UPPER('A') < UPPER('b'); +------------+------------+-------------------------+ | UPPER('A') | UPPER('b') | UPPER('A') < UPPER('b') | +------------+------------+-------------------------+ | A | B | 1 | +------------+------------+-------------------------+ mysql> SELECT LOWER('A'), LOWER('b'), LOWER('A') < LOWER('b'); +------------+------------+-------------------------+ | LOWER('A') | LOWER('b') | LOWER('A') < LOWER('b') | +------------+------------+-------------------------+ | a | b | 1 | +------------+------------+-------------------------+ The same principles can be applied to string comparison functions. For example, STRCMP( ) takes two string arguments and returns -1, 0, or 1, depending on whether the first string is lexically less than, equal to, or greater than the second. Up through MySQL 4.0.0, STRCMP( ) is case sensitive; it always treats its arguments as binary strings, regardless of their actual type: mysql> SELECT STRCMP('Abc','abc'), STRCMP('abc','abc'), STRCMP('abc','Abc'); +---------------------+---------------------+---------------------+ | STRCMP('Abc','abc') | STRCMP('abc','abc') | STRCMP('abc','Abc') | +---------------------+---------------------+---------------------+ | -1 | 0 | 1 | +---------------------+---------------------+---------------------+ However, as of MySQL 4.0.1, STRCMP( ) is not case sensitive: mysql> SELECT STRCMP('Abc','abc'), STRCMP('abc','abc'), STRCMP('abc','Abc'); +---------------------+---------------------+---------------------+ | STRCMP('Abc','abc') | STRCMP('abc','abc') | STRCMP('abc','Abc') | +---------------------+---------------------+---------------------+ | 0 | 0 | 0 | +---------------------+---------------------+---------------------+ To preserve the pre-4.0.1 behavior, make one of the arguments a binary string: mysql> SELECT STRCMP(BINARY 'Abc','abc'), STRCMP(BINARY 'abc','Abc'); +----------------------------+----------------------------+ | STRCMP(BINARY 'Abc','abc') | STRCMP(BINARY 'abc','Abc') | +----------------------------+----------------------------+ | -1 | 1 | +----------------------------+----------------------------+ By the way, take special note of the fact that zero and nonzero return values from STRCMP( ) indicate equality and inequality. This differs from the = comparison operator, which returns zero and nonzero for inequality and equality. To avoid surprises in string comparisons, know the general rules that determine whether or not a string is binary: · Any literal string, string expression, or string column can be made binary by preceding it with the BINARY keyword. If BINARY is not present, the following rules apply. · A string expression is binary if any of its constituent strings is binary, otherwise not. For example, the result returned by this CONCAT( ) expression is binary because its second argument is binary: CONCAT('This is a ',BINARY 'binary',' string') · A string column is case sensitive or not depending on the column's type. The CHAR and VARCHAR types are not case sensitive by default, but may be declared as BINARY to make them case sensitive. ENUM, SET, and TEXT columns are not case sensitive. BLOB columns are case sensitive. (See the table in Recipe 4.1.) In summary, comparisons are case sensitive if they involve a binary literal string or string expression, or a CHAR BINARY, VARCHAR BINARY, or BLOB column. Comparisons are not case sensitive if they involve only non-binary literal strings or string expressions, or CHAR, VARCHAR, ENUM, SET, or TEXT columns. ENUM and SET columns are not case sensitive. Furthermore, because they are stored internally as numbers, you cannot declare them case sensitive in the table definition by adding the BINARY keyword. However, you can still use the BINARY keyword before ENUM or SET values in comparisons to produce a case sensitive operation. Case Sensitivity and String Comparison Speed In general, case-sensitive comparisons involving binary strings are slightly faster than non-case-sensitive comparisons, because MySQL need not take lettercase into account during the comparison. If you find that you've declared a column using a type that is not suitable for the kind of comparisons for which you typically use it, use ALTER TABLE to change the type. Suppose you have a table in which you store news articles: CREATE TABLE news ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, article BLOB NOT NULL, PRIMARY KEY (id) ); Here the article column is declared as a BLOB, which is a case-sensitive type. Should you wish to convert the column so that it is not case sensitive, you can change the type from BLOB to TEXT using either of these ALTER TABLE statements: ALTER TABLE news MODIFY article TEXT NOT NULL; ALTER TABLE news CHANGE article article TEXT NOT NULL; Prior to MySQL 3.22.16, ALTER TABLE ... MODIFY is unavailable, in which case you can use only ALTER TABLE ... CHANGE. See Chapter 8 for more information. 4.11 Controlling Case Sensitivity in Pattern Matching 4.11.1 Problem A pattern match is case sensitive when you don't want it to be, or vice versa. 4.11.2 Solution Alter the case sensitivity of the strings. 4.11.3 Discussion By default, LIKE is not case sensitive: mysql> SELECT name, name LIKE '%i%', name LIKE '%I%' FROM metal; +----------+-----------------+-----------------+ | name | name LIKE '%i%' | name LIKE '%I%' | +----------+-----------------+-----------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 1 | 1 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 1 | 1 | | silver | 1 | 1 | | tin | 1 | 1 | +----------+-----------------+-----------------+ Currently, REGEXP is not case sensitive, either. mysql> SELECT name, name REGEXP 'i', name REGEXP 'I' FROM metal; +----------+-----------------+-----------------+ | name | name REGEXP 'i' | name REGEXP 'I' | +----------+-----------------+-----------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 1 | 1 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 1 | 1 | | silver | 1 | 1 | | tin | 1 | 1 | +----------+-----------------+-----------------+ However, prior to MySQL 3.23.4, REGEXP operations are case sensitive: mysql> SELECT name, name REGEXP 'i', name REGEXP 'I' FROM metal; +----------+-----------------+-----------------+ | name | name REGEXP 'i' | name REGEXP 'I' | +----------+-----------------+-----------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 1 | 0 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 1 | 0 | | silver | 1 | 0 | | tin | 1 | 0 | +----------+-----------------+-----------------+ Note that the (current) behavior of REGEXP not being case sensitive can lead to some unintuitive results: mysql> SELECT 'a' REGEXP '[[:lower:]]', 'a' REGEXP '[[:upper:]]'; +--------------------------+--------------------------+ | 'a' REGEXP '[[:lower:]]' | 'a' REGEXP '[[:upper:]]' | +--------------------------+--------------------------+ | 1 | 1 | +--------------------------+--------------------------+ Both expressions are true because [:lower:] and [:upper:] are equivalent when case sensitivity doesn't matter. If a pattern match uses different case-sensitive behavior than what you want, control it the same way as for string comparisons: · To make a pattern match case sensitive, use a binary string for either operand (for example, by using the BINARY keyword). The following query shows how the non- binary column name normally is not case sensitive: · mysql> SELECT name, name LIKE '%i%%', name REGEXP 'i' FROM metal; · +----------+------------------+-----------------+ · | name | name LIKE '%i%%' | name REGEXP 'i' | · +----------+------------------+-----------------+ · | copper | 0 | 0 | · | gold | 0 | 0 | · | iron | 1 | 1 | · | lead | 0 | 0 | · | mercury | 0 | 0 | · | platinum | 1 | 1 | · | silver | 1 | 1 | · | tin | 1 | 1 | +----------+------------------+-----------------+ And this query shows how to force name values to be case sensitive using BINARY: mysql> SELECT name, BINARY name LIKE '%I%', BINARY name REGEXP 'I' FROM metal; +----------+------------------------+------------------------+ | name | BINARY name LIKE '%I%' | BINARY name REGEXP 'I' | +----------+------------------------+------------------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 0 | 0 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 0 | 0 | | silver | 0 | 0 | | tin | 0 | 0 | +----------+------------------------+------------------------+ Using BINARY also has the effect of causing [:lower:] and [:upper:] in regular expressions to act as you would expect. The second expression in the following query yields a result that really is true only for uppercase letters: mysql> SELECT 'a' REGEXP '[[:upper:]]', BINARY 'a' REGEXP '[[:upper:]]'; +--------------------------+---------------------------------+ | 'a' REGEXP '[[:upper:]]' | BINARY 'a' REGEXP '[[:upper:]]' | +--------------------------+---------------------------------+ | 1 | 0 | +--------------------------+---------------------------------+ · A pattern match against a binary column is case sensitive. To make the match not case sensitive, make both operands the same lettercase. To see how this works, modify the metal table to add a binname column that is like the name column except that it is VARCHAR BINARY rather than VARCHAR: · mysql> ALTER TABLE metal ADD binname VARCHAR(20) BINARY; mysql> UPDATE metal SET binname = name; The first of the following queries shows how the binary column binname normally is case sensitive in pattern matches, and the second shows how to force it not to be, using UPPER( ): mysql> SELECT binname, binname LIKE '%I%', binname REGEXP 'I' -> FROM metal; +----------+--------------------+--------------------+ | binname | binname LIKE '%I%' | binname REGEXP 'I' | +----------+--------------------+--------------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 0 | 0 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 0 | 0 | | silver | 0 | 0 | | tin | 0 | 0 | +----------+--------------------+--------------------+ mysql> SELECT binname, UPPER(binname) LIKE '%I%', UPPER(binname) REGEXP 'I' -> FROM metal; +----------+---------------------------+---------------------------+ | binname | UPPER(binname) LIKE '%I%' | UPPER(binname) REGEXP 'I' | +----------+---------------------------+---------------------------+ | copper | 0 | 0 | | gold | 0 | 0 | | iron | 1 | 1 | | lead | 0 | 0 | | mercury | 0 | 0 | | platinum | 1 | 1 | | silver | 1 | 1 | | tin | 1 | 1 | +----------+---------------------------+---------------------------+ 4.12 Using FULLTEXT Searches 4.12.1 Problem You want to search through a lot of text. 4.12.2 Solution Use a FULLTEXT index. 4.12.3 Discussion You can use pattern matches to look through any number of rows, but as the amount of text goes up, the match operation can become quite slow. It's also common to look for the same text in several string columns, which with pattern matching tends to result in unwieldy queries: SELECT * from tbl_name WHERE col1 LIKE 'pat' OR col2 LIKE 'pat' OR col3 LIKE 'pat' ... A useful alternative (available as of MySQL 3.23.23) is to use FULLTEXT searching, which is designed for looking through large amounts of text, and can search multiple columns simultaneously. To use this capability, add a FULLTEXT index to your table, then use the MATCH operator to look for strings in the indexed column or columns. FULLTEXT indexing can be used with MyISAM tables, for columns of type CHAR, VARCHAR, or TEXT. FULLTEXT searching is best illustrated with a reasonably good-sized body of text. If you don't have a sample dataset, several repositories of freely available electronic text are available on the Internet. For the examples here, the one I've chosen is the complete text of the King James Version of the Bible (KJV), which is relatively large and has the advantage of being nicely structured by book, chapter, and verse. Because of its size, this dataset is not included with the recipes distribution, but is available separately as the mcb-kjv distribution at the MySQL Cookbook web site.[3] (See Appendix A.) The distribution includes a file kjv.txt that contains the verse records. Some sample records look like this: [3] The mcb-kjv distribution is derived from the KJV text available at the Unbound Bible site at Biola University (http://unbound.biola.edu), but has been modified somewhat to make it easier to use for the recipes in this book. The mcb-kjv distribution includes notes that describe how it differs from the Biola distribution. O Genesis 1 1 1 In the beginning God created the heaven and the earth. O Exodus 2 20 13 Thou shalt not kill. N Luke 42 17 32 Remember Lot's wife. Each record contains the following fields: · Book section. This is either O or N, signifying the Old or New Testament. · Book name and corresponding book number, from 1 to 66. · Chapter and verse numbers. · Text of the verse. To import the records into MySQL, create a table named kjv that looks like this: CREATE TABLE kjv ( bsect ENUM('O','N') NOT NULL, # book section (testament) bname VARCHAR(20) NOT NULL, # book name bnum TINYINT UNSIGNED NOT NULL, # book number cnum TINYINT UNSIGNED NOT NULL, # chapter number vnum TINYINT UNSIGNED NOT NULL, # verse number vtext TEXT NOT NULL # text of verse ) TYPE = MyISAM; Then load the kjv.txt file into the table using this statement: mysql> LOAD DATA LOCAL INFILE 'kjv.txt' INTO TABLE kjv; You'll notice that the kjv table contains columns for both book names (Genesis, Exodus, ...) and book numbers (1, 2, ...). The names and numbers have a fixed correspondence, and one can be derived from the other—a redundancy that means the table is not in normal form. It's possible to eliminate the redundancy by storing just the book numbers (which take less space than the names), and then producing the names when necessary in query results by joining the numbers to a small mapping table that associates each book number with the corresponding name. But I want to avoid using joins at this point. Thus, the table includes book names so that search results can be interpreted more easily, and numbers so that the results can be sorted easily into book order. After populating the table, prepare it for use in FULLTEXT searching by adding a FULLTEXT index. This can be done using an ALTER TABLE statement:[4] [4] It's possible to include the index definition in the initial CREATE TABLE statement, but it's generally faster to create a non-indexed table and then add the index with ALTER TABLE after populating the table than to load a large dataset into an indexed table. mysql> ALTER TABLE kjv ADD FULLTEXT (vtext); To perform a search using the index, use MATCH( ) to name the indexed column and AGAINST( ) to specify what text to look for. For example, to answer the question "How often does the name Mizraim occur?" (you've often wondered about that, right?), search the vtext column using this query: mysql> SELECT COUNT(*) from kjv WHERE MATCH(vtext) AGAINST('Mizraim'); +----------+ | COUNT(*) | +----------+ | 4 | +----------+ To find out what those verses are, select the columns you want to see (the example here uses \G so that the results better fit the page): mysql> SELECT bname, cnum, vnum, vtext -> FROM kjv WHERE MATCH(vtext) AGAINST('Mizraim')\G *************************** 1. row *************************** bname: Genesis cnum: 10 vnum: 6 vtext: And the sons of Ham; Cush, and Mizraim, and Phut, and Canaan. *************************** 2. row *************************** bname: Genesis cnum: 10 vnum: 13 vtext: And Mizraim begat Ludim, and Anamim, and Lehabim, and Naphtuhim, *************************** 3. row *************************** bname: 1 Chronicles cnum: 1 vnum: 8 vtext: The sons of Ham; Cush, and Mizraim, Put, and Canaan. *************************** 4. row *************************** bname: 1 Chronicles cnum: 1 vnum: 11 vtext: And Mizraim begat Ludim, and Anamim, and Lehabim, and Naphtuhim, The results come out in book, chapter, and verse number order in this particular instance, but that's actually just coincidence. By default, FULLTEXT searches compute a relevance ranking and use it for sorting. To make sure a search result is sorted the way you want, add an explicit ORDER BY clause: SELECT bname, cnum, vnum, vtext FROM kjv WHERE MATCH(vtext) AGAINST('search string') ORDER BY bnum, cnum, vnum; You can include additional criteria to narrow the search further. The following queries perform progressively more specific searches to find out how often the name Abraham occurs in the entire KJV, the New Testament, the book of Hebrews, and Chapter 11 of Hebrews: mysql> SELECT COUNT(*) from kjv WHERE MATCH(vtext) AGAINST('Abraham'); +----------+ | COUNT(*) | +----------+ | 216 | +----------+ mysql> SELECT COUNT(*) from kjv -> WHERE MATCH(vtext) AGAINST('Abraham') -> AND bsect = 'N'; +----------+ | COUNT(*) | +----------+ | 66 | +----------+ mysql> SELECT COUNT(*) from kjv -> WHERE MATCH(vtext) AGAINST('Abraham') -> AND bname = 'Hebrews'; +----------+ | COUNT(*) | +----------+ | 10 | +----------+ mysql> SELECT COUNT(*) from kjv -> WHERE MATCH(vtext) AGAINST('Abraham') -> AND bname = 'Hebrews' AND cnum = 11; +----------+ | COUNT(*) | +----------+ | 2 | +----------+ If you expect to use search criteria that include other non-FULLTEXT columns frequently, you can increase the performance of such queries by adding regular indexes to those columns. For example, to index the book, chapter, and verse number columns, do this: mysql> ALTER TABLE kjv ADD INDEX (bnum), ADD INDEX (cnum), ADD INDEX (vnum); Search strings in FULLTEXT queries can include more than just a single word, and you might suppose that adding additional words would make a search more specific. But in fact that widens it, because a FULLTEXT search returns records that contain any of the words. In effect, the query performs an OR search for any of the words. This is illustrated by the following queries, which identify successively larger numbers of verses as additional search words are added: mysql> SELECT COUNT(*) from kjv -> WHERE MATCH(vtext) AGAINST('Abraham'); +----------+ | COUNT(*) | +----------+ | 216 | +----------+ mysql> SELECT COUNT(*) from kjv -> WHERE MATCH(vtext) AGAINST('Abraham Sarah'); +----------+ | COUNT(*) | +----------+ | 230 | +----------+ mysql> SELECT COUNT(*) from kjv -> WHERE MATCH(vtext) AGAINST('Abraham Sarah Ishmael Isaac'); +----------+ | COUNT(*) | +----------+ | 317 | +----------+ To perform a search where each word in the search string must be present, see Recipe 4.14. If you want to use a FULLTEXT search that looks though multiple columns simultaneously, name them all when you construct the index: ALTER TABLE tbl_name ADD FULLTEXT (col1, col2, col3); To issue a search query that uses this index, name those same columns in the MATCH( ) list: SELECT ... FROM tbl_name WHERE MATCH(col1, col2, col3) AGAINST('search string'); 4.12.4 See Also FULLTEXT indexes provide a quick-and-easy way to set up a simple search engine. One way to use this capability is to provide a web-based interface to the indexed text. The MySQL Cookbook site includes a basic web-based KJV search page that demonstrates this. 4.13 Using a FULLTEXT Search with Short Words 4.13.1 Problem FULLTEXT searches for short words return no records. 4.13.2 Solution Change the indexing engine's minimum word length parameter. 4.13.3 Discussion In a text like the KJV, certain words have special significance, such as "God" and "sin." However, if you perform FULLTEXT searches on the kjv table for those words using a MySQL 3.23 server, you'll observe a curious phenomenon—both words appear to be missing from the text entirely: mysql> SELECT COUNT(*) FROM kjv WHERE MATCH(vtext) AGAINST('God'); +----------+ | COUNT(*) | +----------+ | 0 | +----------+ mysql> SELECT COUNT(*) FROM kjv WHERE MATCH(vtext) AGAINST('sin'); +----------+ | COUNT(*) | +----------+ | 0 | +----------+ One property of the indexing engine is that it ignores words that are "too common" (that is, words that occur in more than half the records). This eliminates words such as "the" or "and" from the index, but that's not what is going on here. You can verify that by counting the total number of records, and by using SQL pattern matches to count the number of records containing each word:[5] [5] The use of COUNT( ) to produce multiple counts from the same set of values is described in Recipe 7.2. mysql> SELECT COUNT(*) AS 'total verses', -> COUNT(IF(vtext LIKE '%God%',1,NULL)) AS 'verses containing "God"', -> COUNT(IF(vtext LIKE '%sin%',1,NULL)) AS 'verses containing "sin"' -> FROM kjv; +--------------+-------------------------+-------------------------+ | total verses | verses containing "God" | verses containing "sin" | +--------------+-------------------------+-------------------------+ | 31102 | 4118 | 1292 | +--------------+-------------------------+-------------------------+ Neither word is present in more than half the verses, so sheer frequency of occurrence doesn't account for the failure of a FULLTEXT search to find them. What's really happening is that by default, the indexing engine doesn't include words less than four characters long. On a MySQL 3.23 server, there's nothing you can do about that (at least, nothing short of messing around with the MySQL source code and recompiling). As of MySQL 4.0, the minimum word length is a configurable parameter, which you can change by setting the ft_min_word_len server variable. For example, to tell the indexing engine to include words containing three or more characters, add a set-variable line to the [mysqld] group of the /etc/my.cnf file (or whatever option file you put server settings in): [mysqld] set-variable = ft_min_word_len=3 After making this change and restarting the server, rebuild the FULLTEXT index to take advantage of the new setting: mysql> ALTER TABLE kjv DROP INDEX vtext; mysql> ALTER TABLE kjv ADD FULLTEXT (vtext); Then try out the new index to verify that it includes shorter words: mysql> SELECT COUNT(*) FROM kjv WHERE MATCH(vtext) AGAINST('God'); +----------+ | COUNT(*) | +----------+ | 3878 | +----------+ mysql> SELECT COUNT(*) FROM kjv WHERE MATCH(vtext) AGAINST('sin'); +----------+ | COUNT(*) | +----------+ | 389 | +----------+ That's better! But why do the MATCH( ) queries find 3878 and 389 records, whereas the earlier LIKE queries find 4118 and 1292 records? That's because the LIKE patterns match substrings and the FULLTEXT search performed by MATCH( ) matches whole words. 4.14 Requiring or Excluding FULLTEXT Search Words 4.14.1 Problem You want to specifically require or disallow words in a FULLTEXT search. 4.14.2 Solution Use a Boolean mode search. 4.14.3 Discussion Normally, FULLTEXT searches return records that contain any of the words in the search string, even if some of them are missing. For example, the following query finds records that contain either of the names David or Goliath: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('David Goliath'); +----------+ | COUNT(*) | +----------+ | 934 | +----------+ This behavior is undesirable if you want only records that contain both words. One way to do this is to rewrite the query to look for each word separately and join the conditions with AND: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('David') -> AND MATCH(vtext) AGAINST('Goliath'); +----------+ | COUNT(*) | +----------+ | 2 | +----------+ As of MySQL 4.0.1, another way to require multiple words is with a Boolean mode search. To do this, precede each word in the search string with a + character and add IN BOOLEAN MODE after the string: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('+David +Goliath' IN BOOLEAN MODE) +----------+ | COUNT(*) | +----------+ | 2 | +----------+ Boolean mode searches also allow you to exclude words. Just precede any disallowed word with a - character. The following queries select kjv records containing the name David but not Goliath, or vice versa: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('+David -Goliath' IN BOOLEAN MODE) +----------+ | COUNT(*) | +----------+ | 928 | +----------+ mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('-David +Goliath' IN BOOLEAN MODE) +----------+ | COUNT(*) | +----------+ | 4 | +----------+ Another useful special character in Boolean searches is *; when appended to a search word, it acts as a wildcard operator. The following query finds records containing not only whirl, but also words such as whirls, whirleth, and whirlwind: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('whirl*' IN BOOLEAN MODE); +----------+ | COUNT(*) | +----------+ | 28 | +----------+ 4.15 Performing Phrase Searches with a FULLTEXT Index 4.15.1 Problem You want to perform a FULLTEXT search for a phrase, that is, for words that occur adjacent to each other and in a specific order. 4.15.2 Solution Use the FULLTEXT phrase search capability, or combine a non-phrase FULLTEXT search with regular pattern matching. 4.15.3 Discussion To find records that contain a particular phrase, you can't use a simple FULLTEXT search: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('still small voice'); +----------+ | COUNT(*) | +----------+ | 548 | +----------+ The query returns a result, but it's not the result you're looking for. A FULLTEXT search computes a relevance ranking based on the presence of each word individually, no matter where it occurs within the vtext column, and the ranking will be nonzero as long as any of the words are present. Consequently, this kind of query tends to find too many records. As of MySQL 4.0.2, FULLTEXT searching supports phrase searching in Boolean mode. To use it, just place the phrase within double quotes. mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('"still small voice"' IN BOOLEAN MODE); +----------+ | COUNT(*) | +----------+ | 1 | +----------+ Prior to 4.0.2, a workaround is necessary. You could use an IN BOOLEAN MODE search to require each word to be present, but that doesn't really solve the problem, because the words can still occur in any order: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) -> AGAINST('+still +small +voice' IN BOOLEAN MODE); +----------+ | COUNT(*) | +----------+ | 3 | +----------+ If you use a SQL pattern match instead, it returns the correct result: mysql> SELECT COUNT(*) FROM kjv -> WHERE vtext LIKE '%still small voice%'; +----------+ | COUNT(*) | +----------+ | 1 | +----------+ However, using a SQL pattern match is likely to be slower than a FULLTEXT search. So it seems you have the unpleasant choice of using a method that is faster but doesn't produce the desired results, or one that works properly but is slower. Fortunately, those aren't your only options. You can combine both methods in the same query: mysql> SELECT COUNT(*) FROM kjv -> WHERE MATCH(vtext) AGAINST('still small voice') -> AND vtext LIKE '%still small voice%'; +----------+ | COUNT(*) | +----------+ | 1 | +----------+ What this gains you is the best of both types of matching: · Using the MATCH( ) expression, MySQL can perform a FULLTEXT search to produce a set of candidate rows that contain words in the phrase. This narrows the search considerably. · Using the SQL pattern test, MySQL can search the candidate rows to produce only those records that have all the words arranged in the proper order. This technique will fail if all the words are less than the indexing engine's minimum word length or occur in more than half the records. In that case, the FULLTEXT search returns no records at all. You can find the records using a SQL pattern match. Chapter 5. Working with Dates and Times Section 5.1. Introduction Section 5.2. Changing MySQL's Date Format Section 5.3. Telling MySQL How to Display Dates or Times Section 5.4. Determining the Current Date or Time Section 5.5. Decomposing Dates and Times Using Formatting Functions Section 5.6. Decomposing Dates or Times Using Component-Extraction Functions Section 5.7. Decomposing Dates or Times Using String Functions Section 5.8. Synthesizing Dates or Times Using Formatting Functions Section 5.9. Synthesizing Dates or Times Using Component-Extraction Functions Section 5.10. Combining a Date and a Time into a Date-and-Time Value Section 5.11. Converting Between Times and Seconds Section 5.12. Converting Between Dates and Days Section 5.13. Converting Between Date-and-Time Values and Seconds Section 5.14. Adding a Temporal Interval to a Time Section 5.15. Calculating Intervals Between Times Section 5.16. Breaking Down Time Intervals into Components Section 5.17. Adding a Temporal Interval to a Date Section 5.18. Calculating Intervals Between Dates Section 5.19. Canonizing Not-Quite-ISO Date Strings Section 5.20. Calculating Ages Section 5.21. Shifting Dates by a Known Amount Section 5.22. Finding First and Last Days of Months Section 5.23. Finding the Length of a Month Section 5.24. Calculating One Date from Another by Substring Replacement Section 5.25. Finding the Day of the Week for a Date Section 5.26. Finding Dates for Days of the Current Week Section 5.27. Finding Dates for Weekdays of Other Weeks Section 5.28. Performing Leap Year Calculations Section 5.29. Treating Dates or Times as Numbers Section 5.30. Forcing MySQL to Treat Strings as Temporal Values Section 5.31. Selecting Records Based on Their Temporal Characteristics Section 5.32. Using TIMESTAMP Values Section 5.33. Recording a Row's Last Modification Time Section 5.34. Recording a Row's Creation Time Section 5.35. Performing Calculations with TIMESTAMP Values Section 5.36. Displaying TIMESTAMP Values in Readable Form 5.1 Introduction MySQL has several data types for representing dates and times, and several functions for operating on them. MySQL stores dates and times in specific formats. It's important to understand them to avoid surprises in how MySQL interprets input data. MySQL also has reformatting functions for producing date and time output in formats other than the default. This chapter covers the following aspects of working with temporal values in MySQL: · Displaying dates and times. MySQL displays temporal values using specific formats by default, but you can produce other formats by calling the appropriate function. · Determining the current date or time. MySQL provides functions that return the date and time, which is useful for applications that need to know these values or need to calculate other temporal values in relation to them. · Decomposing dates or times into component values. This section explains how to split date and time values when you need only a piece, such as the month part or the hour part. · Synthesizing dates and times from component values. The complement of splitting apart temporal values is to create them from subparts. This section shows how. · Converting between dates or times and basic units. Some date calculations are more easily performed using the number of days or seconds represented by a date or time value than by using the value itself. MySQL makes it possible to perform several kinds of conversions between date and time values and more basic units such as days or seconds. These conversions often are useful for interval calculations (such as time elapsed between two times). · Date and time arithmetic. It's possible in MySQL to add temporal intervals to date or time values to produce other dates or times, and to calculate the interval between dates or times. Time arithmetic is easier than date arithmetic. Times involve hours, minutes, and seconds— units that always have a fixed duration. Date arithmetic can be trickier because units such as months and years vary in length. · Applications for date and time arithmetic. Using the techniques from the earlier sections, this one shows how to perform age calculation, relative date computation, date shifting, and leap year calculation. · Selecting records based on temporal constraints. The calculations discussed in the preceding sections to produce output values can also be used in WHERE clauses to specify how to select records using temporal conditions. · Using TIMESTAMP values. The TIMESTAMP column type has some special properties that make it convenient for automatically recording record creation and modification times. This section describes how TIMESTAMP columns behave and how to use them. It also discusses how to display TIMESTAMP values in more readable formats. This chapter covers many of MySQL's functions for operating on date and time values, but there are yet others. To familiarize yourself with the full set, consult the MySQL Reference Manual. The variety of functions available to you means that it's often possible to perform a given temporal calculation more than one way. I sometimes illustrate alternative methods for achieving a given result, but many of the problems addressed in this chapter can be solved in other ways than are shown here. I invite you to experiment to find other solutions. You may find a method that's more efficient or that you find more readable. Scripts that implement the recipes discussed in this chapter can be found in the dates directory of the recipes source distribution. The scripts that create the tables used here are located in the tables directory. 5.1.1 MySQL's Date and Time Formats MySQL provides DATE and TIME column types for representing date and time values separately, and a DATETIME type for combined date-and-time values. These values have the following formats: · DATE values are handled as strings in CCYY-MM-DD format, where CC, YY, MM, and DD represent the century, year within century, month, and day parts of the date. · TIME values are represented as strings in hh:mm:ss format, where hh, mm, and ss are the hours, minutes, and seconds parts of the time. TIME values often can be thought of as time-of-day values, but MySQL actually treats them as elapsed time. Thus, they may be greater than 23:59:59 or even negative. (The actual range is - 838:59:59 to 838:59:59.) · DATETIME values are represented as combined date-and-time strings in CCYY-MM-DD hh:mm:ss format. · TIMESTAMP values also include date and time parts, but are represented as strings in CCYYMMDDhhmmss format. This column type also has special properties that are discussed further in Recipe 5.32. More examples in this chapter use DATETIME values than TIMESTAMP values (which are less readable), but in most respects, you can treat the two column types the same way. Many of the examples in this chapter draw on the following tables, which contain columns representing TIME, DATE, DATETIME, and TIMESTAMP values. (The time_val table has two columns for use in time interval calculation examples.) mysql> SELECT t1, t2 FROM time_val; +----------+----------+ | t1 | t2 | +----------+----------+ | 15:00:00 | 15:00:00 | | 05:01:30 | 02:30:20 | | 12:30:20 | 17:30:45 | +----------+----------+ mysql> SELECT d FROM date_val; +------------+ | d | +------------+ | 1864-02-28 | | 1900-01-15 | | 1987-03-05 | | 1999-12-31 | | 2000-06-04 | +------------+ mysql> SELECT dt FROM datetime_val; +---------------------+ | dt | +---------------------+ | 1970-01-01 00:00:00 | | 1987-03-05 12:30:15 | | 1999-12-31 09:00:00 | | 2000-06-04 15:45:30 | +---------------------+ mysql> SELECT ts FROM timestamp_val; +----------------+ | ts | +----------------+ | 19700101000000 | | 19870305123015 | | 19991231090000 | | 20000604154530 | +----------------+ 5.2 Changing MySQL's Date Format 5.2.1 Problem You want to change the format that MySQL uses for representing date values. 5.2.2 Solution You can't. However, you can rewrite input values into the proper format when storing dates, and you can rewrite them into fairly arbitrary format for display by using the DATE_FORMAT( ) function. 5.2.3 Discussion The CCYY-MM-DD format that MySQL uses for DATE values follows the ISO 8601 standard for representing dates. This format has the useful property that because the year, month, and day parts have a fixed length and appear left to right in date strings, dates sort naturally into the proper temporal order.[1] However, ISO format is not used by all database systems, which can cause problems if you want to move data between different systems. Moreover, people commonly like to represent dates in other formats such as MM/DD/YY or DD-MM-CCYY. This too can be a source of trouble, due to mismatches between human expectations of what dates should look like and the way MySQL actually represents them. [1] Chapters Chapter 6 and Chapter 7 discuss ordering and grouping techniques for date-based values. A frequent question from people who are new to MySQL is, "How do I tell MySQL to store dates in a specific format such as MM/DD/CCYY?" Sorry, you can't. MySQL always stores dates in ISO format, a fact that has implications both for data entry and for result set display: · For data entry purposes, to store values that are not in ISO format, you normally must rewrite them first. (If you don't want to rewrite your dates, you'll need to store them as strings, for example, in a CHAR column. But then you can't operate on them as dates.) In some cases, if your values are close to ISO format, rewriting may not be necessary. For example, the string values 87-1-7 and 1987-1-7 and the numbers 870107 and 19870107 all are interpreted by MySQL as the date 1987-01-07 when loaded into a DATE column. The topic of date rewriting for data entry is covered in Chapter 10. · For display purposes, you can present dates in non-ISO format by rewriting them. MySQL's DATE_FORMAT( ) function can be helpful here. It provides a lot of flexibility for producing whatever format you want (see Recipe 5.3 and Recipe 5.5). You can also use functions such as YEAR( ) to extract parts of dates (see Recipe 5.6). Additional discussion may be found in Chapter 10, which includes a short script that dumps table contents with the date columns reformatted. 5.3 Telling MySQL How to Display Dates or Times 5.3.1 Problem You want to display dates or times in a format other than what MySQL uses by default. 5.3.2 Solution Use the DATE_FORMAT( ) or TIME_FORMAT( ) functions to rewrite them. 5.3.3 Discussion As already noted, MySQL displays dates in ISO format unless you tell it otherwise. To rewrite date values into other formats, use the DATE_FORMAT( ) function, which takes two arguments: a DATE, DATETIME, or TIMESTAMP value, and a string describing how to display the value. Within the formatting string, you indicate what to display using special sequences of the form %c, where c specifies which part of the date to display. For example, %Y, %M, and %d signify the four-digit year, the month name, and the two-digit day of the month. The following query shows the values in the date_val table, both as MySQL displays them by default and as reformatted with DATE_FORMAT( ): mysql> SELECT d, DATE_FORMAT(d,'%M %d, %Y') FROM date_val; +------------+----------------------------+ | d | DATE_FORMAT(d,'%M %d, %Y') | +------------+----------------------------+ | 1864-02-28 | February 28, 1864 | | 1900-01-15 | January 15, 1900 | | 1987-03-05 | March 05, 1987 | | 1999-12-31 | December 31, 1999 | | 2000-06-04 | June 04, 2000 | +------------+----------------------------+ Clearly, DATE_FORMAT( ) tends to produce rather long column headings, so it's often useful to provide an alias to make a heading more concise or meaningful: mysql> SELECT d, DATE_FORMAT(d,'%M %d, %Y') AS date FROM date_val; +------------+-------------------+ | d | date | +------------+-------------------+ | 1864-02-28 | February 28, 1864 | | 1900-01-15 | January 15, 1900 | | 1987-03-05 | March 05, 1987 | | 1999-12-31 | December 31, 1999 | | 2000-06-04 | June 04, 2000 | +------------+-------------------+ The MySQL Reference Manual provides a complete list of format sequences. Some of the more common ones are shown in the following table: Sequence Meaning %Y Four-digit year %y Two-digit year %M Complete month name %b Month name, initial three letters %m Two-digit month of year (01..12) %c Month of year (1..12) %d Two-digit day of month (01..31) %e Day of month (1..31) %r 12-hour time with AM or PM suffix %T 24-hour time %H Two-digit hour %i Two-digit minute %s Two-digit second %% Literal % The time-related format sequences shown in the table are useful only when you pass DATE_FORMAT( ) a value that has both date and time parts (a DATETIME or TIMESTAMP). The following query demonstrates how to display DATETIME values from the datetime_val table using formats that include the time of day: mysql> SELECT dt, -> DATE_FORMAT(dt,'%c/%e/%y %r') AS format1, -> DATE_FORMAT(dt,'%M %e, %Y %T') AS format2 -> FROM datetime_val; +---------------------+----------------------+----------------------------+ | dt | format1 | format2 | +---------------------+----------------------+----------------------------+ | 1970-01-01 00:00:00 | 1/1/70 12:00:00 AM | January 1, 1970 00:00:00 | | 1987-03-05 12:30:15 | 3/5/87 12:30:15 PM | March 5, 1987 12:30:15 | | 1999-12-31 09:00:00 | 12/31/99 09:00:00 AM | December 31, 1999 09:00:00 | | 2000-06-04 15:45:30 | 6/4/00 03:45:30 PM | June 4, 2000 15:45:30 | +---------------------+----------------------+----------------------------+ TIME_FORMAT( ) is similar to DATE_FORMAT( ), but understands only time-related specifiers in the format string. TIME_FORMAT( ) works with TIME, DATETIME, or TIMESTAMP values. mysql> SELECT dt, -> TIME_FORMAT(dt, '%r') AS '12-hour time', -> TIME_FORMAT(dt, '%T') AS '24-hour time' -> FROM datetime_val; +---------------------+--------------+--------------+ | dt | 12-hour time | 24-hour time | +---------------------+--------------+--------------+ | 1970-01-01 00:00:00 | 12:00:00 AM | 00:00:00 | | 1987-03-05 12:30:15 | 12:30:15 PM | 12:30:15 | | 1999-12-31 09:00:00 | 09:00:00 AM | 09:00:00 | | 2000-06-04 15:45:30 | 03:45:30 PM | 15:45:30 | +---------------------+--------------+--------------+ 5.4 Determining the Current Date or Time 5.4.1 Problem What's the date? What time is it? 5.4.2 Solution Use the NOW( ), CURDATE( ), or CURTIME( ) functions. 5.4.3 Discussion Some applications need to know the current date or time, such as those that produce a datestamped or timestamped status display. This kind of information is also useful for date calculations that are performed in relation to the current date, such as finding the first (or last) day of the month, or determining the date for Wednesday of next week. The current date and time are available through three functions. NOW( ) returns both the current date and time. CURDATE( ) and CURTIME( ) return the date and time separately: mysql> SELECT NOW( ), CURDATE( ), CURTIME( ); +---------------------+------------+-----------+ | NOW( ) | CURDATE( ) | CURTIME( ) | +---------------------+------------+-----------+ | 2002-07-15 10:59:30 | 2002-07-15 | 10:59:30 | +---------------------+------------+-----------+ CURRENT_TIMESTAMP and SYSDATE( ) are synonyms for NOW( ). CURRENT_DATE and CURRENT_TIME are synonyms for CURDATE( ) and CURTIME( ). If you want to obtain subparts of these values (such as the current day of the month or current hour of the day), read the next few sections. NOW( ) Is Not a Valid Column Default Value Functions such as NOW( ) and CURDATE( ) are commonly (but mistakenly) used in CREATE TABLE statements as default values: mysql> CREATE TABLE testtbl (dt DATETIME DEFAULT NOW( )); You have an error in your SQL syntax near 'NOW( ))' at line 1 The intent here is that values of the dt column should be initialized automatically to the date and time at which records are created. But it won't work; default values in MySQL must be constants. If you want a column set to the current date and time at record creation, use a TIMESTAMP, which MySQL will initialize automatically, or use a DATETIME and set the initial value yourself when you create records. The restriction on non-constant default values will be lifted in the future, during the development of MySQL 4.1. 5.5 Decomposing Dates and Times Using Formatting Functions 5.5.1 Problem You want to obtain just a part of a date or a time. 5.5.2 Solution Use a formatting function such as DATE_FORMAT( ) or TIME_FORMAT( ) with a format string that includes a specifier for the part of the value you want to obtain. 5.5.3 Discussion MySQL provides several options for decomposing dates or times to obtain their component values. The DATE_FORMAT( ) and TIME_FORMAT( ) functions provide one way to extract individual parts of temporal values: mysql> SELECT dt, -> DATE_FORMAT(dt,'%Y') AS year, -> DATE_FORMAT(dt,'%d') AS day, -> TIME_FORMAT(dt,'%H') AS hour, -> TIME_FORMAT(dt,'%s') AS second -> FROM datetime_val; +---------------------+------+------+------+--------+ | dt | year | day | hour | second | +---------------------+------+------+------+--------+ | 1970-01-01 00:00:00 | 1970 | 01 | 00 | 00 | | 1987-03-05 12:30:15 | 1987 | 05 | 12 | 15 | | 1999-12-31 09:00:00 | 1999 | 31 | 09 | 00 | | 2000-06-04 15:45:30 | 2000 | 04 | 15 | 30 | +---------------------+------+------+------+--------+ Formatting functions allow you to extract more than one part of a value. For example, to extract the entire date or time from DATETIME values, do this: mysql> SELECT dt, -> DATE_FORMAT(dt,'%Y-%m-%d') AS 'date part', -> TIME_FORMAT(dt,'%T') AS 'time part' -> FROM datetime_val; +---------------------+------------+-----------+ | dt | date part | time part | +---------------------+------------+-----------+ | 1970-01-01 00:00:00 | 1970-01-01 | 00:00:00 | | 1987-03-05 12:30:15 | 1987-03-05 | 12:30:15 | | 1999-12-31 09:00:00 | 1999-12-31 | 09:00:00 | | 2000-06-04 15:45:30 | 2000-06-04 | 15:45:30 | +---------------------+------------+-----------+ One advantage of using formatting functions is that you can display the extracted values in a different form than that in which they're present in the original values. If you want to present a date differently than in CCYY-MM-DD format or present a time without the seconds part, that's easy to do: mysql> SELECT ts, -> DATE_FORMAT(ts,'%M %e, %Y') AS 'descriptive date', -> TIME_FORMAT(ts,'%H:%i') AS 'hours/minutes' -> FROM timestamp_val; +----------------+-------------------+---------------+ | ts | descriptive date | hours/minutes | +----------------+-------------------+---------------+ | 19700101000000 | January 1, 1970 | 00:00 | | 19870305123015 | March 5, 1987 | 12:30 | | 19991231090000 | December 31, 1999 | 09:00 | | 20000604154530 | June 4, 2000 | 15:45 | +----------------+-------------------+---------------+ 5.5.4 See Also Recipe 5.6 discusses other functions that may be used to extract single components from dates or times. Recipe 5.7 shows how to use substring functions for component extraction. 5.6 Decomposing Dates or Times Using Component-Extraction Functions 5.6.1 Problem You want to obtain just a part of a date or a time. 5.6.2 Solution Invoke a function specifically intended for extracting part of a temporal value, such as MONTH( ) or MINUTE( ). For obtaining single components of temporal values, these functions are faster than using DATE_FORMAT( ) for the equivalent operation. 5.6.3 Discussion MySQL includes many functions for extracting date or time parts from temporal values. Some of these are shown in the following list; consult the MySQL Reference Manual for a complete list. The date-related functions work with DATE, DATETIME, or TIMESTAMP values. The time- related functions work with TIME, DATETIME, or TIMESTAMP values. Function Return Value YEAR( ) Year of date MONTH( ) Month number (1..12) MONTHNAME( ) Month name (January..December) DAYOFMONTH( ) Day of month (1..31) DAYNAME( ) Day of week (Sunday..Saturday) DAYOFWEEK( ) Day of week (1..7 for Sunday..Saturday) WEEKDAY( ) Day of week (0..6 for Monday..Sunday) DAYOFYEAR( ) Day of year (1..366) HOUR( ) Hour of time (0..23) MINUTE( ) Minute of time (0..59) SECOND( ) Second of time (0..59) Here's an example: mysql> SELECT dt, -> YEAR(dt), DAYOFMONTH(dt), -> HOUR(dt), SECOND(dt) -> FROM datetime_val; +---------------------+----------+----------------+----------+------------+ | dt | YEAR(dt) | DAYOFMONTH(dt) | HOUR(dt) | SECOND(dt) | +---------------------+----------+----------------+----------+------------+ | 1970-01-01 00:00:00 | 1970 | 1 | 0 | 0 | | 1987-03-05 12:30:15 | 1987 | 5 | 12 | 15 | | 1999-12-31 09:00:00 | 1999 | 31 | 9 | 0 | | 2000-06-04 15:45:30 | 2000 | 4 | 15 | 30 | +---------------------+----------+----------------+----------+------------+ Functions such as YEAR( ) or DAYOFMONTH( ) extract values that have an obvious correspondence to a substring of date values. Some date extraction functions provide access to values that have no such correspondence. One is the day-of-year value: mysql> SELECT d, DAYOFYEAR(d) FROM date_val; +------------+--------------+ | d | DAYOFYEAR(d) | +------------+--------------+ | 1864-02-28 | 59 | | 1900-01-15 | 15 | | 1987-03-05 | 64 | | 1999-12-31 | 365 | | 2000-06-04 | 156 | +------------+--------------+ Another is the day of the week, which can be obtained either by name or by number: · DAYNAME( ) returns the complete day name. There is no function for returning the three-character name abbreviation, but you can get it easily by passing the full name to LEFT( ): · mysql> SELECT d, DAYNAME(d), LEFT(DAYNAME(d),3) FROM date_val; · +------------+------------+--------------------+ · | d | DAYNAME(d) | LEFT(DAYNAME(d),3) | · +------------+------------+--------------------+ · | 1864-02-28 | Sunday | Sun | · | 1900-01-15 | Monday | Mon | · | 1987-03-05 | Thursday | Thu | · | 1999-12-31 | Friday | Fri | · | 2000-06-04 | Sunday | Sun | +------------+------------+--------------------+ · To get the day of the week as a number, use DAYOFWEEK( ) or WEEKDAY( )—but pay attention to the range of values each function returns. DAYOFWEEK( ) returns values from 1 to 7, corresponding to Sunday through Saturday. WEEKDAY( ) returns values from 0 to 6, corresponding to Monday through Sunday. · mysql> SELECT d, DAYNAME(d), DAYOFWEEK(d), WEEKDAY(d) FROM date_val; · +------------+------------+--------------+------------+ · | d | DAYNAME(d) | DAYOFWEEK(d) | WEEKDAY(d) | · +------------+------------+--------------+------------+ · | 1864-02-28 | Sunday | 1 | 6 | · | 1900-01-15 | Monday | 2 | 0 | · | 1987-03-05 | Thursday | 5 | 3 | · | 1999-12-31 | Friday | 6 | 4 | · | 2000-06-04 | Sunday | 1 | 6 | +------------+------------+--------------+------------+ Another way to obtain individual parts of temporal values is to use the EXTRACT( ) function: mysql> SELECT dt, -> EXTRACT(DAY FROM dt), -> EXTRACT(HOUR FROM dt) -> FROM datetime_val; +---------------------+----------------------+-----------------------+ | dt | EXTRACT(DAY FROM dt) | EXTRACT(HOUR FROM dt) | +---------------------+----------------------+-----------------------+ | 1970-01-01 00:00:00 | 1 | 0 | | 1987-03-05 12:30:15 | 5 | 12 | | 1999-12-31 09:00:00 | 31 | 9 | | 2000-06-04 15:45:30 | 4 | 15 | +---------------------+----------------------+-----------------------+ The keyword indicating what to extract should be a unit specifier such as YEAR, MONTH, DAY, HOUR, MINUTE, or SECOND. The EXTRACT( ) function is available as of MySQL 3.23.0. Obtaining the Current Year, Month, Day, Hour, Minute, or Second The extraction functions shown in this section can be applied to CURDATE( ) or NOW( ) to obtain the current year, month, day, or day of week: mysql> SELECT CURDATE( ), YEAR(CURDATE( )) AS year, -> MONTH(CURDATE( )) AS month, MONTHNAME(CURDATE( )) AS monthname, -> DAYOFMONTH(CURDATE( )) AS day, DAYNAME(CURDATE( )) AS dayname; +------------+------+-------+-----------+------+---------+ | CURDATE( ) | year | month | monthname | day | dayname | +------------+------+-------+-----------+------+---------+ | 2002-07-15 | 2002 | 7 | July | 15 | Monday | +------------+------+-------+-----------+------+---------+ Similarly, you can obtain the current hour, minute, and second by passing CURTIME( ) or NOW( ) to a time-component function: mysql> SELECT NOW( ), HOUR(NOW( )) AS hour, -> MINUTE(NOW( )) AS minute, SECOND(NOW( )) AS second; +---------------------+------+--------+--------+ | NOW( ) | hour | minute | second | +---------------------+------+--------+--------+ | 2002-07-15 11:21:12 | 11 | 21 | 12 | +---------------------+------+--------+--------+ 5.6.4 See Also The functions discussed in this recipe provide single components of temporal values. If you want to produce a value consisting of multiple components from a given value, it may be more convenient to use DATE_FORMAT( ). See Recipe 5.5. 5.7 Decomposing Dates or Times Using String Functions 5.7.1 Problem You want to obtain just a part of a date or a time. 5.7.2 Solution Treat a temporal value as a string and use a function such as LEFT( ) or MID( ) to extract substrings corresponding to the desired part of the value. 5.7.3 Discussion Recipe 5.5 and Recipe 5.6 discuss how to extract components of temporal values using DATE_FORMAT( ) or functions such as YEAR( ) and MONTH( ). If you pass a date or time value to a string function, MySQL treats it as a string, which means you can extract substrings. Thus, yet another way to extract pieces of temporal values is to use string functions such as LEFT( ) or MID( ). mysql> SELECT dt, -> LEFT(dt,4) AS year, -> MID(dt,9,2) AS day, -> RIGHT(dt,2) AS second -> FROM datetime_val; +---------------------+------+------+--------+ | dt | year | day | second | +---------------------+------+------+--------+ | 1970-01-01 00:00:00 | 1970 | 01 | 00 | | 1987-03-05 12:30:15 | 1987 | 05 | 15 | | 1999-12-31 09:00:00 | 1999 | 31 | 00 | | 2000-06-04 15:45:30 | 2000 | 04 | 30 | +---------------------+------+------+--------+ You can pull out the entire date or time part from DATETIME values using string-extraction functions such as LEFT( ) or RIGHT( ): mysql> SELECT dt, -> LEFT(dt,10) AS date, -> RIGHT(dt,8) AS time -> FROM datetime_val; +---------------------+------------+----------+ | dt | date | time | +---------------------+------------+----------+ | 1970-01-01 00:00:00 | 1970-01-01 | 00:00:00 | | 1987-03-05 12:30:15 | 1987-03-05 | 12:30:15 | | 1999-12-31 09:00:00 | 1999-12-31 | 09:00:00 | | 2000-06-04 15:45:30 | 2000-06-04 | 15:45:30 | +---------------------+------------+----------+ The same technique also works for TIMESTAMP values. However, because these contain no delimiter characters, the indexes for LEFT( ) and RIGHT( ) are a little different, as are the formats of the output values: mysql> SELECT ts, -> LEFT(ts,8) AS date, -> RIGHT(ts,6) AS time -> FROM timestamp_val; +----------------+----------+--------+ | ts | date | time | +----------------+----------+--------+ | 19700101000000 | 19700101 | 000000 | | 19870305123015 | 19870305 | 123015 | | 19991231090000 | 19991231 | 090000 | | 20000604154530 | 20000604 | 154530 | +----------------+----------+--------+ Decomposition of temporal values with string functions is subject to a couple of constraints that component extraction and reformatting functions are not bound by: · To use a substring function such as LEFT( ), MID( ), or RIGHT( ), you must have fixed-length strings. MySQL might interpret the value 1987-1-1 as 1987-01-01 if you insert it into a DATE column, but using RIGHT('1987-1-1',2) to extract the day part will not work. If the values have variable-length substrings, you may be able to use SUBSTRING_INDEX( ) instead. Alternatively, if your values are close to ISO format, you can standardize them using the techniques described in Recipe 5.19. · String functions cannot be used to obtain values that don't correspond to substrings of a date value, such as the day of the week or the day of the year. 5.8 Synthesizing Dates or Times Using Formatting Functions 5.8.1 Problem You want to produce a new date from a given date by replacing parts of its values. 5.8.2 Solution Use DATE_FORMAT( ) or TIME_FORMAT( ) to combine parts of the existing value with parts you want to replace. 5.8.3 Discussion The complement of splitting apart a date or time value is synthesizing one from its constituent parts. Techniques for date and time synthesis include using formatting functions (discussed here) and string concatenation (discussed in Recipe 5.9). Date synthesis often is performed by beginning with a given date, then keeping parts that you want to use and replacing the rest. For example, to find the first day of the month in which a date falls, use DATE_FORMAT( ) to extract the year and month parts from the date and combine them with a day value of 01: mysql> SELECT d, DATE_FORMAT(d,'%Y-%m-01') FROM date_val; +------------+---------------------------+ | d | DATE_FORMAT(d,'%Y-%m-01') | +------------+---------------------------+ | 1864-02-28 | 1864-02-01 | | 1900-01-15 | 1900-01-01 | | 1987-03-05 | 1987-03-01 | | 1999-12-31 | 1999-12-01 | | 2000-06-04 | 2000-06-01 | +------------+---------------------------+ TIME_FORMAT( ) can be used in a similar way: mysql> SELECT t1, TIME_FORMAT(t1,'%H:%i:00') FROM time_val; +----------+----------------------------+ | t1 | TIME_FORMAT(t1,'%H:%i:00') | +----------+----------------------------+ | 15:00:00 | 15:00:00 | | 05:01:30 | 05:01:00 | | 12:30:20 | 12:30:00 | +----------+----------------------------+ 5.9 Synthesizing Dates or Times Using Component-Extraction Functions 5.9.1 Problem You have the parts of a date or time and want to combine them to produce a date or time value. 5.9.2 Solution Put the parts together using CONCAT( ). 5.9.3 Discussion Another way to construct temporal values is to use date-part extraction functions in conjunction with CONCAT( ). However, this method often is messier than the DATE_FORMAT( ) technique discussed in Recipe 5.8—and it sometimes yields slightly different results: mysql> SELECT d, -> CONCAT(YEAR(d),'-',MONTH(d),'-01') -> FROM date_val; +------------+------------------------------------+ | d | CONCAT(YEAR(d),'-',MONTH(d),'-01') | +------------+------------------------------------+ | 1864-02-28 | 1864-2-01 | | 1900-01-15 | 1900-1-01 | | 1987-03-05 | 1987-3-01 | | 1999-12-31 | 1999-12-01 | | 2000-06-04 | 2000-6-01 | +------------+------------------------------------+ Note that the month values in some of these dates have only a single digit. To ensure that the month has two digits—as required for ISO format—use LPAD( ) to add a leading zero as necessary: mysql> SELECT d, -> CONCAT(YEAR(d),'-',LPAD(MONTH(d),2,'0'),'-01') -> FROM date_val; +------------+------------------------------------------------+ | d | CONCAT(YEAR(d),'-',LPAD(MONTH(d),2,'0'),'-01') | +------------+------------------------------------------------+ | 1864-02-28 | 1864-02-01 | | 1900-01-15 | 1900-01-01 | | 1987-03-05 | 1987-03-01 | | 1999-12-31 | 1999-12-01 | | 2000-06-04 | 2000-06-01 | +------------+------------------------------------------------+ Another way to solve this problem is given in Recipe 5.19. TIME values can be produced from hours, minutes, and seconds values using methods analogous to those for creating DATE values. For example, to change a TIME value so that its seconds part is 00, extract the hour and minute parts, then recombine them using TIME_FORMAT( ) or CONCAT( ): mysql> SELECT t1, -> TIME_FORMAT(t1,'%H:%i:00') AS method1, -> CONCAT(LPAD(HOUR(t1),2,'0'),':',LPAD(MINUTE(t1),2,'0'),':00') AS method2 -> FROM time_val; +----------+----------+----------+ | t1 | method1 | method2 | +----------+----------+----------+ | 15:00:00 | 15:00:00 | 15:00:00 | | 05:01:30 | 05:01:00 | 05:01:00 | | 12:30:20 | 12:30:00 | 12:30:00 | +----------+----------+----------+ 5.10 Combining a Date and a Time into a Date-and-Time Value 5.10.1 Problem You want to produce a combined date-and-time value from separate date and time values. 5.10.2 Solution Concatenate them with a space in between. 5.10.3 Discussion Combining a date value and a time value to produce a date-and-time value is just a matter of concatenating them with a space in between: mysql> SET @d = '2002-02-28'; mysql> SET @t = '13:10:05'; mysql> SELECT @d, @t, CONCAT(@d,' ',@t); +------------+----------+---------------------+ | @d | @t | CONCAT(@d,' ',@t) | +------------+----------+---------------------+ | 2002-02-28 | 13:10:05 | 2002-02-28 13:10:05 | +------------+----------+---------------------+ 5.11 Converting Between Times and Seconds 5.11.1 Problem You have a time value but you want a value in seconds, or vice versa. 5.11.2 Solution TIME values are specialized representations of a simpler unit—seconds—and you can convert back and forth from one to the other using TIME_TO_SEC( ) and SEC_TO_TIME( ). 5.11.3 Discussion TIME_TO_SEC( ) converts a TIME value to the equivalent number of seconds, and SEC_TO_TIME( ) does the opposite. The following query demonstrates a simple conversion in both directions: mysql> SELECT t1, -> TIME_TO_SEC(t1) AS 'TIME to seconds', -> SEC_TO_TIME(TIME_TO_SEC(t1)) AS 'TIME to seconds to TIME' -> FROM time_val; +----------+-----------------+-------------------------+ | t1 | TIME to seconds | TIME to seconds to TIME | +----------+-----------------+-------------------------+ | 15:00:00 | 54000 | 15:00:00 | | 05:01:30 | 18090 | 05:01:30 | | 12:30:20 | 45020 | 12:30:20 | +----------+-----------------+-------------------------+ To express time values as minutes, hours, or days, perform the appropriate divisions: mysql> SELECT t1, -> TIME_TO_SEC(t1) AS 'seconds', -> TIME_TO_SEC(t1)/60 AS 'minutes', -> TIME_TO_SEC(t1)/(60*60) AS 'hours', -> TIME_TO_SEC(t1)/(24*60*60) AS 'days' -> FROM time_val; +----------+---------+---------+-------+------+ | t1 | seconds | minutes | hours | days | +----------+---------+---------+-------+------+ | 15:00:00 | 54000 | 900.00 | 15.00 | 0.62 | | 05:01:30 | 18090 | 301.50 | 5.03 | 0.21 | | 12:30:20 | 45020 | 750.33 | 12.51 | 0.52 | +----------+---------+---------+-------+------+ Use FLOOR( ) if you prefer integer values to floating-point values: mysql> SELECT t1, -> TIME_TO_SEC(t1) AS 'seconds', -> FLOOR(TIME_TO_SEC(t1)/60) AS 'minutes', -> FLOOR(TIME_TO_SEC(t1)/(60*60)) AS 'hours', -> FLOOR(TIME_TO_SEC(t1)/(24*60*60)) AS 'days' -> FROM time_val; +----------+---------+---------+-------+------+ | t1 | seconds | minutes | hours | days | +----------+---------+---------+-------+------+ | 15:00:00 | 54000 | 900 | 15 | 0 | | 05:01:30 | 18090 | 301 | 5 | 0 | | 12:30:20 | 45020 | 750 | 12 | 0 | +----------+---------+---------+-------+------+ If you pass TIME_TO_SEC( ) a date-and-time value, it extracts the time part and discards the date. This provides yet another means of extracting times from DATETIME and TIMESTAMP values (in addition to those already discussed earlier in the chapter): mysql> SELECT dt, -> TIME_TO_SEC(dt) AS 'time part in seconds', -> SEC_TO_TIME(TIME_TO_SEC(dt)) AS 'time part as TIME' -> FROM datetime_val; +---------------------+----------------------+-------------------+ | dt | time part in seconds | time part as TIME | +---------------------+----------------------+-------------------+ | 1970-01-01 00:00:00 | 0 | 00:00:00 | | 1987-03-05 12:30:15 | 45015 | 12:30:15 | | 1999-12-31 09:00:00 | 32400 | 09:00:00 | | 2000-06-04 15:45:30 | 56730 | 15:45:30 | +---------------------+----------------------+-------------------+ mysql> SELECT ts, -> TIME_TO_SEC(ts) AS 'time part in seconds', -> SEC_TO_TIME(TIME_TO_SEC(ts)) AS 'time part as TIME' -> FROM timestamp_val; +----------------+----------------------+-------------------+ | ts | time part in seconds | time part as TIME | +----------------+----------------------+-------------------+ | 19700101000000 | 0 | 00:00:00 | | 19870305123015 | 45015 | 12:30:15 | | 19991231090000 | 32400 | 09:00:00 | | 20000604154530 | 56730 | 15:45:30 | +----------------+----------------------+-------------------+ 5.12 Converting Between Dates and Days 5.12.1 Problem You have a date but want a value in days, or vice versa. 5.12.2 Solution DATE values can be converted to and from days with TO_DAYS( ) and FROM_DAYS( ). Date- and-time values also can be converted to days if you're willing to suffer loss of the time part. 5.12.3 Discussion TO_DAYS( ) converts a date to the corresponding number of days, and FROM_DAYS( ) does the opposite: mysql> SELECT d, -> TO_DAYS(d) AS 'DATE to days', -> FROM_DAYS(TO_DAYS(d)) AS 'DATE to days to DATE' -> FROM date_val; +------------+--------------+----------------------+ | d | DATE to days | DATE to days to DATE | +------------+--------------+----------------------+ | 1864-02-28 | 680870 | 1864-02-28 | | 1900-01-15 | 693975 | 1900-01-15 | | 1987-03-05 | 725800 | 1987-03-05 | | 1999-12-31 | 730484 | 1999-12-31 | | 2000-06-04 | 730640 | 2000-06-04 | +------------+--------------+----------------------+ When using TO_DAYS( ), it's probably best to stick to the advice of the MySQL Reference Manual and avoid DATE values that occur before the beginning of the Gregorian calendar (1582). Changes in the lengths of calendar years and months prior to that date make it difficult to speak meaningfully of what the value of "day 0" might be. This differs from TIME_TO_SEC( ), where the correspondence between a TIME value and the resulting seconds value is obvious and has a meaningful reference point of 0 seconds. If you pass TO_DAYS( ) a date-and-time value, it extracts the date part and discards the time. This provides another means of extracting dates from DATETIME and TIMESTAMP values: mysql> SELECT dt, -> TO_DAYS(dt) AS 'date part in days', -> FROM_DAYS(TO_DAYS(dt)) AS 'date part as DATE' -> FROM datetime_val; +---------------------+-------------------+-------------------+ | dt | date part in days | date part as DATE | +---------------------+-------------------+-------------------+ | 1970-01-01 00:00:00 | 719528 | 1970-01-01 | | 1987-03-05 12:30:15 | 725800 | 1987-03-05 | | 1999-12-31 09:00:00 | 730484 | 1999-12-31 | | 2000-06-04 15:45:30 | 730640 | 2000-06-04 | +---------------------+-------------------+-------------------+ mysql> SELECT ts, -> TO_DAYS(ts) AS 'date part in days', -> FROM_DAYS(TO_DAYS(ts)) AS 'date part as DATE' -> FROM timestamp_val; +----------------+-------------------+-------------------+ | ts | date part in days | date part as DATE | +----------------+-------------------+-------------------+ | 19700101000000 | 719528 | 1970-01-01 | | 19870305123015 | 725800 | 1987-03-05 | | 19991231090000 | 730484 | 1999-12-31 | | 20000604154530 | 730640 | 2000-06-04 | +----------------+-------------------+-------------------+ 5.13 Converting Between Date-and-Time Values and Seconds 5.13.1 Problem You have a date-and-time value but want a value in seconds, or vice versa. 5.13.2 Solution The UNIX_TIMESTAMP( ) and FROM_UNIXTIME( ) functions convert DATETIME or TIMESTAMP values in the range from 1970 through approximately 2037 to and from the number of seconds elapsed since the beginning of 1970. The conversion to seconds offers higher precision for date-and-time values than a conversion to days, at the cost of a more limited range of values for which the conversion may be performed. 5.13.3 Discussion When working with date-and-time values, you can use TO_DAYS( ) and FROM_DAYS( ) to convert date values to days and back to dates, as shown in the previous section. For values that occur no earlier than 1970-01-01 00:00:00 GMT and no later than approximately 2037, it's possible to achieve higher precision by converting to and from seconds.[2] UNIX_TIMESTAMP( ) converts date-and-time values in this range to the number of seconds elapsed since the beginning of 1970, and FROM_UNIXTIME( ) does the opposite: [2] It's difficult to give a precise upper bound on the range of values because it varies somewhat between systems. mysql> SELECT dt, -> UNIX_TIMESTAMP(dt) AS seconds, -> FROM_UNIXTIME(UNIX_TIMESTAMP(dt)) AS timestamp -> FROM datetime_val; +---------------------+-----------+---------------------+ | dt | seconds | timestamp | +---------------------+-----------+---------------------+ | 1970-01-01 00:00:00 | 21600 | 1970-01-01 00:00:00 | | 1987-03-05 12:30:15 | 541967415 | 1987-03-05 12:30:15 | | 1999-12-31 09:00:00 | 946652400 | 1999-12-31 09:00:00 | | 2000-06-04 15:45:30 | 960151530 | 2000-06-04 15:45:30 | +---------------------+-----------+---------------------+ The relationship between the "UNIX" in the function names and the fact that the applicable range of values begins with 1970 is that 1970-01-01 00:00:00 GMT marks the "Unix epoch." The epoch is time zero, or the reference point for measuring time in Unix systems.[3] That being so, you may find it curious that the preceding example shows a UNIX_TIMESTAMP( ) value of 21600 for the first value in the datetime_val table. What's going on? Why isn't it 0? The apparent discrepancy is due to the fact that the MySQL server converts values to its own time zone when displaying them. My server is in the U.S. Central Time zone, which is six hours (that is, 21600 seconds) west of GMT. [3] 1970-01-01 00:00:00 GMT also happens to be the epoch as Java measures time. UNIX_TIMESTAMP( ) can convert DATE values to seconds, too. It treats such values as having an implicit time-of-day part of 00:00:00: mysql> SELECT CURDATE( ), FROM_UNIXTIME(UNIX_TIMESTAMP(CURDATE( ))); +------------+------------------------------------------+ | CURDATE( ) | FROM_UNIXTIME(UNIX_TIMESTAMP(CURDATE( )))| +------------+------------------------------------------+ | 2002-07-15 | 2002-07-15 00:00:00 | +------------+------------------------------------------+ 5.14 Adding a Temporal Interval to a Time 5.14.1 Problem You want to add a given number of seconds to a time, or to add two time values. 5.14.2 Solution Use TIME_TO_SEC( ) as necessary to make sure all values are represented in seconds, then add them. The result will be in seconds; use SEC_TO_TIME( ) if you want to convert back to a time value. 5.14.3 Discussion The primary tools for performing time arithmetic are TIME_TO_SEC( ) and SEC_TO_TIME( ), which convert between TIME values and seconds. To add an interval value in seconds to a TIME value, convert the TIME to seconds so that both values are represented in the same units, add the values together, and convert the result back to a TIME. For example, two hours is 7200 seconds (2*60*60), so the following query adds two hours to each t1 value in the time_val table: mysql> SELECT t1, -> SEC_TO_TIME(TIME_TO_SEC(t1) + 7200) AS 't1 plus 2 hours' -> FROM time_val; +----------+-----------------+ | t1 | t1 plus 2 hours | +----------+-----------------+ | 15:00:00 | 17:00:00 | | 05:01:30 | 07:01:30 | | 12:30:20 | 14:30:20 | +----------+-----------------+ If the interval itself is expressed as a TIME, it too should be converted to seconds before adding the values together. The following example calculates the sum of the two TIME values in the time_val table: mysql> SELECT t1, t2, -> SEC_TO_TIME(TIME_TO_SEC(t1) + TIME_TO_SEC(t2)) AS 't1 + t2' -> FROM time_val; +----------+----------+----------+ | t1 | t2 | t1 + t2 | +----------+----------+----------+ | 15:00:00 | 15:00:00 | 30:00:00 | | 05:01:30 | 02:30:20 | 07:31:50 | | 12:30:20 | 17:30:45 | 30:01:05 | +----------+----------+----------+ It's important to recognize that MySQL TIME values really represent elapsed time, not time of day, so they don't reset to 0 after reaching 24 hours. You can see this in the first and third output rows from the previous query. To produce time-of-day values, enforce a 24-hour wraparound using a modulo operation before converting the seconds value back to a TIME value. The number of seconds in a day is 24*60*60, or 86400, so to convert any seconds value s to lie within a 24-hour range, use the MOD( ) function or the % modulo operator like this: MOD(s,86400) s % 86400 The two expressions are equivalent. Applying the first of them to the time calculations from the preceding example produces the following result: mysql> SELECT t1, t2, -> SEC_TO_TIME(MOD(TIME_TO_SEC(t1) + TIME_TO_SEC(t2), 86400)) AS 't1 + t2' -> FROM time_val; +----------+----------+----------+ | t1 | t2 | t1 + t2 | +----------+----------+----------+ | 15:00:00 | 15:00:00 | 06:00:00 | | 05:01:30 | 02:30:20 | 07:31:50 | | 12:30:20 | 17:30:45 | 06:01:05 | +----------+----------+----------+ The allowable range of TIME values is -838:59:59 to 838:59:59 (that is -3020399 to 3020399 seconds). When you add times together, you can easily produce a result that lies outside this range. If you try to store such a value into a TIME column, MySQL clips it to the nearest endpoint of the range. 5.15 Calculating Intervals Between Times 5.15.1 Problem You want to know the amount of time elapsed between two times. 5.15.2 Solution Convert the times to seconds with TIME_TO_SEC( ) and take the difference. For a difference represented as a time, convert the result back the other way using SEC_TO_TIME( ). 5.15.3 Discussion Calculating intervals between times is similar to adding times together, except that you compute a difference rather than a sum. For example, to calculate intervals in seconds between pairs of t1 and t2 values, convert the values in the time_val table to seconds using TIME_TO_SEC( ), then take the difference. To express the resulting difference as a TIME value, pass it to SEC_TO_TIME( ). The following query shows intervals both ways: mysql> SELECT t1, t2, -> TIME_TO_SEC(t2) - TIME_TO_SEC(t1) AS 'interval in seconds', -> SEC_TO_TIME(TIME_TO_SEC(t2) - TIME_TO_SEC(t1)) AS 'interval as TIME' -> FROM time_val; +----------+----------+---------------------+------------------+ | t1 | t2 | interval in seconds | interval as TIME | +----------+----------+---------------------+------------------+ | 15:00:00 | 15:00:00 | 0 | 00:00:00 | | 05:01:30 | 02:30:20 | -9070 | -02:31:10 | | 12:30:20 | 17:30:45 | 18025 | 05:00:25 | +----------+----------+---------------------+------------------+ Note that intervals may be negative, as is the case when t1 occurs later than t2. 5.16 Breaking Down Time Intervals into Components 5.16.1 Problem You have a time interval represented as a time, but you want the interval in terms of its components. 5.16.2 Solution Decompose the interval with the HOUR( ), MINUTE( ), and SECOND( ) functions. If the calculation is complex in SQL and you're using the interval within a program, it may be easier to use your programming language to perform the equivalent math. 5.16.3 Discussion To express a time interval in terms of its constituent hours, minutes, and seconds values, calculate time interval subparts in SQL using the HOUR( ), MINUTE( ), and SECOND( ) functions. (Don't forget that if your intervals may be negative, you need to take that into account.) For example, to determine the components of the intervals between the t1 and t2 columns in the time_val table, the following SQL statement does the trick: mysql> SELECT t1, t2, -> SEC_TO_TIME(TIME_TO_SEC(t2) - TIME_TO_SEC(t1)) AS 'interval as TIME', -> IF(SEC_TO_TIME(TIME_TO_SEC(t2) >= TIME_TO_SEC(t1)),'+','-') AS sign, -> HOUR(SEC_TO_TIME(TIME_TO_SEC(t2) - TIME_TO_SEC(t1))) AS hour, -> MINUTE(SEC_TO_TIME(TIME_TO_SEC(t2) - TIME_TO_SEC(t1))) AS minute, -> SECOND(SEC_TO_TIME(TIME_TO_SEC(t2) - TIME_TO_SEC(t1))) AS second -> FROM time_val; +----------+----------+------------------+------+------+--------+--------+ | t1 | t2 | interval as TIME | sign | hour | minute | second | +----------+----------+------------------+------+------+--------+--------+ | 15:00:00 | 15:00:00 | 00:00:00 | + | 0 | 0 | 0 | | 05:01:30 | 02:30:20 | -02:31:10 | - | 2 | 31 | 10 | | 12:30:20 | 17:30:45 | 05:00:25 | + | 5 | 0 | 25 | +----------+----------+------------------+------+------+--------+--------+ But that's fairly messy, and attempting to do the same thing using division and modulo operations is even messier. If you happen to be issuing an interval-calculation query from within a program, it's possible to avoid most of the clutter. Use SQL to compute just the intervals in seconds, then use your API language to break down each interval into its components. The formulas should account for negative values and produce integer values for each component. Here's an example function time_components( ) written in Python that takes an interval value in seconds and returns a four-element tuple containing the sign of the value, followed by the hour, minute, and second parts: def time_components (time_in_secs): if time_in_secs < 0: sign = "-" time_in_secs = -time_in_secs else: sign = "" hours = int (time_in_secs / 3600) minutes = int ((time_in_secs / 60)) % 60 seconds = time_in_secs % 60 return (sign, hours, minutes, seconds) You might use time_components( ) within a program like this: query = "SELECT t1, t2, TIME_TO_SEC(t2) - TIME_TO_SEC(t1) FROM time_val" cursor = conn.cursor ( ) cursor.execute (query) for (t1, t2, interval) in cursor.fetchall ( ): (sign, hours, minutes, seconds) = time_components (interval) print "t1 = %s, t2 = %s, interval = %s%d h, %d m, %d s" \ % (t1, t2, sign, hours, minutes, seconds) cursor.close ( ) The program produces the following output: t1 = 15:00:00, t2 = 15:00:00, interval = 0 h, 0 m, 0 s t1 = 05:01:30, t2 = 02:30:20, interval = -2 h, 31 m, 10 s t1 = 12:30:20, t2 = 17:30:45, interval = 5 h, 0 m, 25 s The preceding example illustrates a more general principle that's often useful when issuing queries from a program: it may be easier to deal with a calculation that is complex to express in SQL by using a simpler query and postprocessing the results using your API language. 5.17 Adding a Temporal Interval to a Date 5.17.1 Problem You want to add time to a date or date-and-time value. 5.17.2 Solution Use DATE_ADD( ) and DATE_SUB( ), functions intended specifically for date arithmetic. You can also use TO_DAYS( ) and FROM_DAYS( ), or UNIX_TIMESTAMP( ) and FROM_UNIXTIME( ). 5.17.3 Discussion Date arithmetic is less straightforward than time arithmetic due to the varying length of months and years, so MySQL provides special functions DATE_ADD( ) and DATE_SUB( ) for adding or subtracting intervals to or from dates.[4] Each function takes a date value d and an interval, expressed using the following syntax: [4] DATE_ADD( ) and DATE_SUB( ) were introduced in MySQL 3.22.4, as were their synonyms, ADDDATE( ) and SUBDATE( ). DATE_ADD(d,INTERVAL val unit) DATE_SUB(d,INTERVAL val unit) Here, unit is the interval unit and val is an expression indicating the number of units. Some of the common unit specifiers are YEAR, MONTH, DAY, HOUR, MINUTE, and SECOND. (Check the MySQL Reference Manual for the full list.) Note that all these units are specified in singular form, not plural. Using DATE_ADD( ) or DATE_SUB( ), you can perform date arithmetic operations such as the following: · Determine the date three days from today: mysql> SELECT CURDATE( ), DATE_ADD(CURDATE( ),INTERVAL 3 DAY); +------------+------------------------------------+ | CURDATE() | DATE_ADD(CURDATE(),INTERVAL 3 DAY) | +------------+------------------------------------+ | 2002-07-15 | 2002-07-18 | +------------+------------------------------------+ · Find the date a week ago (the query here uses 7 DAY to represent an interval of a week because there is no WEEK interval unit): mysql> SELECT CURDATE( ), DATE_SUB(CURDATE( ),INTERVAL 7 DAY); +------------+------------------------------------+ | CURDATE() | DATE_SUB(CURDATE(),INTERVAL 7 DAY) | +------------+------------------------------------+ | 2002-07-15 | 2002-07-08 | +------------+------------------------------------+ · For questions where you need to know both the date and the time, begin with a DATETIME or TIMESTAMP value. To answer the question, "what time will it be in 60 hours?," do this: mysql> SELECT NOW( ), DATE_ADD(NOW( ),INTERVAL 60 HOUR); +---------------------+----------------------------------+ | NOW() | DATE_ADD(NOW(),INTERVAL 60 HOUR) | +---------------------+----------------------------------+ | 2002-07-15 11:31:17 | 2002-07-17 23:31:17 | +---------------------+----------------------------------+ · Some interval specifiers comprise both date and time parts. The following adds 14 and a half hours to the current date and time: mysql> SELECT NOW( ), DATE_ADD(NOW( ),INTERVAL '14:30' HOUR_MINUTE); +---------------------+----------------------------------------------+ | NOW() | DATE_ADD(NOW(),INTERVAL '14:30' HOUR_MINUTE) | +---------------------+----------------------------------------------+ | 2002-07-15 11:31:24 | 2002-07-16 02:01:24 | +---------------------+----------------------------------------------+ Similarly, adding 3 days and 4 hours produces this result: mysql> SELECT NOW( ), DATE_ADD(NOW( ),INTERVAL '3 4' DAY_HOUR); +---------------------+-----------------------------------------+ | NOW() | DATE_ADD(NOW( ,INTERVAL '3 4' DAY_HOUR) | +---------------------+-----------------------------------------+ | 2002-07-15 11:31:30 | 2002-07-18 15:31:30 | +---------------------+-----------------------------------------+ DATE_ADD( ) and DATE_SUB( ) are interchangeable because one is the same as the other with the sign of the interval value flipped. For example, these two calls are equivalent for any date value d: DATE_ADD(d,INTERVAL -3 MONTH) DATE_SUB(d,INTERVAL 3 MONTH) As of MySQL 3.23.4, you can also use the + and - operators to perform date interval addition and subtraction: mysql> SELECT CURDATE( ), CURDATE( ) + INTERVAL 1 YEAR; +------------+-----------------------------+ | CURDATE() | CURDATE() + INTERVAL 1 YEAR | +------------+-----------------------------+ | 2002-07-15 | 2003-07-15 | +------------+-----------------------------+ mysql> SELECT NOW( ), NOW( ) - INTERVAL 24 HOUR; +---------------------+--------------------------+ | NOW() | NOW() - INTERVAL 24 HOUR | +---------------------+--------------------------+ | 2002-07-15 11:31:48 | 2002-07-14 11:31:48 | +---------------------+--------------------------+ Another way to add intervals to date or date-and-time values is by using functions that convert to and from basic units. For example, to shift a date forward or backward a week (seven days), use TO_DAYS( ) and FROM_DAYS( ): mysql> SET @d = '2002-01-01'; mysql> SELECT @d AS date, -> FROM_DAYS(TO_DAYS(@d) + 7) AS 'date + 1 week', -> FROM_DAYS(TO_DAYS(@d) - 7) AS 'date - 1 week'; +------------+---------------+---------------+ | date | date + 1 week | date - 1 week | +------------+---------------+---------------+ | 2002-01-01 | 2002-01-08 | 2001-12-25 | +------------+---------------+---------------+ TO_DAYS( ) also can convert DATETIME or TIMESTAMP values to days, if you don't mind having it chop off the time part: mysql> SET @dt = '2002-01-01 12:30:45'; mysql> SELECT @dt AS datetime, -> FROM_DAYS(TO_DAYS(@dt) + 7) AS 'datetime + 1 week', -> FROM_DAYS(TO_DAYS(@dt) - 7) AS 'datetime - 1 week'; +---------------------+-------------------+-------------------+ | datetime | datetime + 1 week | datetime - 1 week | +---------------------+-------------------+-------------------+ | 2002-01-01 12:30:45 | 2002-01-08 | 2001-12-25 | +---------------------+-------------------+-------------------+ To preserve accuracy with DATETIME or TIMESTAMP values, use UNIX_TIMESTAMP( ) and FROM_UNIXTIME( ) instead. The following query shifts a DATETIME value forward and backward by an hour (3600 seconds): mysql> SET @dt = '2002-01-01 09:00:00'; mysql> SELECT @dt AS datetime, -> FROM_UNIXTIME(UNIX_TIMESTAMP(@dt) + 3600) AS 'datetime + 1 hour', -> FROM_UNIXTIME(UNIX_TIMESTAMP(@dt) - 3600) AS 'datetime - 1 hour'; +---------------------+---------------------+---------------------+ | datetime | datetime + 1 hour | datetime - 1 hour | +---------------------+---------------------+---------------------+ | 2002-01-01 09:00:00 | 2002-01-01 10:00:00 | 2002-01-01 08:00:00 | +---------------------+---------------------+---------------------+ The last technique requires that both your initial value and the resulting value like in the allowable range for TIMESTAMP values (1970 to sometime in the year 2037). 5.18 Calculating Intervals Between Dates 5.18.1 Problem You want to know how long it is between dates. 5.18.2 Solution Convert both dates to basic units and take the difference between the resulting values. 5.18.3 Discussion The general procedure for calculating an interval between dates is to convert both dates to a common unit in relation to a given reference point, then take the difference. The range of values you're working with determines which conversions are available. DATE, DATETIME, or TIMESTAMP values dating back to 1970-01-01 00:00:00 GMT—the date of the Unix epoch— can be converted to seconds elapsed since the epoch. If both dates lie within that range, you can calculate intervals to an accuracy of one second. Older dates from the beginning of the Gregorian calendar (1582) on can be converted to day values and used to compute intervals in days. Dates that begin earlier than either of these reference points present more of a problem. In such cases, you may find that your programming language offers computations that are not available or are difficult to perform in SQL. If so, consider processing date values directly from within your API language. (For example, the Date::Calc and Date::Manip modules are available from the CPAN for use within Perl scripts.) To calculate an interval in days between date or date-and-time values, convert them to days using TO_DAYS( ), then take the difference: mysql> SELECT TO_DAYS('1884-01-01') - TO_DAYS('1883-06-05') AS days; +------+ | days | +------+ | 210 | +------+ For an interval in weeks, do the same thing and divide the result by seven: mysql> SELECT (TO_DAYS('1884-01-01') - TO_DAYS('1883-06-05')) / 7 AS weeks; +-------+ | weeks | +-------+ | 30.00 | +-------+ You cannot convert days to months or years by simple division, because those units vary in length. Calculations to yield date intervals expressed in those units are covered in Recipe 5.20. Do You Want an Interval or a Span? Taking a difference between dates gives you the interval from one date to the next. If you want to know the range covered by the two dates, you must add a unit. For example, it's three days from 2002-01-01 to 2002-01-04, but together they span a range of four days. If you're not getting the results you expect from an interval calculation, consider whether you need to use an "off-by-one" correction. For values occurring from the beginning of 1970 on, you can determine intervals to a resolution in seconds using the UNIX_TIMESTAMP( ) function. For example, the number of seconds between dates that lie two weeks apart can be computed like this: mysql> SET @dt1 = '1984-01-01 09:00:00'; mysql> SET @dt2 = '1984-01-15 09:00:00'; mysql> SELECT UNIX_TIMESTAMP(@dt2) - UNIX_TIMESTAMP(@dt1) AS seconds; +---------+ | seconds | +---------+ | 1209600 | +---------+ To convert the interval in seconds to other units, perform the appropriate arithmetic operation. Seconds are easily converted to minutes, hours, days, or weeks: mysql> SET @interval = UNIX_TIMESTAMP(@dt2) - UNIX_TIMESTAMP(@dt1); mysql> SELECT @interval AS seconds, -> @interval / 60 AS minutes, -> @interval / (60 * 60) AS hours, -> @interval / (24 * 60 * 60) AS days, -> @interval / (7 * 24 * 60 * 60) AS weeks; +---------+---------+-------+------+-------+ | seconds | minutes | hours | days | weeks | +---------+---------+-------+------+-------+ | 1209600 | 20160 | 336 | 14 | 2 | +---------+---------+-------+------+-------+ For values that occur prior outside the range from 1970 to 2037, you can use an interval calculation method that is more general (but messier): · Take the difference in days between the date parts of the values and multiply by 24*60*60 to convert to seconds. · Offset the result by the difference in seconds between the time parts of the values. Here's an example, using two date-and-time values that lie a week apart: mysql> SET @dt1 = '1800-02-14 07:30:00'; mysql> SET @dt2 = '1800-02-21 07:30:00'; mysql> SET @interval = -> ((TO_DAYS(@dt2) - TO_DAYS(@dt1)) * 24*60*60) -> + TIME_TO_SEC(@dt2) - TIME_TO_SEC(@dt1); mysql> SELECT @interval AS seconds; +---------+ | seconds | +---------+ | 604800 | +---------+ To convert the interval to a TIME value, pass it to SEC_TO_TIME( ): mysql> SELECT SEC_TO_TIME(@interval) AS TIME; +-----------+ | TIME | +-----------+ | 168:00:00 | +-----------+ To convert the interval from seconds to other units, perform the appropriate division: mysql> SELECT @interval AS seconds, -> @interval / 60 AS minutes, -> @interval / (60 * 60) AS hours, -> @interval / (24 * 60 * 60) AS days, -> @interval / (7 * 24 * 60 * 60) AS weeks; +---------+---------+-------+------+-------+ | seconds | minutes | hours | days | weeks | +---------+---------+-------+------+-------+ | 604800 | 10080 | 168 | 7 | 1 | +---------+---------+-------+------+-------+ I cheated here by choosing an interval that produces nice integer values for all the division operations. In general, you'll have a fractional part, in which case you may find it helpful to use FLOOR(expr) to chop off the fractional part and produce an integer. 5.19 Canonizing Not-Quite-ISO Date Strings 5.19.1 Problem A date is in a format that's close to but not exactly ISO format. 5.19.2 Solution Canonize the date by passing it to a function that always returns an ISO-format date result. 5.19.3 Discussion Earlier in the chapter (Recipe 5.9), we ran into the problem that synthesizing dates with CONCAT( ) may produce values that are not quite in ISO format. For example, the following query produces first-of-month values in which the month part may have only a single digit: mysql> SELECT d, CONCAT(YEAR(d),'-',MONTH(d),'-01') FROM date_val; +------------+------------------------------------+ | d | CONCAT(YEAR(d),'-',MONTH(d),'-01') | +------------+------------------------------------+ | 1864-02-28 | 1864-2-01 | | 1900-01-15 | 1900-1-01 | | 1987-03-05 | 1987-3-01 | | 1999-12-31 | 1999-12-01 | | 2000-06-04 | 2000-6-01 | +------------+------------------------------------+ In that section, a technique using LPAD( ) was shown for making sure the month values have two digits. mysql> SELECT d, CONCAT(YEAR(d),'-',LPAD(MONTH(d),2,'0'),'-01') FROM date_val; +------------+------------------------------------------------+ | d | CONCAT(YEAR(d),'-',LPAD(MONTH(d),2,'0'),'-01') | +------------+------------------------------------------------+ | 1864-02-28 | 1864-02-01 | | 1900-01-15 | 1900-01-01 | | 1987-03-05 | 1987-03-01 | | 1999-12-31 | 1999-12-01 | | 2000-06-04 | 2000-06-01 | +------------+------------------------------------------------+ Another way to standardize a close-to-ISO date is to use it in an expression that produces an ISO date result. For a date d, any of the following expressions will do: DATE_ADD(d,INTERVAL 0 DAY) d + INTERVAL 0 DAY FROM_DAYS(TO_DAYS(d)) For example, the non-ISO results from the CONCAT( ) operation can be converted into ISO format three different ways as follows: mysql> SELECT d, -> CONCAT(YEAR(d),'-',MONTH(d),'-01') AS 'non-ISO', -> DATE_ADD(CONCAT(YEAR(d),'-',MONTH(d),'-01'),INTERVAL 0 DAY) AS method1, -> CONCAT(YEAR(d),'-',MONTH(d),'-01') + INTERVAL 0 DAY AS method2, -> FROM_DAYS(TO_DAYS(CONCAT(YEAR(d),'-',MONTH(d),'-01'))) AS method3 -> FROM date_val; +------------+------------+------------+------------+------------+ | d | non-ISO | method1 | method2 | method3 | +------------+------------+------------+------------+------------+ | 1864-02-28 | 1864-2-01 | 1864-02-01 | 1864-02-01 | 1864-02-01 | | 1900-01-15 | 1900-1-01 | 1900-01-01 | 1900-01-01 | 1900-01-01 | | 1987-03-05 | 1987-3-01 | 1987-03-01 | 1987-03-01 | 1987-03-01 | | 1999-12-31 | 1999-12-01 | 1999-12-01 | 1999-12-01 | 1999-12-01 | | 2000-06-04 | 2000-6-01 | 2000-06-01 | 2000-06-01 | 2000-06-01 | +------------+------------+------------+------------+------------+ 5.20 Calculating Ages 5.20.1 Problem You want to know how old someone is. 5.20.2 Solution This is a problem of computing the interval between dates, but with a twist. For an age in years, it's necessary to account for the relative placement of the start and end dates within the calendar year. For an age in months, it's also necessary to account for the placement of the months and the days within the month. 5.20.3 Discussion Age determination is a type of date interval calculation, but one that cannot be done by computing a difference in days and dividing by 365. That doesn't work because leap years throw off the calculation. (The interval from 1995-03-01 to 1996-02-29 spans 365 days, but is not a year in age terms.) Using 365.25 is slightly more accurate, but still not correct for all dates. Instead, it's necessary to determine the difference between dates in years and then adjust for the relative location of the dates within the calendar year. (Suppose Gretchen Smith was born on April 14, 1942. To compute how old Gretchen is now, we must account for where the current date falls within the calendar year: she's one age up through April 13 of the year, and one year older from April 14 through the end of the year.) This section shows how to perform this kind of calculation to determine ages in units of years or months. 5.20.4 Determining Ages in Years In general, given a birth date birth, an age in years on a target date d can be computed by the following logic: if (d occurs earlier in the year than birth) age = YEAR(d) - YEAR(birth) - 1 if (d occurs on or later in the year than birth) age = YEAR(d) - YEAR(birth) For both cases, the difference-in-years part of the calculation is the same. What distinguishes them is the relative ordering of the dates within the calendar year. However, this ordering cannot be determined with DAYOFYEAR( ), because that only works if both dates fall during years with the same number of days. For dates in different years, different calendar days may have the same DAYOFYEAR( ) value, as the following query illustrates: mysql> SELECT DAYOFYEAR('1995-03-01'), DAYOFYEAR('1996-02-29'); +-------------------------+-------------------------+ | DAYOFYEAR('1995-03-01') | DAYOFYEAR('1996-02-29') | +-------------------------+-------------------------+ | 60 | 60 | +-------------------------+-------------------------+ The fact that ISO date strings compare naturally in the proper order comes to our rescue here—or more precisely, the fact that the rightmost five characters that represent the month and day also compare properly: mysql> SELECT RIGHT('1995-03-01',5), RIGHT('1996-02-29',5); +-----------------------+-----------------------+ | RIGHT('1995-03-01',5) | RIGHT('1996-02-29',5) | +-----------------------+-----------------------+ | 03-01 | 02-29 | +-----------------------+-----------------------+ mysql> SELECT IF('02-29' < '03-01','02-29','03-01') AS earliest; +----------+ | earliest | +----------+ | 02-29 | +----------+ This means that we can perform the "earlier-in-year" test for two dates, d1 and d2, like this: RIGHT(d2,5) < RIGHT(d1,5) The expression evaluates to 1 or 0, depending on the result of the test, so the result of the < comparison can be used to perform an age-in-years calculation: YEAR(d2) - YEAR(d1) - (RIGHT(d2,5) < RIGHT(d1,5)) To make it more obvious what the comparison result evaluates to, wrap it in an IF( ) function that explicitly returns 1 or 0: YEAR(d2) - YEAR(d1) - IF(RIGHT(d2,5) < RIGHT(d1,5),1,0) The following query demonstrates how this formula works to calculate an age as of the beginning 1975 for someone born on 1965-03-01. It shows the unadjusted age difference in years, the adjustment value, and the final age: mysql> SET @birth = '1965-03-01'; mysql> SET @target = '1975-01-01'; mysql> SELECT @birth, @target, -> YEAR(@target) - YEAR(@birth) AS 'difference', -> IF(RIGHT(@target,5) < RIGHT(@birth,5),1,0) AS 'adjustment', -> YEAR(@target) - YEAR(@birth) -> - IF(RIGHT(@target,5) < RIGHT(@birth,5),1,0) -> AS 'age'; +------------+------------+------------+------------+------+ | @birth | @target | difference | adjustment | age | +------------+------------+------------+------------+------+ | 1965-03-01 | 1975-01-01 | 10 | 1 | 9 | +------------+------------+------------+------------+------+ Let's try the age-in-years formula with a sibling table that lists the birth dates of Gretchen Smith and her brothers Wilbur and Franz: +----------+------------+ | name | birth | +----------+------------+ | Gretchen | 1942-04-14 | | Wilbur | 1946-11-28 | | Franz | 1953-03-05 | +----------+------------+ The formula produces answers for questions such as the following: · How old are the Smith children today? · mysql> SELECT name, birth, CURDATE( ) AS today, · -> YEAR(CURDATE( )) - YEAR(birth) · -> - IF(RIGHT(CURDATE( ),5) < RIGHT(birth,5),1,0) · -> AS 'age in years' · -> FROM sibling; · +----------+------------+------------+--------------+ · | name | birth | today | age in years | · +----------+------------+------------+--------------+ · | Gretchen | 1942-04-14 | 2002-07-15 | 60 | · | Wilbur | 1946-11-28 | 2002-07-15 | 55 | · | Franz | 1953-03-05 | 2002-07-15 | 49 | +----------+------------+------------+--------------+ · How old were Gretchen and Wilbur when Franz was born? · mysql> SELECT name, birth, '1953-03-05' AS 'Franz'' birthday', · -> YEAR('1953-03-05') - YEAR(birth) · -> - IF(RIGHT('1953-03-05',5) < RIGHT(birth,5),1,0) · -> AS 'age in years' · -> FROM sibling WHERE name != 'Franz'; · +----------+------------+-----------------+--------------+ · | name | birth | Franz' birthday | age in years | · +----------+------------+-----------------+--------------+ · | Gretchen | 1942-04-14 | 1953-03-05 | 10 | · | Wilbur | 1946-11-28 | 1953-03-05 | 6 | +----------+------------+-----------------+--------------+ When performing calculations of this nature, be sure to remember that, for comparisons on the MM-DD part of date strings to yield correct results, you must use ISO values like 1987- 07-01 and not close-to-ISO values like 1987-7-1. For example, the following comparison produces a result that is correct in lexical terms but incorrect in temporal terms: mysql> SELECT RIGHT('1987-7-1',5) < RIGHT('1987-10-01',5); +---------------------------------------------+ | RIGHT('1987-7-1',5) < RIGHT('1987-10-01',5) | +---------------------------------------------+ | 0 | +---------------------------------------------+ The absence of leading zeros in the month and day parts of the first date makes the substring- based comparison fail. 5.20.5 Determining Ages in Months The formula for calculating ages in months is similar to that for ages in years, except that we multiply the years difference by 12, add the months difference, and adjust for the relative day-in-month values of the two dates. In this case, we need to use the month and day part of each date separately, so we may as well extract them directly using MONTH( ) and DAYOFMONTH( ) rather than performing a comparison on the MM-DD part of the date strings. The current ages of the Smith children in months thus can be calculated like this: mysql> SELECT name, birth, CURDATE( ) AS today, -> (YEAR(CURDATE( )) - YEAR(birth)) * 12 -> + (MONTH(CURDATE( )) - MONTH(birth)) -> - IF(DAYOFMONTH(CURDATE( )) < DAYOFMONTH(birth),1,0) -> AS 'age in months' -> FROM sibling; +----------+------------+------------+---------------+ | name | birth | today | age in months | +----------+------------+------------+---------------+ | Gretchen | 1942-04-14 | 2002-07-15 | 723 | | Wilbur | 1946-11-28 | 2002-07-15 | 667 | | Franz | 1953-03-05 | 2002-07-15 | 592 | +----------+------------+------------+---------------+ 5.21 Shifting Dates by a Known Amount 5.21.1 Problem You want to shift a given date by a given amount to compute the resulting date. 5.21.2 Solution Use DATE_ADD( ) or DATE_SUB( ). 5.21.3 Discussion If you have a reference date and want to calculate another date from it that differs by a known interval, the problem generally can be solved by basic date arithmetic using DATE_ADD( ) and DATE_SUB( ). Some examples of this kind of question include finding anniversary dates, determining expiration dates, or finding records that satisfy "this date in history" queries. This section illustrates a couple of applications for date shifting. 5.21.4 Calculating Anniversary Dates Suppose you're getting married on August 6, 2003, and you don't want to wait a year for your first anniversary to show your devotion to your sweetheart. Instead, you want to get her special gifts on your 1 week, 1 month, 3 month, and 6 month anniversaries. To calculate those dates, shift your anniversary date forward by the desired intervals, as follows: mysql> SET @d = '2003-08-06'; mysql> SELECT @d AS 'start date', -> DATE_ADD(@d,INTERVAL 7 DAY) AS '1 week', -> DATE_ADD(@d,INTERVAL 1 MONTH) AS '1 month', -> DATE_ADD(@d,INTERVAL 3 MONTH) AS '3 months', -> DATE_ADD(@d,INTERVAL 6 MONTH) AS '6 months'; +------------+------------+------------+------------+------------+ | start date | 1 week | 1 month | 3 months | 6 months | +------------+------------+------------+------------+------------+ | 2003-08-06 | 2003-08-13 | 2003-09-06 | 2003-11-06 | 2004-02-06 | +------------+------------+------------+------------+------------+ If you're interested only in part of an anniversary date, you may be able to dispense with date arithmetic altogether. For example, if you graduated from school on June 4, 2000, and you want to know the years on which your 10th, 20th, and 40th class reunions will be, it's unnecessary to use DATE_ADD( ). Just extract the year part of the reference date and use normal arithmetic to add 10, 20, and 40 to it: mysql> SET @y = YEAR('2000-06-04'); mysql> SELECT @y + 10, @y + 20, @y + 40; +---------+---------+---------+ | @y + 10 | @y + 20 | @y + 40 | +---------+---------+---------+ | 2010 | 2020 | 2040 | +---------+---------+---------+ 5.21.5 Time Zone Adjustments A MySQL server returns dates using the time zone of the host on which the server runs. If you're running a client program in a different time zone, you can adjust values to client local time with DATE_ADD( ). To convert times for a server that is two hours ahead of the client, subtract two hours: mysql> SELECT dt AS 'server time', -> DATE_ADD(dt,INTERVAL -2 HOUR) AS 'client time' -> FROM datetime_val; +---------------------+---------------------+ | server time | client time | +---------------------+---------------------+ | 1970-01-01 00:00:00 | 1969-12-31 22:00:00 | | 1987-03-05 12:30:15 | 1987-03-05 10:30:15 | | 1999-12-31 09:00:00 | 1999-12-31 07:00:00 | | 2000-06-04 15:45:30 | 2000-06-04 13:45:30 | +---------------------+---------------------+ Note that the server has no idea what time zone the client is in, so you are responsible for determining the amount of shift between the client and the server time zones. Within a script, you may be able to do this by getting the current local time and comparing it to the server's idea of its local time. In Perl, the localtime( ) function comes in handy for this: my ($sec, $min, $hour, $day, $mon, $year) = localtime (time ( )); my $now = sprintf ("%04d-%02d-%02d %02d:%02d:%02d", $year + 1900, $mon + 1, $day, $hour, $min, $sec); my ($server_now, $adjustment) = $dbh->selectrow_array ( "SELECT NOW( ), UNIX_TIMESTAMP(?) - UNIX_TIMESTAMP(NOW( ))", undef, $now); print "client now: $now\n"; print "server now: $server_now\n"; print "adjustment (secs): $adjustment\n"; 5.22 Finding First and Last Days of Months 5.22.1 Problem Given a date, you want to determine the date for the first or last day of the month in which the date occurs, or the first or last day for the month n months away. 5.22.2 Solution You can do this by date shifting. 5.22.3 Discussion Sometimes you have a reference date and want to reach a target date that doesn't have a fixed relationship to the reference date. For example, to find the last day of the month, the amount that you shift the current date depends on what day of the month it is now and the length of the current month. To find the first day of the month for a given date, shift the date back by one fewer days than its DAYOFMONTH( ) value: mysql> SELECT d, DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY) AS '1st of month' -> FROM date_val; +------------+--------------+ | d | 1st of month | +------------+--------------+ | 1864-02-28 | 1864-02-01 | | 1900-01-15 | 1900-01-01 | | 1987-03-05 | 1987-03-01 | | 1999-12-31 | 1999-12-01 | | 2000-06-04 | 2000-06-01 | +------------+--------------+ In the general case, to find the first of the month for any month n months away from a given date, calculate the first of the month for the date, then shift the result by n months: DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL n MONTH) For example, to find the first day of the previous and following months relative to a given date, n would be -1 and 1: mysql> SELECT d, -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL -1 MONTH) -> AS '1st of previous month', -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL 1 MONTH) -> AS '1st of following month' -> FROM date_val; +------------+-----------------------+------------------------+ | d | 1st of previous month | 1st of following month | +------------+-----------------------+------------------------+ | 1864-02-28 | 1864-01-01 | 1864-03-01 | | 1900-01-15 | 1899-12-01 | 1900-02-01 | | 1987-03-05 | 1987-02-01 | 1987-04-01 | | 1999-12-31 | 1999-11-01 | 2000-01-01 | | 2000-06-04 | 2000-05-01 | 2000-07-01 | +------------+-----------------------+------------------------+ Finding the last day of the month for a given reference date is more difficult, because months vary in length. However, the last day of the month is always the day before the first of the next month, and we know how to calculate the latter. Thus, for the general case, the last day of the month n months from a date can be determined using the following procedure: 1. Find the first day of the month 2. Shift the result by n+1 months 3. Shift back a day The SQL expression to perform these operations look like this: DATE_SUB( DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL n+1 MONTH), INTERVAL 1 DAY) For example, to calculate the last day of the month for the previous, current, and following months relative to a given date, n would be -1, 0, and 1, and the expressions look like this: mysql> SELECT d, -> DATE_SUB( -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL 0 MONTH), -> INTERVAL 1 DAY) -> AS 'last, prev. month', -> DATE_SUB( -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL 1 MONTH), -> INTERVAL 1 DAY) -> AS 'last, this month', -> DATE_SUB( -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL 2 MONTH), -> INTERVAL 1 DAY) -> AS 'last, following month' -> FROM date_val; +------------+-------------------+------------------+-----------------------+ | d | last, prev. month | last, this month | last, following month | +------------+-------------------+------------------+-----------------------+ | 1864-02-28 | 1864-01-31 | 1864-02-29 | 1864-03-31 | | 1900-01-15 | 1899-12-31 | 1900-01-31 | 1900-02-28 | | 1987-03-05 | 1987-02-28 | 1987-03-31 | 1987-04-30 | | 1999-12-31 | 1999-11-30 | 1999-12-31 | 2000-01-31 | | 2000-06-04 | 2000-05-31 | 2000-06-30 | 2000-07-31 | +------------+-------------------+------------------+-----------------------+ The last day of the previous month is a special case for which the general expression can be simplified quite a bit: mysql> SELECT d, -> DATE_SUB(d,INTERVAL DAYOFMONTH(d) DAY) -> AS 'last of previous month' -> FROM date_val; +------------+------------------------+ | d | last of previous month | +------------+------------------------+ | 1864-02-28 | 1864-01-31 | | 1900-01-15 | 1899-12-31 | | 1987-03-05 | 1987-02-28 | | 1999-12-31 | 1999-11-30 | | 2000-06-04 | 2000-05-31 | +------------+------------------------+ The key feature of the general last-of-month expression is that it begins by finding the first-of- month value for the starting date. That gives you a useful point of reference, because you can always shift it forward or backward by month units to obtain another first-of-month value, which can in turn be shifted back a day to find a last-of-month value. If you determine last-of- month values by finding the last-of-month value for the starting date and then shifting that, you won't always get the correct result, because not all months have the same number of days. For example, an incorrect method for determining the last day of a given month is to find the last day of the previous month and add a month: mysql> SELECT d, -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d) DAY),INTERVAL 1 MONTH) -> AS 'last of month' -> FROM date_val; +------------+---------------+ | d | last of month | +------------+---------------+ | 1864-02-28 | 1864-02-29 | | 1900-01-15 | 1900-01-31 | | 1987-03-05 | 1987-03-28 | | 1999-12-31 | 1999-12-30 | | 2000-06-04 | 2000-06-30 | +------------+---------------+ This fails because the day-of-month part of the resulting date may not be correct. In the rows for 1987-03-05 and 1999-12-31, the last day of the month has been calculated incorrectly. This will be true with the preceding formula for any month in which the month preceding the reference date has fewer days than the target month. 5.23 Finding the Length of a Month 5.23.1 Problem You want to know how many days there are in a month. 5.23.2 Solution Determine the date of its last day, then extract the day-of-month component from the result. 5.23.3 Discussion To determine the number of days for the month in which a given date occurs, calculate the date for the last day of the month as shown in the previous section, then extract the DAYOFMONTH( ) value from the result: mysql> SELECT d, -> DAYOFMONTH(DATE_SUB( -> DATE_ADD(DATE_SUB(d,INTERVAL DAYOFMONTH(d)-1 DAY),INTERVAL 1 MONTH), -> INTERVAL 1 DAY)) -> AS 'days in month' -> FROM date_val; +------------+---------------+ | d | days in month | +------------+---------------+ | 1864-02-28 | 29 | | 1900-01-15 | 31 | | 1987-03-05 | 31 | | 1999-12-31 | 31 | | 2000-06-04 | 30 | +------------+---------------+ 5.23.4 See Also Recipe 5.28 later in this chapter discusses another way to calculate month lengths. Chapter 10 discusses leap year calculations in the context of date validation. 5.24 Calculating One Date from Another by Substring Replacement 5.24.1 Problem Given a date, you want to produce another date from it, and you know the two dates share some components in common. 5.24.2 Solution Treat a date or time value as a string and perform direct replacement on parts of the string. 5.24.3 Discussion In some cases, you can use substring replacement to calculate dates without performing any date arithmetic. For example, you can use string operations to produce the first-of-month value for a given date by replacing the day component with 01. You can do this either with DATE_FORMAT( ) or with CONCAT( ): mysql> SELECT d, -> DATE_FORMAT(d,'%Y-%m-01') AS method1, -> CONCAT(YEAR(d),'-',LPAD(MONTH(d),2,'0'),'-01') AS method2 -> FROM date_val; +------------+------------+------------+ | d | method1 | method2 | +------------+------------+------------+ | 1864-02-28 | 1864-02-01 | 1864-02-01 | | 1900-01-15 | 1900-01-01 | 1900-01-01 | | 1987-03-05 | 1987-03-01 | 1987-03-01 | | 1999-12-31 | 1999-12-01 | 1999-12-01 | | 2000-06-04 | 2000-06-01 | 2000-06-01 | +------------+------------+------------+ The string replacement technique can also be used to produce dates with a specific position within the calendar year. For New Year's Day (January 1), replace the month and day with 01: mysql> SELECT d, -> DATE_FORMAT(d,'%Y-01-01') AS method1, -> CONCAT(YEAR(d),'-01-01') AS method2 -> FROM date_val; +------------+------------+------------+ | d | method1 | method2 | +------------+------------+------------+ | 1864-02-28 | 1864-01-01 | 1864-01-01 | | 1900-01-15 | 1900-01-01 | 1900-01-01 | | 1987-03-05 | 1987-01-01 | 1987-01-01 | | 1999-12-31 | 1999-01-01 | 1999-01-01 | | 2000-06-04 | 2000-01-01 | 2000-01-01 | +------------+------------+------------+ For Christmas, replace the month and day with 12 and 25: mysql> SELECT d, -> DATE_FORMAT(d,'%Y-12-25') AS method1, -> CONCAT(YEAR(d),'-12-25') AS method2 -> FROM date_val; +------------+------------+------------+ | d | method1 | method2 | +------------+------------+------------+ | 1864-02-28 | 1864-12-25 | 1864-12-25 | | 1900-01-15 | 1900-12-25 | 1900-12-25 | | 1987-03-05 | 1987-12-25 | 1987-12-25 | | 1999-12-31 | 1999-12-25 | 1999-12-25 | | 2000-06-04 | 2000-12-25 | 2000-12-25 | +------------+------------+------------+ To perform the same operation for Christmas in other years, combine string replacement with date shifting. The following query shows two ways to determine the date for Christmas two years hence. The first method finds Christmas for this year, then shifts it two years forward. The second shifts the current date forward two years, then finds Christmas in the resulting year: mysql> SELECT CURDATE( ), -> DATE_ADD(DATE_FORMAT(CURDATE( ),'%Y-12-25'),INTERVAL 2 YEAR) -> AS method1, -> DATE_FORMAT(DATE_ADD(CURDATE( ),INTERVAL 2 YEAR),'%Y-12-25') -> AS method2; +------------+------------+------------+ | CURDATE( ) | method1 | method2 | +------------+------------+------------+ | 2002-07-15 | 2004-12-25 | 2004-12-25 | +------------+------------+------------+ 5.25 Finding the Day of the Week for a Date 5.25.1 Problem You want to know the day of the week a date falls on. 5.25.2 Solution Use the DAYNAME( ) function. 5.25.3 Discussion To determine the name of the day of the week for a given date, use DAYNAME( ): mysql> SELECT CURDATE( ), DAYNAME(CURDATE( )); +------------+--------------------+ | CURDATE() | DAYNAME(CURDATE()) | +------------+--------------------+ | 2002-07-15 | Monday | +------------+--------------------+ DAYNAME( ) is often useful in conjunction with other date-related techniques. For example, to find out the day of the week for the first of the month, use the first-of-month expression from earlier in the chapter as the argument to DAYNAME( ): mysql> SET @d = CURDATE( ); mysql> SET @first = DATE_SUB(@d,INTERVAL DAYOFMONTH(@d)-1 DAY); mysql> SELECT @d AS 'starting date', -> @first AS '1st of month date', -> DAYNAME(@first) AS '1st of month day'; +---------------+-------------------+------------------+ | starting date | 1st of month date | 1st of month day | +---------------+-------------------+------------------+ | 2002-07-15 | 2002-07-01 | Monday | +---------------+-------------------+------------------+ 5.26 Finding Dates for Days of the Current Week 5.26.1 Problem You want to compute the date for some other day of the current week. 5.26.2 Solution Figure out the number of days between the starting day and the desired day, and shift the date by that many days. 5.26.3 Discussion This section and the next describe how to convert one date to another when the target date is specified in terms of days of the week. To solve such problems, you need to know day-of- week values. For example, if you want to know what date it is on Tuesday of this week, the calculation depends on what day of the week it is today. If today is Monday, you add a day to CURDATE( ), but if today is Wednesday, you subtract a day. MySQL provides two functions that are useful here. DAYOFWEEK( ) treats Sunday as the first day of the week and returns 1 through 7 for Sunday through Saturday. WEEKDAY( ) treats Monday as the first day of the week and returns 0 through 6 for Monday through Sunday. (The examples shown here use DAYOFWEEK( ).) Another kind of day-of-week operation involves determining the name of the day. DAYNAME( ) can be used for that. Calculations that determine one day of the week from another depend on the day you start from as well as the day you want to reach. I find it easiest to shift the reference date first to a known point relative to the beginning of the week, then shift forward: · Shift the reference date back by its DAYOFWEEK( ) value, which always produces the date for the Saturday preceding the week. · Add one day to the result to reach the Sunday date, two days to reach the Monday date, and so forth. In SQL, these operations can be expressed as follows for a date d, where n is 1 through 7 to produce the dates for Sunday through Saturday: DATE_ADD(DATE_SUB(d,INTERVAL DAYOFWEEK(d) DAY),INTERVAL n DAY) That expression splits the "shift back to Saturday" and "shift forward" phases into separate operations, but because the intervals for both DATE_SUB( ) and DATE_ADD( ) are both in days, the expression can be simplified into a single DATE_ADD( ) call: DATE_ADD(d,INTERVAL n-DAYOFWEEK(d) DAY) If we apply this formula to our date_val table, using an n of 1 for Sunday and 7 for Saturday to find the first and last days of the week, we get this result: mysql> SELECT d, DAYNAME(d) AS day, -> DATE_ADD(d,INTERVAL 1-DAYOFWEEK(d) DAY) AS Sunday, -> DATE_ADD(d,INTERVAL 7-DAYOFWEEK(d) DAY) AS Saturday -> FROM date_val; +------------+----------+------------+------------+ | d | day | Sunday | Saturday | +------------+----------+------------+------------+ | 1864-02-28 | Sunday | 1864-02-28 | 1864-03-05 | | 1900-01-15 | Monday | 1900-01-14 | 1900-01-20 | | 1987-03-05 | Thursday | 1987-03-01 | 1987-03-07 | | 1999-12-31 | Friday | 1999-12-26 | 2000-01-01 | | 2000-06-04 | Sunday | 2000-06-04 | 2000-06-10 | +------------+----------+------------+------------+ 5.27 Finding Dates for Weekdays of Other Weeks 5.27.1 Problem You want to compute the date for some weekday of some other week. 5.27.2 Solution Figure out the date for that weekday in the current week, then shift the result into the desired week. 5.27.3 Discussion Calculating the date for a day of the week in some other week is a problem that breaks down into a day-within-week shift (using the formula given in the previous section) plus a week shift. These operations can be done in either order because the amount of shift within the week is the same whether or not you shift the reference date into a different week first. For example, to calculate Wednesday of a week by the preceding formula, n is 4. To compute the date for Wednesday two weeks ago, you can perform the day-within-week shift first, like this: mysql> SET @target = -> DATE_SUB(DATE_ADD(CURDATE( ),INTERVAL 4-DAYOFWEEK(CURDATE( )) DAY), -> INTERVAL 14 DAY); mysql> SELECT CURDATE( ), @target, DAYNAME(@target); +------------+------------+------------------+ | CURDATE() | @target | DAYNAME(@target) | +------------+------------+------------------+ | 2002-07-15 | 2002-07-03 | Wednesday | +------------+------------+------------------+ Or you can perform the week shift first: mysql> SET @target = -> DATE_ADD(DATE_SUB(CURDATE( ),INTERVAL 14 DAY), -> INTERVAL 4-DAYOFWEEK(CURDATE( )) DAY); mysql> SELECT CURDATE( ), @target, DAYNAME(@target); +------------+------------+------------------+ | CURDATE() | @target | DAYNAME(@target) | +------------+------------+------------------+ | 2002-07-15 | 2002-07-03 | Wednesday | +------------+------------+------------------+ Some applications need to determine dates such as the n-th instance of particular weekdays. For example, if you administer a payroll where paydays are the 2nd and 4th Thursdays of each month, you'd need to know what those dates are. One way to do this for any given month is to begin with the first-of-month date and shift it forward. It's easy enough to shift the date to the Thursday in that week; the trick is to figure out how many weeks forward to shift the result to reach the 2nd and 4th Thursdays. If the first of the month occurs on any day from Sunday through Thursday, you shift forward one week to reach the 2nd Thursday. If the first of the month occurs on Friday or later, you shift forward by two weeks. The 4th Thursday is of course two weeks after that. The following Perl code implements this logic to find all paydays in the year 2002. It runs a loop that constructs the first-of-month date for the months of the year. For each month, it issues a query that determines the dates of the 2nd and 4th Thursdays: my $year = 2002; print "MM/CCYY 2nd Thursday 4th Thursday\n"; foreach my $month (1..12) { my $first = sprintf ("%04d-%02d-01", $year, $month); my ($thu2, $thu4) = $dbh->selectrow_array (qq{ SELECT DATE_ADD( DATE_ADD(?,INTERVAL 5-DAYOFWEEK(?) DAY), INTERVAL IF(DAYOFWEEK(?) <= 5, 7, 14) DAY), DATE_ADD( DATE_ADD(?,INTERVAL 5-DAYOFWEEK(?) DAY), INTERVAL IF(DAYOFWEEK(?) <= 5, 21, 28) DAY) }, undef, $first, $first, $first, $first, $first, $first); printf "%02d/%04d %s %s\n", $month, $year, $thu2, $thu4; } The output from the program looks like this: MM/CCYY 2nd Thursday 4th Thursday 01/2002 2002-01-10 2002-01-24 02/2002 2002-02-14 2002-02-28 03/2002 2002-03-14 2002-03-28 04/2002 2002-04-11 2002-04-25 05/2002 2002-05-09 2002-05-23 06/2002 2002-06-13 2002-06-27 07/2002 2002-07-11 2002-07-25 08/2002 2002-08-08 2002-08-22 09/2002 2002-09-12 2002-09-26 10/2002 2002-10-10 2002-10-24 11/2002 2002-11-14 2002-11-28 12/2002 2002-12-12 2002-12-26 5.28 Performing Leap Year Calculations 5.28.1 Problem You need to perform a date calculation that must account for leap years. For example, the length of a month or a year depends on knowing whether or not the date falls in a leap year. 5.28.2 Solution Know how to test whether or not a year is a leap year and factor the result into your calculation. 5.28.3 Discussion Date calculations are complicated by the fact that months don't all have the same number of days, and an additional headache is that February has an extra day during leap years. This section shows how to determine whether or not any given date falls within a leap year, and how to take leap years into account when determining the length of a year or month. 5.28.4 Determining Whether a Date Occurs in a Leap Year To determine whether or not a date d falls within a leap year, obtain the year component using YEAR( ) and test the result. The common rule-of-thumb test for leap years is "divisible by four," which you can test using the % modulo operator like this: YEAR(d) % 4 = 0 However, that test is not technically correct. (For example, the year 1900 is divisible by four, but is not a leap year.) For a year to qualify as a leap year, it must satisfy both of the following constraints: · The year must be divisible by four. · The year cannot be divisible by 100, unless it is also divisible by 400. The meaning of the second constraint is that turn-of-century years are not leap years, except every fourth century. In SQL, you can express these conditions as follows: (YEAR(d) % 4 = 0) AND ((YEAR(d) % 100 != 0) OR (YEAR(d) % 400 = 0)) Running our date_val table through both the rule-of-thumb leap-year test and the complete test produces the following results: mysql> SELECT -> d, -> YEAR(d) % 4 = 0 -> AS "rule-of-thumb test", -> (YEAR(d) % 4 = 0) AND ((YEAR(d) % 100 != 0) OR (YEAR(d) % 400 = 0)) -> AS "complete test" -> FROM date_val; +------------+--------------------+---------------+ | d | rule-of-thumb test | complete test | +------------+--------------------+---------------+ | 1864-02-28 | 1 | 1 | | 1900-01-15 | 1 | 0 | | 1987-03-05 | 0 | 0 | | 1999-12-31 | 0 | 0 | | 2000-06-04 | 1 | 1 | +------------+--------------------+---------------+ As you can see, the two tests don't always produce the same result. In particular, the rule-of- thumb test fails for the year 1900; the complete test result is correct because it accounts for the turn-of-century constraint. Because the complete leap-year test needs to check the century, it requires four-digit year values. Two-digit years are ambiguous with respect to the century, making it impossible to assess the turn-of- century constraint. If you're working with date values within a program, you can perform leap-year tests with your API language rather than at the SQL level. Pull off the first four digits of the date string to get the year, then test it. If the language performs automatic string-to-number conversion of the year value, this is easy. Otherwise, you must convert the year value to numeric form before testing it. In Perl and PHP, the leap-year test syntax is as follows: $year = substr ($date, 0, 4); $is_leap = ($year % 4 == 0) && ($year % 100 != 0 || $year % 400 == 0); The syntax for Python is similar, although a type conversion operation is necessary: year = int (date[0:4]) is_leap = (year % 4 == 0) and (year % 100 != 0 or year % 400 == 0) Type conversion is necessary for Java as well: int year = Integer.valueOf (date.substring (0, 4)).intValue ( ); boolean is_leap = (year % 4 == 0) && (year % 100 != 0 || year % 400 == 0); 5.28.5 Using Leap Year Tests for Year-Length Calculations Years are usually 365 days long, but leap years have an extra day. To determine the length of a year in which a date falls, you can use one of the leap year tests just shown to figure out whether to add a day: $year = substr ($date, 0, 4); $is_leap = ($year % 4 == 0) && ($year % 100 != 0 || $year % 400 == 0); $days_in_year = ($is_leap ? 366 : 365); Another way to compute a year's length is to compute the date of the last day of the year and pass it to DAYOFYEAR( ): mysql> SET @d = '2003-04-13'; mysql> SELECT DAYOFYEAR(DATE_FORMAT(@d,'%Y-12-31')); +---------------------------------------+ | DAYOFYEAR(DATE_FORMAT(@d,'%Y-12-31')) | +---------------------------------------+ | 365 | +---------------------------------------+ mysql> SET @d = '2004-04-13'; mysql> SELECT DAYOFYEAR(DATE_FORMAT(@d,'%Y-12-31')); +---------------------------------------+ | DAYOFYEAR(DATE_FORMAT(@d,'%Y-12-31')) | +---------------------------------------+ | 366 | +---------------------------------------+ 5.28.6 Using Leap Year Tests for Month-Length Calculations Earlier in Recipe 5.23, we discussed how to determine the number of days in a month using date shifting to find the last day of the month. Leap-year testing provides an alternate way to accomplish the same objective. All months except February have a fixed length, so by examining the month part of a date, you can tell how long it is. You can also tell how long a given February is if you know whether or not it occurs within a leap year. A days-in-month expression can be written in SQL like this: mysql> SELECT d, -> ELT(MONTH(d), -> 31, -> IF((YEAR(d)%4 = 0) AND ((YEAR(d)%100 != 0) OR (YEAR(d)%400 = 0)),29,28), -> 31,30,31,30,31,31,30,31,30,31) -> AS 'days in month' -> FROM date_val; +------------+---------------+ | d | days in month | +------------+---------------+ | 1864-02-28 | 29 | | 1900-01-15 | 31 | | 1987-03-05 | 31 | | 1999-12-31 | 31 | | 2000-06-04 | 30 | +------------+---------------+ The ELT( ) function evaluates its first argument to determine its value n, then returns the n- th value from the following arguments. This is straightforward except for February, where ELT( ) must return 29 or 28 depending on whether or not the year is a leap year. Within an API language, you can write a function that, given an ISO-format date argument, returns the number of days in the month during which the date occurs. Here's a Perl version: sub days_in_month { my $date = shift; my $year = substr ($date, 0, 4); my $month = substr ($date, 5, 2); # month, 1-based my @days_in_month = (31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31); my $days = $days_in_month[$month-1]; my $is_leap = ($year % 4 == 0) && ($year % 100 != 0 || $year % 400 == 0); $days++ if $month == 2 && $is_leap; # add a day for Feb of leap years return ($days); } 5.29 Treating Dates or Times as Numbers 5.29.1 Problem You want to treat a temporal string as a number. 5.29.2 Solution Perform a string-to-number conversion. 5.29.3 Discussion In many cases, it is possible in MySQL to treat date and time values as numbers. This can sometimes be useful if you want to perform an arithmetic operation on the value. To force conversion of a temporal value to numeric form, add zero or use it in a numeric context: mysql> SELECT t1, -> t1+0 AS 't1 as number', -> FLOOR(t1) AS 't1 as number', -> FLOOR(t1/10000) AS 'hour part' -> FROM time_val; +----------+--------------+--------------+-----------+ | t1 | t1 as number | t1 as number | hour part | +----------+--------------+--------------+-----------+ | 15:00:00 | 150000 | 150000 | 15 | | 05:01:30 | 50130 | 50130 | 5 | | 12:30:20 | 123020 | 123020 | 12 | +----------+--------------+--------------+-----------+ The same kind of conversion can be performed for date or date-and-time values: mysql> SELECT d, d+0 FROM date_val; +------------+----------+ | d | d+0 | +------------+----------+ | 1864-02-28 | 18640228 | | 1900-01-15 | 19000115 | | 1987-03-05 | 19870305 | | 1999-12-31 | 19991231 | | 2000-06-04 | 20000604 | +------------+----------+ mysql> SELECT dt, dt+0 FROM datetime_val; +---------------------+----------------+ | dt | dt+0 | +---------------------+----------------+ | 1970-01-01 00:00:00 | 19700101000000 | | 1987-03-05 12:30:15 | 19870305123015 | | 1999-12-31 09:00:00 | 19991231090000 | | 2000-06-04 15:45:30 | 20000604154530 | +---------------------+----------------+ A value produced by adding zero is not the same as that produced by conversion into basic units like seconds or days. The result is essentially what you get by removing all the delimiters from the string representation of the original value. Also, conversion to numeric form works only for values that MySQL interprets temporally. If you try converting a literal string to a number by adding zero, you'll just get the first component: mysql> SELECT '1999-01-01'+0, '1999-01-01 12:30:45'+0, '12:30:45'+0; +----------------+-------------------------+--------------+ | '1999-01-01'+0 | '1999-01-01 12:30:45'+0 | '12:30:45'+0 | +----------------+-------------------------+--------------+ | 1999 | 1999 | 12 | +----------------+-------------------------+--------------+ This same thing happens with functions such as DATE_FORMAT( ) and TIME_FORMAT( ), or if you pull out parts of DATETIME or TIMESTAMP values with LEFT( ) or RIGHT( ). In +0 context, the results of these functions are treated as strings, not temporal types. 5.30 Forcing MySQL to Treat Strings as Temporal Values 5.30.1 Problem You want a string to be interpreted temporally. 5.30.2 Solution Use the string in a temporal context to give MySQL a hint about how to treat it. 5.30.3 Discussion If you need to make MySQL treat a string as a date or time, use it in an expression that provides a temporal context without changing the value. For example, you can't add zero to a literal TIME string to cause a time-to-number conversion, but if you use TIME_TO_SEC( ) and SEC_TO_TIME( ), you can: mysql> SELECT SEC_TO_TIME(TIME_TO_SEC('12:30:45'))+0; +----------------------------------------+ | SEC_TO_TIME(TIME_TO_SEC('12:30:45'))+0 | +----------------------------------------+ | 123045 | +----------------------------------------+ The conversion to and from seconds leaves the value unchanged but results in a context where MySQL treats the result as a TIME value. For date values, the procedure is similar, but uses TO_DAYS( ) and FROM_DAYS( ): mysql> SELECT '1999-01-01'+0, FROM_DAYS(TO_DAYS('1999-01-01'))+0; +----------------+------------------------------------+ | '1999-01-01'+0 | FROM_DAYS(TO_DAYS('1999-01-01'))+0 | +----------------+------------------------------------+ | 1999 | 19990101 | +----------------+------------------------------------+ For DATETIME- or TIMESTAMP-formatted strings, you can use DATE_ADD( ) to introduce a temporal context: mysql> SELECT -> DATE_ADD('1999-01-01 12:30:45',INTERVAL 0 DAY)+0 AS 'numeric datetime', -> DATE_ADD('19990101123045',INTERVAL 0 DAY)+0 AS 'numeric timestamp'; +------------------+-------------------+ | numeric datetime | numeric timestamp | +------------------+-------------------+ | 19990101123045 | 19990101123045 | +------------------+-------------------+ 5.31 Selecting Records Based on Their Temporal Characteristics 5.31.1 Problem You want to select records based on temporal constraints. 5.31.2 Solution Use a date or time condition in the WHERE clause. This may be based on direct comparison of column values with known values. Or it may be necessary to apply a function to column values to convert them to a more appropriate form for testing, such as using MONTH( ) to test the month part of a date. 5.31.3 Discussion Most of the preceding date-based techniques were illustrated by example queries that produce date or time values as output. You can use the same techniques in WHERE clauses to place date-based restrictions on the records selected by a query. For example, you can select records occurring before or after a given date, within a date range, or that match particular month or day values. 5.31.4 Comparing Dates to One Another The following queries find records from the date_val table that occur either before 1900 or during the 1900s: mysql> SELECT d FROM date_val where d < '1900-01-01'; +------------+ | d | +------------+ | 1864-02-28 | +------------+ mysql> SELECT d FROM date_val where d BETWEEN '1900-01-01' AND '1999-12- 31'; +------------+ | d | +------------+ | 1900-01-15 | | 1987-03-05 | | 1999-12-31 | +------------+ If your version of MySQL is older then 3.23.9, one problem to watch out for is that BETWEEN sometimes doesn't work correctly with literal date strings if they are not in ISO format. For example, this may fail: SELECT d FROM date_val WHERE d BETWEEN '1960-3-1' AND '1960-3-15'; If that happens, try rewriting the dates in ISO format for better results: SELECT d FROM date_val WHERE d BETWEEN '1960-03-01' AND '1960-03-15'; You can also rewrite the expression using two explicit comparisons: SELECT d FROM date_val WHERE d >= '1960-03-01' AND d <= '1960-03-15'; When you don't know the exact date you want for a WHERE clause, you can often calculate it using an expression. For example, to perform an "on this day in history" query to search for records in a table history to find events occurring exactly 50 years ago, do this: SELECT * FROM history WHERE d = DATE_SUB(CURDATE( ),INTERVAL 50 YEAR); You see this kind of thing in newspapers that run columns showing what the news events were in times past. (In essence, the query compiles those events that have reached their n-th anniversary.) If you want to retrieve events that occurred "on this day" for any year rather than "on this date" for a specific year, the query is a bit different. In that case, you need to find records that match the current calendar day, ignoring the year. That topic is discussed in Recipe 5.31.6 later in this section. Calculated dates are useful for range testing as well. For example, to find dates that occur within the last six years, use DATE_SUB( ) to calculate the cutoff date: mysql> SELECT d FROM date_val WHERE d >= DATE_SUB(CURDATE( ),INTERVAL 6 YEAR); +------------+ | d | +------------+ | 1999-12-31 | | 2000-06-04 | +------------+ Note that the expression in the WHERE clause isolates the date column d on one side of the comparison operator. This is usually a good idea; if the column is indexed, placing it alone on one side of a comparison allows MySQL to process the query more efficiently. To illustrate, the preceding WHERE clause can be written in a way that's logically equivalent, but much less efficient for MySQL to execute: ... WHERE DATE_ADD(d,INTERVAL 6 MONTH) >= CURDATE( ); Here, the d column is used within an expression. That means every row must be retrieved so that the expression can be evaluated and tested, which makes any index on the column useless. Sometimes it's not so obvious how to rewrite a comparison to isolate a date column on one side. For example, the following WHERE clause uses only part of the date column in the comparisons: ... WHERE YEAR(d) >= 1987 AND YEAR(d) <= 1991; To rewrite the first comparison, eliminate the YEAR( ) call and replace its righthand side with a complete date: ... WHERE d >= '1987-01-01' AND YEAR(d) <= 1991; Rewriting the second comparison is a little trickier. You can eliminate the YEAR( ) call on the lefthand side, just as with the first expression, but you can't just add -01-01 to the year on the righthand side. That would produce the following result, which is incorrect: ... WHERE d >= '1987-01-01' AND d <= '1991-01-01'; That fails because dates from 1991-01-02 to 1991-12-31 fail the test, but should pass. To rewrite the second comparison correctly, either of the following will do: ... WHERE d >= '1987-01-01' AND d <= '1991-12-31'; ... WHERE d >= '1987-01-01' AND d < '1992-01-01'; Another use for calculated dates occurs frequently in applications that create records that have a limited lifetime. Such applications must be able to determine which records to delete when performing an expiration operation. You can approach this problem a couple of ways: · Store a date in each record indicating when it was created. (Do this by making the column a TIMESTAMP or by setting it to NOW( ); see Recipe 5.34 for details.) To perform an expiration operation later, determine which records have a creation date that is too old by comparing that date to the current date. For example, the query to expire records that were created more than n days ago might look like this: DELETE FROM tbl_name WHERE create_date < DATE_SUB(NOW( ),INTERVAL n DAY); · Store an explicit expiration date in each record by calculating the expiration date with DATE_ADD( ) when the record is created. For a record that should expire in n days, you can do that like this: · INSERT INTO tbl_name (expire_date,...) VALUES(DATE_ADD(NOW( ),INTERVAL n DAY),...); To perform the expiration operation in this case, compare the expiration dates to the current date to see which ones have been reached: DELETE FROM tbl_name WHERE expire_date < NOW( ) 5.31.5 Comparing Times to One Another Comparisons involving times are similar to those involving dates. For example, to find times that occurred from 9 AM to 2 PM, use an expression like one of the following: ... WHERE t1 BETWEEN '09:00:00' AND '14:00:00'; ... WHERE HOUR(t1) BETWEEN 9 AND 14; For an indexed TIME column, the first method would be more efficient. The second method has the property that it works not only for TIME columns, but for DATETIME and TIMESTAMP columns as well. 5.31.6 Comparing Dates to Calendar Days To answer questions about particular days of the year, use calendar day testing. The following examples illustrate how to do this in the context of looking for birthdays: · Who has a birthday today? This requires matching a particular calendar day, so you extract the month and day but ignore the year when performing comparisons: ... WHERE MONTH(d) = MONTH(CURDATE( )) AND DAYOFMONTH(d) = DAYOFMONTH(CURDATE( )); This kind of query commonly is applied to biographical data to find lists of actors, politicians, musicians, etc., who were born on a particular day of the year. It's tempting to use DAYOFYEAR( ) to solve "on this day" problems, because it results in simpler queries. But DAYOFYEAR( ) doesn't work properly for leap years. The presence of February 29 throws off the values for days from March through December. · Who has a birthday this month? In this case, it's necessary to check only the month: ... WHERE MONTH(d) = MONTH(CURDATE( )); · Who has a birthday next month? The trick here is that you can't just add one to the current month to get the month number that qualifying dates must match. That gives you 13 for dates in December. To make sure you get 1 (January), use either of the following techniques: · ... WHERE MONTH(d) = MONTH(DATE_ADD(CURDATE( ),INTERVAL 1 MONTH)); ... WHERE MONTH(d) = MOD(MONTH(CURDATE( )),12)+1; 5.32 Using TIMESTAMP Values 5.32.1 Problem You want a record's creation time or last modification time to be automatically recorded. 5.32.2 Solution The TIMESTAMP column type can be used for this. However, it has properties that sometimes surprise people, so read this section to make sure you know what you'll be getting. Then read the next few sections for some applications of TIMESTAMP columns. 5.32.3 Discussion MySQL supports a TIMESTAMP column type that in many ways can be treated the same way as the DATETIME type. However, the TIMESTAMP type has some special properties: · The first TIMESTAMP column in a table is special at record-creation time: its default value is the current date and time. This means you need not specify its value at all in an INSERT statement if you want the column set to the record's creation time; MySQL will initialize it automatically. This also occurs if you set the column to NULL when creating the record. · The first TIMESTAMP is also special whenever any columns in a row are changed from their current values. MySQL automatically updates its value to the date and time at which the change was made. Note that the update happens only if you actually change a column value. Setting a column to its current value doesn't update the TIMESTAMP. · Other TIMESTAMP columns in a table are not special in the same way as the first one. Their default value is zero, not the current date and time. Also, their value does not change automatically when you modify other columns; to update them, you must change them yourself. · A TIMESTAMP column can be set to the current date and time at any time by setting it to NULL. This is true for any TIMESTAMP column, not just the first one. The TIMESTAMP properties that relate to record creation and modification make this column type particularly suited for certain kinds of problems, such as automatically recording the times at which table rows are inserted or updated. On the other hand, there are other properties that can be somewhat limiting: · TIMESTAMP values are represented in CCYYMMDDhhmmss format, which isn't especially intuitive or easy to read, and often needs reformatting for display. · The range for TIMESTAMP values starts at the beginning of the year 1970 and extends to about 2037. If you need a larger range, you need to use DATETIME values. The following sections show how to take advantage of the TIMESTAMP type's special properties. 5.33 Recording a Row's Last Modification Time 5.33.1 Problem You want to automatically record the time when a record was last updated. 5.33.2 Solution Include a TIMESTAMP column in your table. 5.33.3 Discussion To create a table where each row contains a value that indicates when the record was most recently updated, include a TIMESTAMP column. The column will be set to the current date and time when you create a new row, and updated whenever you update the value of another column in the row. Suppose you create a table tsdemo1 with a TIMESTAMP column that looks like this: CREATE TABLE tsdemo1 ( t TIMESTAMP, val INT ); Insert a couple of records into the table and then select its contents. (Issue the INSERT queries a few seconds apart so that you can see how the timestamps differ.) The first INSERT statement shows that you can set t to the current date and time by setting it explicitly to NULL; the second shows that you set t by omitting it from the INSERT statement entirely: mysql> INSERT INTO tsdemo1 (t,val) VALUES(NULL,5); mysql> INSERT INTO tsdemo1 (val) VALUES(10); mysql> SELECT * FROM tsdemo1; +----------------+------+ | t | val | +----------------+------+ | 20020715115825 | 5 | | 20020715115831 | 10 | +----------------+------+ Now issue a query that changes one record's val column and check its effect on the table's contents: mysql> UPDATE tsdemo1 SET val = 6 WHERE val = 5; mysql> SELECT * FROM tsdemo1; +----------------+------+ | t | val | +----------------+------+ | 20020715115915 | 6 | | 20020715115831 | 10 | +----------------+------+ The result shows that the TIMESTAMP has been updated only for the modified record. If you modify multiple records, the TIMESTAMP values in all of them will be updated: mysql> UPDATE tsdemo1 SET val = val + 1; mysql> SELECT * FROM tsdemo1; +----------------+------+ | t | val | +----------------+------+ | 20020715115926 | 7 | | 20020715115926 | 11 | +----------------+------+ Issuing an UPDATE statement that doesn't actually change the values in the val column doesn't update the TIMESTAMP values. To see this, set every record's val column to its current value, then review the contents of the table: mysql> UPDATE tsdemo1 SET val = val + 0; mysql> SELECT * FROM tsdemo1; +----------------+------+ | t | val | +----------------+------+ | 20020715115926 | 7 | | 20020715115926 | 11 | +----------------+------+ An alternative to using a TIMESTAMP is to use a DATETIME column and set it to NOW( ) explicitly when you create a record and whenever you update a record. However, in this case, all applications that use the table must implement the same strategy, which fails if even one application neglects to do so. 5.34 Recording a Row's Creation Time 5.34.1 Problem You want to record the time when a record was created, which TIMESTAMP will do, but you want that time not to change when the record is changed, and a TIMESTAMP cannot hold its value. 5.34.2 Solution Actually, it can; you just need to include a second TIMESTAMP column, which has different properties than the first. 5.34.3 Discussion If you want a column to be set initially to the time at which a record is created, but remain constant thereafter, a single TIMESTAMP is not the solution, because it will be updated whenever other columns in the record are updated. Instead, use two TIMESTAMP columns and take advantage of the fact that the second one won't have the same special properties of the first. Both columns can be set to the current date and time when the record is created. Thereafter, whenever you modify other columns in the record, the first TIMESTAMP column will be updated automatically to reflect the time of the change, but the second remains set to the record creation time. You can see how this works using the following table: CREATE TABLE tsdemo2 ( t_update TIMESTAMP, # record last-modification time t_create TIMESTAMP, # record creation time val INT ); Create the table, then insert into it as follows a record for which both TIMESTAMP columns are set to NULL, to initialize them to the current date and time: mysql> INSERT INTO tsdemo2 (t_update,t_create,val) VALUES(NULL,NULL,5); mysql> SELECT * FROM tsdemo2; +----------------+----------------+------+ | t_update | t_create | val | +----------------+----------------+------+ | 20020715120003 | 20020715120003 | 5 | +----------------+----------------+------+ After inserting the record, change the val column, then verify that the update modifies the t_update column and leaves the t_create column set to the record-creation time: mysql> UPDATE tsdemo2 SET val = val + 1; mysql> SELECT * FROM tsdemo2; +----------------+----------------+------+ | t_update | t_create | val | +----------------+----------------+------+ | 20020715120012 | 20020715120003 | 6 | +----------------+----------------+------+ As with the tsdemo1 table, updates to tsdemo2 records that don't actually modify a column cause no change to TIMESTAMP values: mysql> UPDATE tsdemo2 SET val = val + 0; mysql> SELECT * FROM tsdemo2; +----------------+----------------+------+ | t_update | t_create | val | +----------------+----------------+------+ | 20020715120012 | 20020715120003 | 6 | +----------------+----------------+------+ An alternative strategy is to use DATETIME columns for t_create and t_update. When creating a record, set them both to NOW( ) explicitly. When modifying a record, update t_update to NOW( ) and leave t_create alone. 5.35 Performing Calculations with TIMESTAMP Values 5.35.1 Problem You want to calculate intervals between TIMESTAMP values, search for records based on a TIMESTAMP column, and so forth. 5.35.2 Solution TIMESTAMP values are susceptible to the same kinds of date calculations as DATETIME values, such as comparison, shifting, and component extraction. 5.35.3 Discussion The following queries show some of the possible operations you can perform on TIMESTAMP values, using the tsdemo2 table from Recipe 5.34: · Records that have not been modified since they were created: SELECT * FROM tsdemo2 WHERE t_create = t_update; · Records modified within the last 12 hours: SELECT * FROM tsdemo2 WHERE t_update >= DATE_SUB(NOW( ),INTERVAL 12 HOUR); · The difference between the creation and modification times (here expressed both in seconds and in hours): · SELECT t_create, t_update, · UNIX_TIMESTAMP(t_update) - UNIX_TIMESTAMP(t_create) AS 'seconds', · (UNIX_TIMESTAMP(t_update) - UNIX_TIMESTAMP(t_create))/(60 * 60) AS 'hours' FROM tsdemo2; · Records created from 1 PM to 4 PM: · SELECT * FROM tsdemo2 WHERE HOUR(t_create) BETWEEN 13 AND 16; Or: SELECT * FROM tsdemo2 WHERE DATE_FORMAT(t_create,'%H%i%s') BETWEEN '130000' AND '160000'; Or even by using TIME_TO_SEC( ) to strip off the date part of the t_create values: SELECT * FROM tsdemo2 WHERE TIME_TO_SEC(t_create) BETWEEN TIME_TO_SEC('13:00:00') AND TIME_TO_SEC('16:00:00'); 5.36 Displaying TIMESTAMP Values in Readable Form 5.36.1 Problem You don't like the way that MySQL displays TIMESTAMP values. 5.36.2 Solution Reformat them with the DATE_FORMAT( ) function. 5.36.3 Discussion TIMESTAMP columns have certain desirable properties, but one that sometimes isn't so desirable is the display format (CCYYMMDDhhmmss). As a long unbroken string of digits, this is inconsistent with DATETIME format (CCYY-MM-DD hh:mm:ss) and is also more difficult to read. To rewrite TIMESTAMP values into DATETIME format, use the DATE_FORMAT( ) function. The following example uses the tsdemo2 table from Recipe 5.34: mysql> SELECT t_create, DATE_FORMAT(t_create,'%Y-%m-%d %T') FROM tsdemo2; +----------------+-------------------------------------+ | t_create | DATE_FORMAT(t_create,'%Y-%m-%d %T') | +----------------+-------------------------------------+ | 20020715120003 | 2002-07-15 12:00:03 | +----------------+-------------------------------------+ You can go in the other direction, too (to display DATETIME values in TIMESTAMP format), though this is much less common. One way is to use DATE_FORMAT( ); another that's simpler is to add zero: mysql> SELECT dt, -> DATE_FORMAT(dt,'%Y%m%d%H%i%s'), -> dt+0 -> FROM datetime_val; +---------------------+--------------------------------+----------------+ | dt | DATE_FORMAT(dt,'%Y%m%d%H%i%s') | dt+0 | +---------------------+--------------------------------+----------------+ | 1970-01-01 00:00:00 | 19700101000000 | 19700101000000 | | 1987-03-05 12:30:15 | 19870305123015 | 19870305123015 | | 1999-12-31 09:00:00 | 19991231090000 | 19991231090000 | | 2000-06-04 15:45:30 | 20000604154530 | 20000604154530 | +---------------------+--------------------------------+----------------+ See Recipe 5.3 for more information about rewriting temporal values in whatever format you like. Chapter 6. Sorting Query Results Section 6.1. Introduction Section 6.2. Using ORDER BY to Sort Query Results Section 6.3. Sorting Subsets of a Table Section 6.4. Sorting Expression Results Section 6.5. Displaying One Set of Values While Sorting by Another Section 6.6. Sorting and NULL Values Section 6.7. Controlling Case Sensitivity of String Sorts Section 6.8. Date-Based Sorting Section 6.9. Sorting by Calendar Day Section 6.10. Sorting by Day of Week Section 6.11. Sorting by Time of Day Section 6.12. Sorting Using Substrings of Column Values Section 6.13. Sorting by Fixed-Length Substrings Section 6.14. Sorting by Variable-Length Substrings Section 6.15. Sorting Hostnames in Domain Order Section 6.16. Sorting Dotted-Quad IP Values in Numeric Order Section 6.17. Floating Specific Values to the Head or Tail of the Sort Order Section 6.18. Sorting in User-Defined Orders Section 6.19. Sorting ENUM Values 6.1 Introduction This chapter covers sorting, an operation that is extremely important for controlling how MySQL displays results from SELECT statements. Sorting is performed by adding an ORDER BY clause to a query. Without such a clause, MySQL is free to return rows in any order, so sorting helps bring order to disorder and make query results easier to examine and understand. (Sorting also is performed implicitly when you use a GROUP BY clause, as discussed in Recipe 7.14.) One of the tables used for quite a few examples in this chapter is driver_log, a table that contains columns for recording daily mileage logs for a set of truck drivers: mysql> SELECT * FROM driver_log; +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 1 | Ben | 2001-11-30 | 152 | | 2 | Suzi | 2001-11-29 | 391 | | 3 | Henry | 2001-11-29 | 300 | | 4 | Henry | 2001-11-27 | 96 | | 5 | Ben | 2001-11-29 | 131 | | 6 | Henry | 2001-11-26 | 115 | | 7 | Suzi | 2001-12-02 | 502 | | 8 | Henry | 2001-12-01 | 197 | | 9 | Ben | 2001-12-02 | 79 | | 10 | Henry | 2001-11-30 | 203 | +--------+-------+------------+-------+ Many other examples use the mail table (first seen in earlier chapters): mysql> SELECT * FROM mail; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | | 2001-05-14 09:31:37 | gene | venus | barb | mars | 2291 | | 2001-05-14 11:52:17 | phil | mars | tricia | saturn | 5781 | | 2001-05-14 14:42:21 | barb | venus | barb | venus | 98151 | | 2001-05-14 17:03:01 | tricia | saturn | phil | venus | 2394482 | | 2001-05-15 07:17:48 | gene | mars | gene | saturn | 3824 | | 2001-05-15 08:50:57 | phil | venus | phil | venus | 978 | | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-15 17:35:31 | gene | saturn | gene | mars | 3856 | | 2001-05-16 09:00:28 | gene | venus | barb | mars | 613 | | 2001-05-16 23:04:19 | phil | venus | barb | venus | 10294 | | 2001-05-17 12:49:23 | phil | mars | tricia | saturn | 873 | | 2001-05-19 22:21:51 | gene | saturn | gene | venus | 23992 | +---------------------+---------+---------+---------+---------+---------+ Other tables are used occasionally as well. You can create most of them with the scripts found in the tables directory of the recipes distribution. The baseball1 directory contains instructions for creating the tables used in the examples relating to the baseball1.com baseball database. 6.2 Using ORDER BY to Sort Query Results 6.2.1 Problem Output from a query doesn't come out in the order you want. 6.2.2 Solution Add an ORDER BY clause to the query. 6.2.3 Discussion The contents of the driver_log and mail tables shown in the chapter introduction are disorganized and difficult to make any sense of. The exception is that the values in the id and t columns are in order, but that's just coincidental. Rows do tend to be returned from a table in the order they were originally inserted, but only until the table is subjected to delete and update operations. Rows inserted after that are likely to be returned in the middle of the result set somewhere. Many MySQL users notice this disturbance in row retrieval order, which leads them to ask, "How can I store rows in my table so they come out in a particular order when I retrieve them?" The answer to this question is that it's the wrong question. Storing rows is the server's job and you should let the server do it. (Besides, even if you could specify storage order, how would that help you if you wanted to see results sorted in different orders at different times?) When you select records, they're pulled out of the database and returned in whatever order the server happens to use. This may change, even for queries that don't sort rows, depending on which index the server happens to use when it executes a query, because the index can affect the retrieval order. Even if your rows appear to come out in the proper order naturally, a relational database makes no guarantee about the order in which it returns rows—unless you tell it how. To arrange the rows from a query result into a specific order, sort them by adding an ORDER BY clause to your SELECT statement. Without ORDER BY, you may find that the retrieval order changes when you modify the contents of your table. With an ORDER BY clause, MySQL will always sort rows the way you indicate. ORDER BY has the following general characteristics: · You can sort using a single column of values or multiple columns · You can sort any column in either ascending order (the default) or descending order · You can refer to sort columns by name, by their position within the output column list, or by using an alias This section shows some basic sorting techniques, and the following sections illustrate how to perform more complex sorts. Paradoxically, you can even use ORDER BY to disorder a result set, which is useful for randomizing the rows, or (in conjunction with LIMIT) for picking a row at random from a result set. Those uses for ORDER BY are described in Chapter 13. 6.2.4 Naming the Sort Columns and Specifying Sorting Direction The following set of examples demonstrates how to sort on a single column or multiple columns and how to sort in ascending or descending order. The examples select the rows in the driver_log table but sort them in different orders so that you can compare the effect of the different ORDER BY clauses. This query produces a single-column sort using the driver name: mysql> SELECT * FROM driver_log ORDER BY name; +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 1 | Ben | 2001-11-30 | 152 | | 5 | Ben | 2001-11-29 | 131 | | 9 | Ben | 2001-12-02 | 79 | | 3 | Henry | 2001-11-29 | 300 | | 4 | Henry | 2001-11-27 | 96 | | 6 | Henry | 2001-11-26 | 115 | | 8 | Henry | 2001-12-01 | 197 | | 10 | Henry | 2001-11-30 | 203 | | 2 | Suzi | 2001-11-29 | 391 | | 7 | Suzi | 2001-12-02 | 502 | +--------+-------+------------+-------+ The default sort direction is ascending. You can make the direction for an ascending sort explicit by adding ASC after the sorted column's name: SELECT * FROM driver_log ORDER BY name ASC; The opposite (or reverse) of ascending order is descending order, specified by adding DESC after the sorted column's name: mysql> SELECT * FROM driver_log ORDER BY name DESC; +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 2 | Suzi | 2001-11-29 | 391 | | 7 | Suzi | 2001-12-02 | 502 | | 3 | Henry | 2001-11-29 | 300 | | 4 | Henry | 2001-11-27 | 96 | | 6 | Henry | 2001-11-26 | 115 | | 8 | Henry | 2001-12-01 | 197 | | 10 | Henry | 2001-11-30 | 203 | | 1 | Ben | 2001-11-30 | 152 | | 5 | Ben | 2001-11-29 | 131 | | 9 | Ben | 2001-12-02 | 79 | +--------+-------+------------+-------+ If you closely examine the output from the queries just shown, you'll notice that although the rows are sorted by name, the rows for any given name aren't in any special order (The trav_date values aren't in date order for Henry or Ben, for example.) That's because MySQL doesn't sort something unless you tell it to: · The overall order of rows returned by a query is indeterminate unless you specify an ORDER BY clause. · In the same way, within a group of rows that sort together based on the values in a given column, the order of values in other columns also is indeterminate unless you name them in the ORDER BY clause. To more fully control output order, specify a multiple-column sort by listing each column to use for sorting, separated by commas. The following query sorts in ascending order by name and by trav_date within the rows for each name: mysql> SELECT * FROM driver_log ORDER BY name, trav_date; +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 5 | Ben | 2001-11-29 | 131 | | 1 | Ben | 2001-11-30 | 152 | | 9 | Ben | 2001-12-02 | 79 | | 6 | Henry | 2001-11-26 | 115 | | 4 | Henry | 2001-11-27 | 96 | | 3 | Henry | 2001-11-29 | 300 | | 10 | Henry | 2001-11-30 | 203 | | 8 | Henry | 2001-12-01 | 197 | | 2 | Suzi | 2001-11-29 | 391 | | 7 | Suzi | 2001-12-02 | 502 | +--------+-------+------------+-------+ Multiple-column sorts can be descending as well, but DESC must be specified after each column name to perform a fully descending sort: mysql> SELECT * FROM driver_log ORDER BY name DESC, trav_date DESC; +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 7 | Suzi | 2001-12-02 | 502 | | 2 | Suzi | 2001-11-29 | 391 | | 8 | Henry | 2001-12-01 | 197 | | 10 | Henry | 2001-11-30 | 203 | | 3 | Henry | 2001-11-29 | 300 | | 4 | Henry | 2001-11-27 | 96 | | 6 | Henry | 2001-11-26 | 115 | | 9 | Ben | 2001-12-02 | 79 | | 1 | Ben | 2001-11-30 | 152 | | 5 | Ben | 2001-11-29 | 131 | +--------+-------+------------+-------+ Multiple-column ORDER BY clauses can perform mixed-order sorting where some columns are sorted in ascending order and others in descending order. The following query sorts by name in descending order, then by trav_date in ascending order for each name: mysql> SELECT * FROM driver_log ORDER BY name DESC, trav_date; +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 2 | Suzi | 2001-11-29 | 391 | | 7 | Suzi | 2001-12-02 | 502 | | 6 | Henry | 2001-11-26 | 115 | | 4 | Henry | 2001-11-27 | 96 | | 3 | Henry | 2001-11-29 | 300 | | 10 | Henry | 2001-11-30 | 203 | | 8 | Henry | 2001-12-01 | 197 | | 5 | Ben | 2001-11-29 | 131 | | 1 | Ben | 2001-11-30 | 152 | | 9 | Ben | 2001-12-02 | 79 | +--------+-------+------------+-------+ Should You Sort Query Results Yourself? If you're issuing a SELECT query from within one of your own programs, you can retrieve an unsorted result set into a data structure, then sort the data structure using your programming language. But why reinvent the wheel? The MySQL server is built to sort efficiently, and you may as well let it do its job. A possible exception to this principle occurs when you need to sort a set of rows several different ways. In this case, rather than issuing several queries that differ only in the ORDER BY clause, it might be faster to retrieve the records once, and resort them as necessary within your program. 6.2.5 More Ways to Refer to Sort Columns The ORDER BY clauses in the queries shown thus far refer to the sorted columns by name. You can also name the columns by their positions within the output column list or by using aliases. Positions within the output list begin with 1. The following query sorts results by the third output column, miles: mysql> SELECT name, trav_date, miles FROM driver_log ORDER BY 3; +-------+------------+-------+ | name | trav_date | miles | +-------+------------+-------+ | Ben | 2001-12-02 | 79 | | Henry | 2001-11-27 | 96 | | Henry | 2001-11-26 | 115 | | Ben | 2001-11-29 | 131 | | Ben | 2001-11-30 | 152 | | Henry | 2001-12-01 | 197 | | Henry | 2001-11-30 | 203 | | Henry | 2001-11-29 | 300 | | Suzi | 2001-11-29 | 391 | | Suzi | 2001-12-02 | 502 | +-------+------------+-------+ If an output column has an alias, you can refer to the alias in the ORDER BY clause: mysql> SELECT name, trav_date, miles AS distance FROM driver_log -> ORDER BY distance; +-------+------------+----------+ | name | trav_date | distance | +-------+------------+----------+ | Ben | 2001-12-02 | 79 | | Henry | 2001-11-27 | 96 | | Henry | 2001-11-26 | 115 | | Ben | 2001-11-29 | 131 | | Ben | 2001-11-30 | 152 | | Henry | 2001-12-01 | 197 | | Henry | 2001-11-30 | 203 | | Henry | 2001-11-29 | 300 | | Suzi | 2001-11-29 | 391 | | Suzi | 2001-12-02 | 502 | +-------+------------+----------+ Aliases have an advantage over positionally specified columns in ORDER BY clause. If you use positions for sorting, but then revise the query to change the output column list, you may need to revise the position numbers in the ORDER BY clause as well. If you use aliases, this is unnecessary. (But note that some database engines do not support use of aliases in ORDER BY clauses, so this feature is not portable.) Columns specified by positions or by aliases can be sorted in either ascending or descending order, just like named columns: mysql> SELECT name, trav_date, miles FROM driver_log ORDER BY 3 DESC; +-------+------------+-------+ | name | trav_date | miles | +-------+------------+-------+ | Suzi | 2001-12-02 | 502 | | Suzi | 2001-11-29 | 391 | | Henry | 2001-11-29 | 300 | | Henry | 2001-11-30 | 203 | | Henry | 2001-12-01 | 197 | | Ben | 2001-11-30 | 152 | | Ben | 2001-11-29 | 131 | | Henry | 2001-11-26 | 115 | | Henry | 2001-11-27 | 96 | | Ben | 2001-12-02 | 79 | +-------+------------+-------+ 6.3 Sorting Subsets of a Table 6.3.1 Problem You don't want to sort an entire table, just part of it. 6.3.2 Solution Add a WHERE clause that selects only the records you want to see. 6.3.3 Discussion ORDER BY doesn't care how many rows there are; it sorts whatever rows the query returns. If you don't want to sort an entire table, add a WHERE clause to indicate which rows to select. For example, to sort the records for just one of the drivers, do something like this: mysql> SELECT trav_date, miles FROM driver_log WHERE name = 'Henry' -> ORDER BY trav_date; +------------+-------+ | trav_date | miles | +------------+-------+ | 2001-11-26 | 115 | | 2001-11-27 | 96 | | 2001-11-29 | 300 | | 2001-11-30 | 203 | | 2001-12-01 | 197 | +------------+-------+ Columns named in the ORDER BY clause need not be the same as those in the WHERE clause, as the preceding query demonstrates. The ORDER BY columns need not even be the ones you display, but that's covered later (Recipe 6.5). 6.4 Sorting Expression Results 6.4.1 Problem You want to sort a query result based on values calculated from a column, rather than using the values actually stored in the column. 6.4.2 Solution Put the expression that calculates the values in the ORDER BY clause. For older versions of MySQL that don't support ORDER BY expressions, use a workaround. 6.4.3 Discussion One of the columns in the mail table shows how large each mail message is, in bytes: mysql> SELECT * FROM mail; +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | | 2001-05-12 15:02:49 | phil | mars | phil | saturn | 1048 | | 2001-05-13 13:59:18 | barb | saturn | tricia | venus | 271 | ... Suppose you want to retrieve records for "big" mail messages (defined as those larger than 50,000 bytes), but you want them to be displayed and sorted by sizes in terms of kilobytes, not bytes. In this case, the values to sort are calculated by an expression. You can use ORDER BY to sort expression results, although the way you write the query may depend on your version of MySQL. Prior to MySQL 3.23.2, expressions in ORDER BY clauses are not allowed. To work around this problem, specify the expression in the output column list and either refer to it by position or give it an alias and refer to the alias:[1] [1] Wondering about the +1023 in the FLOOR( ) expression? That's there so that size values group to the nearest upper boundary of the 1024-byte categories. Without it, the values group by lower boundaries (for example, a 2047-byte message would be reported as having a size of 1 kilobyte rather than 2). This technique is discussed in more detail in Recipe 7.13. mysql> SELECT t, srcuser, FLOOR((size+1023)/1024) -> FROM mail WHERE size > 50000 -> ORDER BY 3; +---------------------+---------+-------------------------+ | t | srcuser | FLOOR((size+1023)/1024) | +---------------------+---------+-------------------------+ | 2001-05-11 10:15:08 | barb | 57 | | 2001-05-14 14:42:21 | barb | 96 | | 2001-05-12 12:48:13 | tricia | 191 | | 2001-05-15 10:25:52 | gene | 976 | | 2001-05-14 17:03:01 | tricia | 2339 | +---------------------+---------+-------------------------+ mysql> SELECT t, srcuser, FLOOR((size+1023)/1024) AS kilobytes -> FROM mail WHERE size > 50000 -> ORDER BY kilobytes; +---------------------+---------+-----------+ | t | srcuser | kilobytes | +---------------------+---------+-----------+ | 2001-05-11 10:15:08 | barb | 57 | | 2001-05-14 14:42:21 | barb | 96 | | 2001-05-12 12:48:13 | tricia | 191 | | 2001-05-15 10:25:52 | gene | 976 | | 2001-05-14 17:03:01 | tricia | 2339 | +---------------------+---------+-----------+ These techniques work for MySQL 3.23.2 and up, too, but you also have the additional option of putting the expression directly in the ORDER BY clause: mysql> SELECT t, srcuser, FLOOR((size+1023)/1024) -> FROM mail WHERE size > 50000 -> ORDER BY FLOOR((size+1023)/1024); +---------------------+---------+-------------------------+ | t | srcuser | FLOOR((size+1023)/1024) | +---------------------+---------+-------------------------+ | 2001-05-11 10:15:08 | barb | 57 | | 2001-05-14 14:42:21 | barb | 96 | | 2001-05-12 12:48:13 | tricia | 191 | | 2001-05-15 10:25:52 | gene | 976 | | 2001-05-14 17:03:01 | tricia | 2339 | +---------------------+---------+-------------------------+ However, even if you can put the expression in the ORDER BY clause, there are at least two reasons you might still want to use an alias: · It's easier to write the ORDER BY clause using the alias than by repeating the (rather cumbersome) expression. · The alias may be useful for display purposes, to provide a more meaningful column label. The same restriction on expressions in ORDER BY clauses applies to GROUP BY (which we'll get to in Chapter 7), and the same workarounds apply as well. If your version of MySQL is older than 3.23.2, be sure to remember these workarounds. Many of the queries in the rest of this book use expressions in ORDER BY or GROUP BY clauses; to use them with an older MySQL server, you'll need to rewrite them using the techniques just described. 6.5 Displaying One Set of Values While Sorting by Another 6.5.1 Problem You want to sort a result set using values that you're not selecting. 6.5.2 Solution That's not a problem. You can use columns in the ORDER BY clause that don't appear in the column output list. 6.5.3 Discussion ORDER BY is not limited to sorting only those columns named in the column output list. It can sort using values that are "hidden" (that is, not displayed in the query output). This technique is commonly used when you have values that can be represented different ways and you want to display one type of value but sort by another. For example, you may want to display mail message sizes not in terms of bytes, but as strings such as 103K for 103 kilobytes. You can convert a byte count to that kind of value using this expression: CONCAT(FLOOR((size+1023)/1024),'K') However, such values are strings, so they sort lexically, not numerically. If you use them for sorting, a value such as 96K sorts after 2339K, even though it represents a smaller number: mysql> SELECT t, srcuser, -> CONCAT(FLOOR((size+1023)/1024),'K') AS size_in_K -> FROM mail WHERE size > 50000 -> ORDER BY size_in_K; +---------------------+---------+-----------+ | t | srcuser | size_in_K | +---------------------+---------+-----------+ | 2001-05-12 12:48:13 | tricia | 191K | | 2001-05-14 17:03:01 | tricia | 2339K | | 2001-05-11 10:15:08 | barb | 57K | | 2001-05-14 14:42:21 | barb | 96K | | 2001-05-15 10:25:52 | gene | 976K | +---------------------+---------+-----------+ To achieve the desired output order, display the string, but use the actual numeric size for sorting: mysql> SELECT t, srcuser, -> CONCAT(FLOOR((size+1023)/1024),'K') AS size_in_K -> FROM mail WHERE size > 50000 -> ORDER BY size; +---------------------+---------+-----------+ | t | srcuser | size_in_K | +---------------------+---------+-----------+ | 2001-05-11 10:15:08 | barb | 57K | | 2001-05-14 14:42:21 | barb | 96K | | 2001-05-12 12:48:13 | tricia | 191K | | 2001-05-15 10:25:52 | gene | 976K | | 2001-05-14 17:03:01 | tricia | 2339K | +---------------------+---------+-----------+ Displaying values as strings but sorting them as numbers also can bail you out of some otherwise difficult situations. Members of sports teams typically are assigned a jersey number, which normally you might think should be stored using a numeric column. Not so fast! Some players like to have a jersey number of zero (0), and some like double-zero (00). If a team happens to have players with both numbers, you cannot represent them using a numeric column, because both values will be treated as the same number. The way out of the problem is to store jersey numbers as strings: CREATE TABLE roster ( name CHAR(30), # player name jersey_num CHAR(3) # jersey number ); Then the jersey numbers will display the same way you enter them, and 0 and 00 will be treated as distinct values. Unfortunately, although representing numbers as strings solves the problem of distinguishing 0 and 00, it introduces a different problem. Suppose a team comprises the following players: mysql> SELECT name, jersey_num FROM roster; +-----------+------------+ | name | jersey_num | +-----------+------------+ | Lynne | 29 | | Ella | 0 | | Elizabeth | 100 | | Nancy | 00 | | Jean | 8 | | Sherry | 47 | +-----------+------------+ The problem occurs when you try to sort the team members by jersey number. If those numbers are stored as strings, they'll sort lexically, and lexical order often differs from numeric order. That's certainly true for the team in question: mysql> SELECT name, jersey_num FROM roster ORDER BY jersey_num; +-----------+------------+ | name | jersey_num | +-----------+------------+ | Ella | 0 | | Nancy | 00 | | Elizabeth | 100 | | Lynne | 29 | | Sherry | 47 | | Jean | 8 | +-----------+------------+ The values 100 and 8 are out of place. But that's easily solved. Display the string values, but use the numeric values for sorting. To accomplish this, add zero to the jersey_num values to force a string-to-number conversion: mysql> SELECT name, jersey_num FROM roster ORDER BY jersey_num+0; +-----------+------------+ | name | jersey_num | +-----------+------------+ | Ella | 0 | | Nancy | 00 | | Jean | 8 | | Lynne | 29 | | Sherry | 47 | | Elizabeth | 100 | +-----------+------------+ The technique of displaying one value but sorting by another is also useful when you want to display composite values that are formed from multiple columns but that don't sort the way you want. For example, the mail table lists message senders using separate srcuser and srchost values. If you want to display message senders from the mail table as email addresses in srcuser@srchost format with the username first, you can construct those values using the following expression: CONCAT(srcuser,'@',srchost) However, those values are no good for sorting if you want to treat the hostname as more significant than the username. Instead, sort the results using the underlying column values rather than the displayed composite values: mysql> SELECT t, CONCAT(srcuser,'@',srchost) AS sender, size -> FROM mail WHERE size > 50000 -> ORDER BY srchost, srcuser; +---------------------+---------------+---------+ | t | sender | size | +---------------------+---------------+---------+ | 2001-05-15 10:25:52 | gene@mars | 998532 | | 2001-05-12 12:48:13 | tricia@mars | 194925 | | 2001-05-11 10:15:08 | barb@saturn | 58274 | | 2001-05-14 17:03:01 | tricia@saturn | 2394482 | | 2001-05-14 14:42:21 | barb@venus | 98151 | +---------------------+---------------+---------+ The same idea commonly is applied to sorting people's names. Suppose you have a table names that contains last and first names. To display records sorted by last name first, the query is straightforward when the columns are displayed separately: mysql> SELECT last_name, first_name FROM name -> ORDER BY last_name, first_name; +-----------+------------+ | last_name | first_name | +-----------+------------+ | Blue | Vida | | Brown | Kevin | | Gray | Pete | | White | Devon | | White | Rondell | +-----------+------------+ If instead you want to display each name as a single string composed of the first name, a space, and the last name, you can begin the query like this: SELECT CONCAT(first_name,' ',last_name) AS full_name FROM name ... But then how do you sort the names so they come out in the last name order? The answer is to display the composite names, but refer to the constituent values in the ORDER BY clause: mysql> SELECT CONCAT(first_name,' ',last_name) AS full_name -> FROM name -> ORDER BY last_name, first_name; +---------------+ | full_name | +---------------+ | Vida Blue | | Kevin Brown | | Pete Gray | | Devon White | | Rondell White | +---------------+ If you want to write queries that sort on non-displayed values, you'll have problems if the sort columns are expressions and you're using an older version of MySQL. This is because expressions aren't allowed in ORDER BY clauses until MySQL 3.23.2 (as discussed in Recipe 6.4). The solution is to "unhide" the expression—add it as an extra output column, and then refer to it by position or by using an alias. For example, to write a query that lists names from the names table with the longest names first, you might do this in MySQL 3.23.2 and up: mysql> SELECT CONCAT(first_name,' ',last_name) AS name -> FROM names -> ORDER BY LENGTH(CONCAT(first_name,' ',last_name)) DESC; +---------------+ | name | +---------------+ | Rondell White | | Kevin Brown | | Devon White | | Vida Blue | | Pete Gray | +---------------+ To rewrite this query for older versions of MySQL, put the expression in the output column list and use an alias to sort it: mysql> SELECT CONCAT(first_name,' ',last_name) AS name, -> LENGTH(CONCAT(first_name,' ',last_name)) AS len -> FROM names -> ORDER BY len DESC; +---------------+------+ | name | len | +---------------+------+ | Rondell White | 13 | | Kevin Brown | 11 | | Devon White | 11 | | Vida Blue | 9 | | Pete Gray | 9 | +---------------+------+ Or else refer to the additional output column by position: mysql> SELECT CONCAT(first_name,' ',last_name) AS name, -> LENGTH(CONCAT(first_name,' ',last_name)) AS len -> FROM names -> ORDER BY 2 DESC; +---------------+------+ | name | len | +---------------+------+ | Rondell White | 13 | | Kevin Brown | 11 | | Devon White | 11 | | Vida Blue | 9 | | Pete Gray | 9 | +---------------+------+ Whichever workaround you use, the output will of course contain a column that's there only for sorting purposes and that you really aren't interested in displaying. If you're running the query from the mysql program, that's unfortunate, but there's nothing you can do about the additional output. In your own programs, the extra output column is no problem. It'll be returned in the result set, but you can ignore it. Here's a Python example that demonstrates this. It runs the query, displays the names, and discards the name lengths: cursor = conn.cursor (MySQLdb.cursors.DictCursor) cursor.execute (""" SELECT CONCAT(first_name,' ',last_name) AS full_name, LENGTH(CONCAT(first_name,' ',last_name)) AS len FROM name ORDER BY len DESC """) for row in cursor.fetchall ( ): print row["full_name"] # print name, ignore length cursor.close ( ) 6.6 Sorting and NULL Values 6.6.1 Problem You want to sort a column that may contain NULL values. 6.6.2 Solution The placement of NULL values in a sorted list has changed over time and depends on your version of MySQL. If NULL values don't come out in the desired position within the sort order, trick them into appearing where you want. 6.6.3 Discussion When a sorted column contains NULL values, MySQL puts them all together in the sort order. It may seem a bit odd that NULL values are grouped this way, given that (as the following query shows) they are not considered equal in comparisons: mysql> SELECT NULL = NULL; +-------------+ | NULL = NULL | +-------------+ | NULL | +-------------+ On the other hand, NULL values conceptually do seem more similar to each other than to non- NULL values, and there's no good way to distinguish one NULL from another, anyway. However, although NULL values group together, they may be placed at the beginning or end of the sort order, depending on your version of MySQL. Prior to MySQL 4.0.2, NULL values sort to the beginning of the order (or at the end, if you specify DESC). From 4.0.2 on, MySQL sorts NULL values according to the ANSI SQL specification, and thus always places them first in the sort order, regardless of whether or not you specify DESC. Despite these differences, if you want NULL values at one end or the other of the sort order, you can force them to be placed where you want no matter which version of MySQL you're using. Suppose you have a table t with the following contents: mysql> SELECT val FROM t; +------+ | val | +------+ | 3 | | 100 | | NULL | | NULL | | 9 | +------+ Normally, sorting puts the NULL values at the beginning: mysql> SELECT val FROM t ORDER BY val; +------+ | val | +------+ | NULL | | NULL | | 3 | | 9 | | 100 | +------+ To put them at the end instead, introduce an extra ORDER BY column that maps NULL values to a higher value than non-NULL values: mysql> SELECT val FROM t ORDER BY IF(val IS NULL,1,0), val; +------+ | val | +------+ | 3 | | 9 | | 100 | | NULL | | NULL | +------+ That works for DESC sorts as well: mysql> SELECT val FROM t ORDER BY IF(val IS NULL,1,0), val DESC; +------+ | val | +------+ | 100 | | 9 | | 3 | | NULL | | NULL | +------+ If you find MySQL putting NULL values at the end of the sort order and you want them at the beginning, use the same technique, but reverse the second and third arguments of the IF( ) function to map NULL values to a lower value than non-NULL values: IF(val IS NULL,0,1) 6.7 Controlling Case Sensitivity of String Sorts 6.7.1 Problem String sorts are case sensitive when you don't want them to be, or vice versa. 6.7.2 Solution Alter the case sensitivity of the sorted values. 6.7.3 Discussion Chapter 4 discusses the fact that binary strings are case sensitive in comparisons, whereas non-binary strings are not. This property carries over into string sorting as well: ORDER BY produces lexical sorts that are case sensitive for binary strings and not case sensitive for non- binary strings. The following table textblob_val contains a TEXT column tstr and a BLOB column bstr that serve to demonstrate this: mysql> SELECT * FROM textblob_val; +------+------+ | tstr | bstr | +------+------+ | aaa | aaa | | AAA | AAA | | bbb | bbb | | BBB | BBB | +------+------+ Both columns contain the same values. But they produce different sort results, because TEXT columns are not case sensitive and BLOB columns are: mysql> SELECT tstr FROM textblob_val ORDER BY tstr; +------+ | tstr | +------+ | aaa | | AAA | | bbb | | BBB | +------+ mysql> SELECT bstr FROM textblob_val ORDER BY bstr; +------+ | bstr | +------+ | AAA | | BBB | | aaa | | bbb | +------+ To control case sensitivity in ORDER BY clauses, use the techniques discussed in Chapter 4 for affecting string comparisons. To perform a case-sensitive sort for strings that are not case sensitive (such as those in the tstr column) cast the sort column to binary-string form using the BINARY keyword: mysql> SELECT tstr FROM textblob_val ORDER BY BINARY tstr; +------+ | tstr | +------+ | AAA | | BBB | | aaa | | bbb | +------+ Another possibility is to convert the output column to binary and sort that: mysql> SELECT BINARY tstr FROM textblob_val ORDER BY 1; +-------------+ | BINARY tstr | +-------------+ | AAA | | BBB | | aaa | | bbb | +-------------+ You can also use the CAST( ) function that is available as of MySQL 4.0.2: mysql> SELECT tstr FROM textblob_val ORDER BY CAST(tstr AS BINARY); +------+ | tstr | +------+ | AAA | | BBB | | aaa | | bbb | +------+ The complementary operation is to sort binary strings in non-case-sensitive fashion. To do this, convert the values to uppercase or lowercase with UPPER( ) or LOWER( ): mysql> SELECT bstr FROM textblob_val ORDER BY UPPER(bstr); +------+ | bstr | +------+ | aaa | | AAA | | bbb | | BBB | +------+ Alternatively, you can convert the output column and sort that—but doing so affects the displayed values, possibly in an undesirable way: mysql> SELECT UPPER(bstr) FROM textblob_val ORDER BY 1; +-------------+ | UPPER(bstr) | +-------------+ | AAA | | AAA | | BBB | | BBB | +-------------+ 6.8 Date-Based Sorting 6.8.1 Problem You want to sort in temporal order. 6.8.2 Solution Sort using a date or time column type, ignoring parts of the values that are irrelevant if necessary. 6.8.3 Discussion Many types of information include date or time information and it's very often necessary to sort results in temporal order. MySQL knows how to sort temporal column types, so there's no special trick to ordering values in DATE, DATETIME, TIME, or TIMESTAMP columns. Begin with a table that contains values for each of those types: mysql> SELECT * FROM temporal_val; +------------+---------------------+----------+----------------+ | d | dt | t | ts | +------------+---------------------+----------+----------------+ | 1970-01-01 | 1884-01-01 12:00:00 | 13:00:00 | 19800101020000 | | 1999-01-01 | 1860-01-01 12:00:00 | 19:00:00 | 20210101030000 | | 1981-01-01 | 1871-01-01 12:00:00 | 03:00:00 | 19750101040000 | | 1964-01-01 | 1899-01-01 12:00:00 | 01:00:00 | 19850101050000 | +------------+---------------------+----------+----------------+ Using an ORDER BY clause with any of these columns sorts the values into the appropriate order: mysql> SELECT * FROM temporal_val ORDER BY d; +------------+---------------------+----------+----------------+ | d | dt | t | ts | +------------+---------------------+----------+----------------+ | 1964-01-01 | 1899-01-01 12:00:00 | 01:00:00 | 19850101050000 | | 1970-01-01 | 1884-01-01 12:00:00 | 13:00:00 | 19800101020000 | | 1981-01-01 | 1871-01-01 12:00:00 | 03:00:00 | 19750101040000 | | 1999-01-01 | 1860-01-01 12:00:00 | 19:00:00 | 20210101030000 | +------------+---------------------+----------+----------------+ mysql> SELECT * FROM temporal_val ORDER BY dt; +------------+---------------------+----------+----------------+ | d | dt | t | ts | +------------+---------------------+----------+----------------+ | 1999-01-01 | 1860-01-01 12:00:00 | 19:00:00 | 20210101030000 | | 1981-01-01 | 1871-01-01 12:00:00 | 03:00:00 | 19750101040000 | | 1970-01-01 | 1884-01-01 12:00:00 | 13:00:00 | 19800101020000 | | 1964-01-01 | 1899-01-01 12:00:00 | 01:00:00 | 19850101050000 | +------------+---------------------+----------+----------------+ mysql> SELECT * FROM temporal_val ORDER BY t; +------------+---------------------+----------+----------------+ | d | dt | t | ts | +------------+---------------------+----------+----------------+ | 1964-01-01 | 1899-01-01 12:00:00 | 01:00:00 | 19850101050000 | | 1981-01-01 | 1871-01-01 12:00:00 | 03:00:00 | 19750101040000 | | 1970-01-01 | 1884-01-01 12:00:00 | 13:00:00 | 19800101020000 | | 1999-01-01 | 1860-01-01 12:00:00 | 19:00:00 | 20210101030000 | +------------+---------------------+----------+----------------+ mysql> SELECT * FROM temporal_val ORDER BY ts; +------------+---------------------+----------+----------------+ | d | dt | t | ts | +------------+---------------------+----------+----------------+ | 1981-01-01 | 1871-01-01 12:00:00 | 03:00:00 | 19750101040000 | | 1970-01-01 | 1884-01-01 12:00:00 | 13:00:00 | 19800101020000 | | 1964-01-01 | 1899-01-01 12:00:00 | 01:00:00 | 19850101050000 | | 1999-01-01 | 1860-01-01 12:00:00 | 19:00:00 | 20210101030000 | +------------+---------------------+----------+----------------+ Sometimes a temporal sort uses only part of a date or time column. In that case, you can bust out the part or parts you need and use them to order the results. Some examples of this are given in the next few sections. 6.9 Sorting by Calendar Day 6.9.1 Problem You want to sort by day of the calendar year. 6.9.2 Solution Sort using the month and day of a date, ignoring the year. 6.9.3 Discussion Sorting in calendar order differs from sorting by date. You ignore the year part of the dates and sort using only the month and day to order records in terms of where they fall during the calendar year. Suppose you have an event table that looks like this when values are ordered by actual date of occurrence: mysql> SELECT date, description FROM event ORDER BY date; +------------+-------------------------------------+ | date | description | +------------+-------------------------------------+ | 1215-06-15 | Signing of the Magna Carta | | 1732-02-22 | George Washington's birthday | | 1776-07-14 | Bastille Day | | 1789-07-04 | US Independence Day | | 1809-02-12 | Abraham Lincoln's birthday | | 1919-06-28 | Signing of the Treaty of Versailles | | 1944-06-06 | D-Day at Normandy Beaches | | 1957-10-04 | Sputnik launch date | | 1958-01-31 | Explorer 1 launch date | | 1989-11-09 | Opening of the Berlin Wall | +------------+-------------------------------------+ To put these items in calendar order, sort them by month, then by day within month: mysql> SELECT date, description FROM event -> ORDER BY MONTH(date), DAYOFMONTH(date); +------------+-------------------------------------+ | date | description | +------------+-------------------------------------+ | 1958-01-31 | Explorer 1 launch date | | 1809-02-12 | Abraham Lincoln's birthday | | 1732-02-22 | George Washington's birthday | | 1944-06-06 | D-Day at Normandy Beaches | | 1215-06-15 | Signing of the Magna Carta | | 1919-06-28 | Signing of the Treaty of Versailles | | 1789-07-04 | US Independence Day | | 1776-07-14 | Bastille Day | | 1957-10-04 | Sputnik launch date | | 1989-11-09 | Opening of the Berlin Wall | +------------+-------------------------------------+ MySQL also has a DAYOFYEAR( ) function that you might think would be useful for calendar day sorting: mysql> SELECT date, description FROM event ORDER BY DAYOFYEAR(date); +------------+-------------------------------------+ | date | description | +------------+-------------------------------------+ | 1958-01-31 | Explorer 1 launch date | | 1809-02-12 | Abraham Lincoln's birthday | | 1732-02-22 | George Washington's birthday | | 1944-06-06 | D-Day at Normandy Beaches | | 1215-06-15 | Signing of the Magna Carta | | 1919-06-28 | Signing of the Treaty of Versailles | | 1789-07-04 | US Independence Day | | 1776-07-14 | Bastille Day | | 1957-10-04 | Sputnik launch date | | 1989-11-09 | Opening of the Berlin Wall | +------------+-------------------------------------+ That appears to work, but only because the table doesn't have records in it that expose a problem with the use of DAYOFYEAR( ): It can generate the same value for different calendar days. For example, February 29 of leap years and March 1 of non-leap years appear to be the same day: mysql> SELECT DAYOFYEAR('1996-02-29'), DAYOFYEAR('1997-03-01'); +-------------------------+-------------------------+ | DAYOFYEAR('1996-02-29') | DAYOFYEAR('1997-03-01') | +-------------------------+-------------------------+ | 60 | 60 | +-------------------------+-------------------------+ This property means that DAYOFYEAR( ) won't necessarily produce correct results for calendar sorting. It can group dates together that actually occur on different calendar days. If a table represents dates using separate year, month, and day columns, calendar sorting requires no date-part extraction. Just sort the relevant columns directly. For example, the master ballplayer table from the baseball1.com database distribution represents names and birth dates as follows: mysql> SELECT lastname, firstname, birthyear, birthmonth, birthday -> FROM master; +----------------+--------------+-----------+------------+----------+ | lastname | firstname | birthyear | birthmonth | birthday | +----------------+--------------+-----------+------------+----------+ | AARON | HANK | 1934 | 2 | 5 | | AARON | TOMMIE | 1939 | 8 | 5 | | AASE | DON | 1954 | 9 | 8 | | ABAD | ANDY | 1972 | 8 | 25 | | ABADIE | JOHN | 1854 | 11 | 4 | | ABBATICCHIO | ED | 1877 | 4 | 15 | | ABBEY | BERT | 1869 | 11 | 29 | | ABBEY | CHARLIE | 1866 | 10 | 14 | ... To sort those records in calendar order, use the birthmonth and birthday columns. Of course, that will leave records unsorted within any given day, so you may also want to add additional sort columns. The following query selects players with known birthdays, sorts them by calendar order, and by name for each calendar day: mysql> SELECT lastname, firstname, birthyear, birthmonth, birthday -> FROM master -> WHERE birthmonth IS NOT NULL AND birthday IS NOT NULL -> ORDER BY birthmonth, birthday, lastname, firstname; +----------------+--------------+-----------+------------+----------+ | lastname | firstname | birthyear | birthmonth | birthday | +----------------+--------------+-----------+------------+----------+ | ALLEN | ETHAN | 1904 | 1 | 1 | | BEIRNE | KEVIN | 1974 | 1 | 1 | | BELL | RUDY | 1881 | 1 | 1 | | BERTHRONG | HARRY | 1844 | 1 | 1 | | BETHEA | BILL | 1942 | 1 | 1 | | BISHOP | CHARLIE | 1924 | 1 | 1 | | BOBB | RANDY | 1948 | 1 | 1 | | BRUCKMILLER | ANDY | 1882 | 1 | 1 | ... For large datasets, sorting using separate date part columns can be much faster than sorts based on extracting pieces of DATE values. There's no overhead for part extraction, but more important, you can index the date part columns separately—something not possible with a DATE column. 6.10 Sorting by Day of Week 6.10.1 Problem You want to sort in day-of-week order. 6.10.2 Solution Use DAYOFWEEK( ) to convert a date column to its numeric day of week value. 6.10.3 Discussion Day-of-week sorting is similar to calendar day sorting, except that you use different functions to get at the relevant ordering values. You can get the day of the week using DAYNAME( ), but that produces strings that sort lexically rather than in day-of-week order (Sunday, Monday, Tuesday, etc.). Here the technique of displaying one value but sorting by another is useful (Recipe 6.5). Display day names using DAYNAME( ), but sort in day-of-week order using DAYOFWEEK( ), which returns numeric values from 1 to 7 for Sunday through Saturday: mysql> SELECT DAYNAME(date) AS day, date, description -> FROM event -> ORDER BY DAYOFWEEK(date); +----------+------------+-------------------------------------+ | day | date | description | +----------+------------+-------------------------------------+ | Sunday | 1776-07-14 | Bastille Day | | Sunday | 1809-02-12 | Abraham Lincoln's birthday | | Monday | 1215-06-15 | Signing of the Magna Carta | | Tuesday | 1944-06-06 | D-Day at Normandy Beaches | | Thursday | 1989-11-09 | Opening of the Berlin Wall | | Friday | 1957-10-04 | Sputnik launch date | | Friday | 1958-01-31 | Explorer 1 launch date | | Friday | 1732-02-22 | George Washington's birthday | | Saturday | 1789-07-04 | US Independence Day | | Saturday | 1919-06-28 | Signing of the Treaty of Versailles | +----------+------------+-------------------------------------+ If you want to sort in day-of-week order, but treat Monday as the first day of the week and Sunday as the last, you can use a the MOD( ) function to map Monday to 0, Tuesday to 1, ..., Sunday to 6: mysql> SELECT DAYNAME(date), date, description -> FROM event -> ORDER BY MOD(DAYOFWEEK(date) + 5, 7); +---------------+------------+-------------------------------------+ | DAYNAME(date) | date | description | +---------------+------------+-------------------------------------+ | Monday | 1215-06-15 | Signing of the Magna Carta | | Tuesday | 1944-06-06 | D-Day at Normandy Beaches | | Thursday | 1989-11-09 | Opening of the Berlin Wall | | Friday | 1957-10-04 | Sputnik launch date | | Friday | 1958-01-31 | Explorer 1 launch date | | Friday | 1732-02-22 | George Washington's birthday | | Saturday | 1789-07-04 | US Independence Day | | Saturday | 1919-06-28 | Signing of the Treaty of Versailles | | Sunday | 1776-07-14 | Bastille Day | | Sunday | 1809-02-12 | Abraham Lincoln's birthday | +---------------+------------+-------------------------------------+ The following table shows the DAYOFWEEK( ) expressions to use for putting any day of the week first in the sort order: Day to list first DAYOFWEEK( ) expression Sunday DAYOFWEEK(date) Monday MOD(DAYOFWEEK(date) + 5, 7) Tuesday MOD(DAYOFWEEK(date) + 4, 7) Wednesday MOD(DAYOFWEEK(date) + 3, 7) Thursday MOD(DAYOFWEEK(date) + 2, 7) Friday MOD(DAYOFWEEK(date) + 1, 7) Saturday MOD(DAYOFWEEK(date) + 0, 7) Another function that you can use for day-of-week sorting is WEEKDAY( ), although it returns a different set of values (0 for Monday through 6 for Sunday). 6.11 Sorting by Time of Day 6.11.1 Problem You want to sort in time-of-day order. 6.11.2 Solution Pull out the hour, minute, and second from the column that contains the time, and use them for sorting. 6.11.3 Discussion Time-of-day sorting can be done different ways, depending on your column type. If the values are stored in a TIME column, just sort them directly. To put DATETIME or TIMESTAMP values in time-of-day order, extract the time parts and sort them. For example, the mail table contains DATETIME values, which can be sorted by time of day like this: mysql> SELECT * FROM mail ORDER BY HOUR(t), MINUTE(t), SECOND(t); +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-15 07:17:48 | gene | mars | gene | saturn | 3824 | | 2001-05-15 08:50:57 | phil | venus | phil | venus | 978 | | 2001-05-16 09:00:28 | gene | venus | barb | mars | 613 | | 2001-05-14 09:31:37 | gene | venus | barb | mars | 2291 | | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-14 11:52:17 | phil | mars | tricia | saturn | 5781 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | ... You can also use TIME_TO_SEC( ), which strips off the date part and returns the time part as the corresponding number of seconds: mysql> SELECT * FROM mail ORDER BY TIME_TO_SEC(t); +---------------------+---------+---------+---------+---------+---------+ | t | srcuser | srchost | dstuser | dsthost | size | +---------------------+---------+---------+---------+---------+---------+ | 2001-05-15 07:17:48 | gene | mars | gene | saturn | 3824 | | 2001-05-15 08:50:57 | phil | venus | phil | venus | 978 | | 2001-05-16 09:00:28 | gene | venus | barb | mars | 613 | | 2001-05-14 09:31:37 | gene | venus | barb | mars | 2291 | | 2001-05-11 10:15:08 | barb | saturn | tricia | mars | 58274 | | 2001-05-15 10:25:52 | gene | mars | tricia | saturn | 998532 | | 2001-05-14 11:52:17 | phil | mars | tricia | saturn | 5781 | | 2001-05-12 12:48:13 | tricia | mars | gene | venus | 194925 | ... 6.12 Sorting Using Substrings of Column Values 6.12.1 Problem You want to sort a set of values using one or more substrings of each value. 6.12.2 Solution Extract the hunks you want and sort them separately. 6.12.3 Discussion This is an application of sorting by expression value (Recipe 6.4). If you want to sort records using just a particular portion of a column's values, extract the substring you need and use it in the ORDER BY clause. This is easiest if the substrings are at a fixed position and length within the column. For substrings of variable position or length, you may still be able to use them for sorting if there is some reliable way to identify them. The next several recipes show how to use substring-extraction to produce specialized sort orders. 6.13 Sorting by Fixed-Length Substrings 6.13.1 Problem You want to sort using parts of a column that occur at a given position within the column. 6.13.2 Solution Pull out the parts you need with LEFT( ), MID( ), or RIGHT( ) and sort them. 6.13.3 Discussion Suppose you have a housewares table that acts as a catalog for houseware furnishings, and that items are identified by 11-character ID values consisting of three subparts: a three- character category abbreviation (such as DIN for "dining room" or KIT for "kitchen"), a five- digit serial number, and a two-character country code indicating where the part is manufactured: mysql> SELECT * FROM housewares; +------------+------------------+ | id | description | +------------+------------------+ | DIN40672US | dining table | | KIT00372UK | garbage disposal | | KIT01729JP | microwave oven | | BED00038SG | bedside lamp | | BTH00485US | shower stall | | BTH00415JP | lavatory | +------------+------------------+ This is not necessarily a good way to store complex ID values, and later we'll consider how to represent them using separate columns (Recipe 11.14). But for now, assume that the values must be stored as just shown. If you want to sort records from this table based on the id values, you'd just use the entire column value: mysql> SELECT * FROM housewares ORDER BY id; +------------+------------------+ | id | description | +------------+------------------+ | BED00038SG | bedside lamp | | BTH00415JP | lavatory | | BTH00485US | shower stall | | DIN40672US | dining table | | KIT00372UK | garbage disposal | | KIT01729JP | microwave oven | +------------+------------------+ But you might also have a need to sort on any of the three subparts (for example, to sort by country of manufacture). For that kind of operation, it's helpful to use functions that pull out pieces of a column, such as LEFT( ), MID( ), and RIGHT( ). These functions can be used to break apart the id values into their three components: mysql> SELECT id, -> LEFT(id,3) AS category, -> MID(id,4,5) AS serial, -> RIGHT(id,2) AS country -> FROM housewares; +------------+----------+--------+---------+ | id | category | serial | country | +------------+----------+--------+---------+ | DIN40672US | DIN | 40672 | US | | KIT00372UK | KIT | 00372 | UK | | KIT01729JP | KIT | 01729 | JP | | BED00038SG | BED | 00038 | SG | | BTH00485US | BTH | 00485 | US | | BTH00415JP | BTH | 00415 | JP | +------------+----------+--------+---------+ Any of those fixed-length substrings of the id values can be used for sorting, either alone or in combination. To sort by product category, extract the category value and use it in the ORDER BY clause: mysql> SELECT * FROM housewares ORDER BY LEFT(id,3); +------------+------------------+ | id | description | +------------+------------------+ | BED00038SG | bedside lamp | | BTH00485US | shower stall | | BTH00415JP | lavatory | | DIN40672US | dining table | | KIT00372UK | garbage disposal | | KIT01729JP | microwave oven | +------------+------------------+ To sort rows by product serial number, use MID( ) to extract the middle five characters from the id values, beginning with the fourth: mysql> SELECT * FROM housewares ORDER BY MID(id,4,5); +------------+------------------+ | id | description | +------------+------------------+ | BED00038SG | bedside lamp | | KIT00372UK | garbage disposal | | BTH00415JP | lavatory | | BTH00485US | shower stall | | KIT01729JP | microwave oven | | DIN40672US | dining table | +------------+------------------+ This appears to be a numeric sort, but it's actually a string sort, because MID( ) returns strings. It just so happens that the lexical and numeric sort order are the same in this case due to the fact that the "numbers" have leading zeros to make them all the same length. To sort by country code, use the rightmost two characters of the id values: mysql> SELECT * FROM housewares ORDER BY RIGHT(id,2); +------------+------------------+ | id | description | +------------+------------------+ | KIT01729JP | microwave oven | | BTH00415JP | lavatory | | BED00038SG | bedside lamp | | KIT00372UK | garbage disposal | | DIN40672US | dining table | | BTH00485US | shower stall | +------------+------------------+ You can also sort using combinations of substrings. For example, to sort by country code and serial number, the query looks like this: mysql> SELECT * FROM housewares ORDER BY RIGHT(id,2), MID(id,4,5); +------------+------------------+ | id | description | +------------+------------------+ | BTH00415JP | lavatory | | KIT01729JP | microwave oven | | BED00038SG | bedside lamp | | KIT00372UK | garbage disposal | | BTH00485US | shower stall | | DIN40672US | dining table | +------------+------------------+ 6.14 Sorting by Variable-Length Substrings 6.14.1 Problem You want to sort using parts of a column that do not occur at a given position within the column. 6.14.2 Solution Figure out some way to identify the parts you need so you can extract them; otherwise, you're out of luck. 6.14.3 Discussion If the substrings that you want to use for sorting vary in length, you need a reliable means of extracting just the part of the column values that you want. To see how this works, create a housewares2 table that is like the housewares table used in the previous section, except that it has no leading zeros in the serial number part of the id values: mysql> SELECT * FROM housewares2; +------------+------------------+ | id | description | +------------+------------------+ | DIN40672US | dining table | | KIT372UK | garbage disposal | | KIT1729JP | microwave oven | | BED38SG | bedside lamp | | BTH485US | shower stall | | BTH415JP | lavatory | +------------+------------------+ The category and country parts of the id values can be extracted and sorted using LEFT( ) and RIGHT( ), just as for the housewares table. But now the numeric segments of the values have different lengths and cannot be extracted and sorted using a simple MID( ) call. Instead, use SUBSTRING( ) to skip over the first three characters and return the remainder beginning with the fourth character (the first digit): mysql> SELECT id, SUBSTRING(id,4) FROM housewares2; +------------+-----------------+ | id | SUBSTRING(id,4) | +------------+-----------------+ | DIN40672US | 40672US | | KIT372UK | 372UK | | KIT1729JP | 1729JP | | BED38SG | 38SG | | BTH485US | 485US | | BTH415JP | 415JP | +------------+-----------------+ Then take everything but the rightmost two columns. One way to do this is as follows: mysql> SELECT id, LEFT(SUBSTRING(id,4),LENGTH(SUBSTRING(id,4)-2)) -> FROM housewares2; +------------+-------------------------------------------------+ | id | LEFT(SUBSTRING(id,4),LENGTH(SUBSTRING(id,4)-2)) | +------------+-------------------------------------------------+ | DIN40672US | 40672 | | KIT372UK | 372 | | KIT1729JP | 1729 | | BED38SG | 38 | | BTH485US | 485 | | BTH415JP | 415 | +------------+-------------------------------------------------+ But that's more complex than necessary. The SUBSTRING( ) function takes an optional third argument specifying a desired result length, and we know that the length of the middle part is equal to the length of the string minus five (three for the characters at the beginning and two for the characters at the end). The following query demonstrates how to get the numeric middle part by beginning with the ID, then stripping off the rightmost suffix: mysql> SELECT id, SUBSTRING(id,4), SUBSTRING(id,4,LENGTH(id)-5) -> FROM housewares2; +------------+-----------------+------------------------------+ | id | SUBSTRING(id,4) | SUBSTRING(id,4,LENGTH(id)-5) | +------------+-----------------+------------------------------+ | DIN40672US | 40672US | 40672 | | KIT372UK | 372UK | 372 | | KIT1729JP | 1729JP | 1729 | | BED38SG | 38SG | 38 | | BTH485US | 485US | 485 | | BTH415JP | 415JP | 415 | +------------+-----------------+------------------------------+ Unfortunately, although the final expression correctly extracts the numeric part from the IDs, the resulting values are strings. Consequently, they sort lexically rather than numerically: mysql> SELECT * FROM housewares2 -> ORDER BY SUBSTRING(id,4,LENGTH(id)-5); +------------+------------------+ | id | description | +------------+------------------+ | KIT1729JP | microwave oven | | KIT372UK | garbage disposal | | BED38SG | bedside lamp | | DIN40672US | dining table | | BTH415JP | lavatory | | BTH485US | shower stall | +------------+------------------+ How to deal with that? One way is to add zero, which tells MySQL to perform a string-to- number conversion that results in a numeric sort of the serial number values: mysql> SELECT * FROM housewares2 -> ORDER BY SUBSTRING(id,4,LENGTH(id)-5)+0; +------------+------------------+ | id | description | +------------+------------------+ | BED38SG | bedside lamp | | KIT372UK | garbage disposal | | BTH415JP | lavatory | | BTH485US | shower stall | | KIT1729JP | microwave oven | | DIN40672US | dining table | +------------+------------------+ But in this particular case, a simpler solution is possible. It's not necessary to calculate the length of the numeric part of the string, because the string-to-number conversion operation will strip off trailing non-numeric suffixes and provide the values needed to sort on the variable-length serial number portion of the id values. That means the third argument to SUBSTRING( ) actually isn't needed: mysql> SELECT * FROM housewares2 -> ORDER BY SUBSTRING(id,4)+0; +------------+------------------+ | id | description | +------------+------------------+ | BED38SG | bedside lamp | | KIT372UK | garbage disposal | | BTH415JP | lavatory | | BTH485US | shower stall | | KIT1729JP | microwave oven | | DIN40672US | dining table | +------------+------------------+ In the preceding example, the ability to extract variable-length substrings was based on the different kinds of characters in the middle of the ID values, compared to the characters on the ends (that is, digits versus non-digits). In other cases, you may be able to use delimiter characters to pull apart column values. For the next examples, assume a housewares3 table with id values that look like this: mysql> SELECT * FROM housewares3; +---------------+------------------+ | id | description | +---------------+------------------+ | 13-478-92-2 | dining table | | 873-48-649-63 | garbage disposal | | 8-4-2-1 | microwave oven | | 97-681-37-66 | bedside lamp | | 27-48-534-2 | shower stall | | 5764-56-89-72 | lavatory | +---------------+------------------+ To extract segments from these values, use SUBSTRING_INDEX(str,c,n). It searches into a string str for the n-th occurrence of a given character c and returns everything to the left of that character. For example, the following call returns 13-478: SUBSTRING_INDEX('13-478-92-2','-',2) If n is negative, the search for c proceeds from the right and returns the rightmost string. This call returns 478-92-2: SUBSTRING_INDEX('13-478-92-2','-',-3) By combining SUBSTRING_INDEX( ) calls with positive and negative indexes, it's possible to extract successive pieces from each id value. One way is to extract the first n segments of the value, then pull off the rightmost one. By varying n from 1 to 4, we get the successive segments from left to right: SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',1),'-',-1) SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',2),'-',-1) SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',3),'-',-1) SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',4),'-',-1) The first of those expressions can be optimized, because the inner SUBSTRING_INDEX( ) call returns a single-segment string and is sufficient by itself to return the leftmost id segment: SUBSTRING_INDEX(id,'-',1) Another way to obtain substrings is to extract the rightmost n segments of the value, then pull off the first one. Here we vary n from -4 to -1: SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',-4),'-',1) SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',-3),'-',1) SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',-2),'-',1) SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',-1),'-',1) Again, an optimization is possible. For the fourth expression, the inner SUBSTRING_INDEX( ) call is sufficient to return the final substring: SUBSTRING_INDEX(id,'-',-1) These expressions can be difficult to read and understand, and you probably should try experimenting with a few of them to see how they work. Here is an example that shows how to get the second and fourth segments from the id values: mysql> SELECT -> id, -> SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',2),'-',-1) AS segment2, -> SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',4),'-',-1) AS segment4 -> FROM housewares3; +---------------+----------+----------+ | id | segment2 | segment4 | +---------------+----------+----------+ | 13-478-92-2 | 478 | 2 | | 873-48-649-63 | 48 | 63 | | 8-4-2-1 | 4 | 1 | | 97-681-37-66 | 681 | 66 | | 27-48-534-2 | 48 | 2 | | 5764-56-89-72 | 56 | 72 | +---------------+----------+----------+ To use the substrings for sorting, use the appropriate expressions in the ORDER BY clause. (Remember to force a string-to-number conversion by adding zero if you want the sort to be numeric rather than lexical.) The following two queries order the results based on the second id segment. The first sorts lexically, the second numerically: mysql> SELECT * FROM housewares3 -> ORDER BY SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',2),'-',-1); +---------------+------------------+ | id | description | +---------------+------------------+ | 8-4-2-1 | microwave oven | | 13-478-92-2 | dining table | | 873-48-649-63 | garbage disposal | | 27-48-534-2 | shower stall | | 5764-56-89-72 | lavatory | | 97-681-37-66 | bedside lamp | +---------------+------------------+ mysql> SELECT * FROM housewares3 -> ORDER BY SUBSTRING_INDEX(SUBSTRING_INDEX(id,'-',2),'-',-1)+0; +---------------+------------------+ | id | description | +---------------+------------------+ | 8-4-2-1 | microwave oven | | 873-48-649-63 | garbage disposal | | 27-48-534-2 | shower stall | | 5764-56-89-72 | lavatory | | 13-478-92-2 | dining table | | 97-681-37-66 | bedside lamp | +---------------+------------------+ The substring-extraction expressions here are messy, but at least the column values to which we're applying them have a consistent number of segments. To sort values that have varying numbers of segments, the job can be more difficult. The next section shows an example illustrating why that is. 6.15 Sorting Hostnames in Domain Order 6.15.1 Problem You want to sort hostnames in domain order, with the rightmost parts of the names more significant than the leftmost parts. 6.15.2 Solution Break apart the names and sort the pieces from right to left. 6.15.3 Discussion Hostnames are strings and therefore their natural sort order is lexical. However, it's often desirable to sort hostnames in domain order, where the rightmost segments of the hostname values are more significant than the leftmost segments. Suppose you have a table hostname that contains the following names: mysql> SELECT name FROM hostname ORDER BY name; +--------------------+ | name | +--------------------+ | cvs.php.net | | dbi.perl.org | | jakarta.apache.org | | lists.mysql.com | | mysql.com | | www.kitebird.com | +--------------------+ The preceding query demonstrates the natural lexical sort order of the name values. That differs from domain order, as shown by the following table: Lexical order Domain order cvs.php.net www.kitebird.com dbi.perl.org mysql.com jakarta.apache.org lists.mysql.com lists.mysql.com cvs.php.net mysql.com jakarta.apache.org www.kitebird.com dbi.perl.org Producing domain-ordered output is a substring-sorting problem, where it's necessary to extract each segment of the names so they can be sorted in right-to-left fashion. There is also an additional complication if your values contain different numbers of segments, as our example hostnames do. (Most of them have three segments, but mysql.com has only two.) To extract the pieces of the hostnames, begin by using SUBSTRING_INDEX( ) in a manner similar to that described previously in Recipe 6.14. The hostname values have a maximum of three segments, from which the pieces can be extracted left to right like this: SUBSTRING_INDEX(SUBSTRING_INDEX(name,'.',-3),'.',1) SUBSTRING_INDEX(SUBSTRING_INDEX(name,'.',-2),'.',1) SUBSTRING_INDEX(name,'.',-1) These expressions work properly as long as all the hostnames have three components. But if a name has fewer than three, we don't get the correct result, as the following query demonstrates: mysql> SELECT name, -> SUBSTRING_INDEX(SUBSTRING_INDEX(name,'.',-3),'.',1) AS leftmost, -> SUBSTRING_INDEX(SUBSTRING_INDEX(name,'.',-2),'.',1) AS middle, -> SUBSTRING_INDEX(name,'.',-1) AS rightmost -> FROM hostname; +--------------------+----------+----------+-----------+ | name | leftmost | middle | rightmost | +--------------------+----------+----------+-----------+ | cvs.php.net | cvs | php | net | | dbi.perl.org | dbi | perl | org | | lists.mysql.com | lists | mysql | com | | mysql.com | mysql | mysql | com | | jakarta.apache.org | jakarta | apache | org | | www.kitebird.com | www | kitebird | com | +--------------------+----------+----------+-----------+ Notice the output for the mysql.com row; it has mysql for the value of the leftmost column, where it should have an empty string. The segment-extraction expressions work by pulling off the rightmost n segments, then returning the leftmost segment of the result. The source of the problem for mysql.com is that if there aren't n segments, the expression simply returns the leftmost segment of however many there are. To fix this problem, prepend a sufficient number of periods to the hostname values to guarantee that they have the requisite number of segments: mysql> SELECT name, -> SUBSTRING_INDEX(SUBSTRING_INDEX(CONCAT('..',name),'.',-3),'.',1) -> AS leftmost, -> SUBSTRING_INDEX(SUBSTRING_INDEX(CONCAT('.',name),'.',-2),'.',1) -> AS middle, -> SUBSTRING_INDEX(name,'.',-1) AS rightmost -> FROM hostname; +--------------------+----------+----------+-----------+ | name | leftmost | middle | rightmost | +--------------------+----------+----------+-----------+ | cvs.php.net | cvs | php | net | | dbi.perl.org | dbi | perl | org | | lists.mysql.com | lists | mysql | com | | mysql.com | | mysql | com | | jakarta.apache.org | jakarta | apache | org | | www.kitebird.com | www | kitebird | com | +--------------------+----------+----------+-----------+ That's pretty ugly. But these expressions do serve to extract the substrings that are needed for sorting hostname values correctly in right-to-left fashion: mysql> SELECT name FROM hostname -> ORDER BY -> SUBSTRING_INDEX(name,'.',-1), -> SUBSTRING_INDEX(SUBSTRING_INDEX(CONCAT('.',name),'.',-2),'.',1), -> SUBSTRING_INDEX(SUBSTRING_INDEX(CONCAT('..',name),'.',-3),'.',1); +--------------------+ | name | +--------------------+ | www.kitebird.com | | mysql.com | | lists.mysql.com | | cvs.php.net | | jakarta.apache.org | | dbi.perl.org | +--------------------+ If you had hostnames with a maximum of four segments rather than three, you'd need to add to the ORDER BY clause another SUBSTRING_INDEX( ) expression that prepends three dots to the hostname values. 6.16 Sorting Dotted-Quad IP Values in Numeric Order 6.16.1 Problem You want to sort strings that represent IP numbers in numeric order. 6.16.2 Solution Break apart the strings and sort the pieces numerically. Or just use INET_ATON( ). 6.16.3 Discussion If a table contains IP numbers represented as strings in dotted-quad notation (for example, 111.122.133.144), they'll sort lexically rather than numerically. To produce a numeric ordering instead, you can sort them as four-part values with each part sorted numerically. To accomplish this, use a technique similar to that for sorting hostnames, but with the following differences: · Dotted quads always have four segments, so there's no need to prepend dots to the value before extracting substrings. · Dotted quads sort left to right, so the order in which substrings are used in the ORDER BY clause is opposite to that used for hostname sorting. · The segments of dotted-quad values are numbers, so add zero to each substring to tell MySQL to using a numeric sort rather than a lexical one. Suppose you have a hostip table with a string-valued ip column containing IP numbers: mysql> SELECT ip FROM hostip ORDER BY ip; +-----------------+ | ip | +-----------------+ | 127.0.0.1 | | 192.168.0.10 | | 192.168.0.2 | | 192.168.1.10 | | 192.168.1.2 | | 21.0.0.1 | | 255.255.255.255 | +-----------------+ The preceding query produces output sorted in lexical order. To sort the ip values numerically, you can extract each segment and add zero to convert it to a number using an ORDER BY clause like this: mysql> SELECT ip FROM hostip -> ORDER BY -> SUBSTRING_INDEX(ip,'.',1)+0, -> SUBSTRING_INDEX(SUBSTRING_INDEX(ip,'.',-3),'.',1)+0, -> SUBSTRING_INDEX(SUBSTRING_INDEX(ip,'.',-2),'.',1)+0, -> SUBSTRING_INDEX(ip,'.',-1)+0; +-----------------+ | ip | +-----------------+ | 21.0.0.1 | | 127.0.0.1 | | 192.168.0.2 | | 192.168.0.10 | | 192.168.1.2 | | 192.168.1.10 | | 255.255.255.255 | +-----------------+ A simpler solution is possible if you have MySQL 3.23.15 or higher. Then you can sort the IP values using the INET_ATON( ) function, which converts a network address directly to its underlying numeric form: mysql> SELECT ip FROM hostip ORDER BY INET_ATON(ip); +-----------------+ | ip | +-----------------+ | 21.0.0.1 | | 127.0.0.1 | | 192.168.0.2 | | 192.168.0.10 | | 192.168.1.2 | | 192.168.1.10 | | 255.255.255.255 | +-----------------+ If you're tempted to sort by simply adding zero to the ip value and using ORDER BY on the result, consider the values that kind of string-to-number conversion actually will produce: mysql> SELECT ip, ip+0 FROM hostip; +-----------------+---------+ | ip | ip+0 | +-----------------+---------+ | 127.0.0.1 | 127 | | 192.168.0.2 | 192.168 | | 192.168.0.10 | 192.168 | | 192.168.1.2 | 192.168 | | 192.168.1.10 | 192.168 | | 255.255.255.255 | 255.255 | | 21.0.0.1 | 21 | +-----------------+---------+ The conversion retains only as much of each value as can be interpreted as a valid number. The remainder would be unavailable for sorting purposes, each though it's necessary to produce a correct ordering. 6.17 Floating Specific Values to the Head or Tail of the Sort Order 6.17.1 Problem You want a column to sort the way it normally does, except for a few values that you want at a specific spot. 6.17.2 Solution Add another sort column to the ORDER BY clause that places those few values where you want them. The remaining sort columns will have their usual effect for the other values. 6.17.3 Discussion If you want to sort a result set normally except that you want particular values first, create an additional sort column that is 0 for those values and 1 for everything else. We used this technique earlier to float NULL values to the high end of the sort order (see Recipe 6.6), but it works for other types of information as well. Suppose you want to sort mail table messages in sender/recipient order, with the exception that you want to put messages for phil first. You can do that like this: mysql> SELECT t, srcuser, dstuser, size -> FROM mail -> ORDER BY IF(srcuser='phil',0,1), srcuser, dstuser; +---------------------+---------+---------+---------+ | t | srcuser | dstuser | size | +---------------------+---------+---------+---------+ | 2001-05-16 23:04:19 | phil | barb | 10294 | | 2001-05-12 15:02:49 | phil | phil | 1048 | | 2001-05-15 08:50:57 | phil | phil | 978 | | 2001-05-14 11:52:17 | phil | tricia | 5781 | | 2001-05-17 12:49:23 | phil | tricia | 873 | | 2001-05-14 14:42:21 | barb | barb | 98151 | | 2001-05-11 10:15:08 | barb | tricia | 58274 | | 2001-05-13 13:59:18 | barb | tricia | 271 | | 2001-05-14 09:31:37 | gene | barb | 2291 | | 2001-05-16 09:00:28 | gene | barb | 613 | | 2001-05-15 07:17:48 | gene | gene | 3824 | | 2001-05-15 17:35:31 | gene | gene | 3856 | | 2001-05-19 22:21:51 | gene | gene | 23992 | | 2001-05-15 10:25:52 | gene | tricia | 998532 | | 2001-05-12 12:48:13 | tricia | gene | 194925 | | 2001-05-14 17:03:01 | tricia | phil | 2394482 | +---------------------+---------+---------+---------+ The value of the extra sort column is 0 for rows where the srcuser value is phil, and 1 for all other rows. By making that the most significant sort column, records for messages sent by phil float to the top of the output. (To sink them to the bottom instead, either sort the column in reverse order using DESC, or reverse the order of the second and third arguments of the IF( ) function.) You can also use this technique for particular conditions, not just specific values. To put first those records where people sent messages to themselves, do this: mysql> SELECT t, srcuser, dstuser, size -> FROM mail -> ORDER BY IF(srcuser=dstuser,0,1), srcuser, dstuser; +---------------------+---------+---------+---------+ | t | srcuser | dstuser | size | +---------------------+---------+---------+---------+ | 2001-05-14 14:42:21 | barb | barb | 98151 | | 2001-05-15 07:17:48 | gene | gene | 3824 | | 2001-05-15 17:35:31 | gene | gene | 3856 | | 2001-05-19 22:21:51 | gene | gene | 23992 | | 2001-05-12 15:02:49 | phil | phil | 1048 | | 2001-05-15 08:50:57 | phil | phil | 978 | | 2001-05-11 10:15:08 | barb | tricia | 58274 | | 2001-05-13 13:59:18 | barb | tricia | 271 | | 2001-05-14 09:31:37 | gene | barb | 2291 | | 2001-05-16 09:00:28 | gene | barb | 613 | | 2001-05-15 10:25:52 | gene | tricia | 998532 | | 2001-05-16 23:04:19 | phil | barb | 10294 | | 2001-05-14 11:52:17 | phil | tricia | 5781 | | 2001-05-17 12:49:23 | phil | tricia | 873 | | 2001-05-12 12:48:13 | tricia | gene | 194925 | | 2001-05-14 17:03:01 | tricia | phil | 2394482 | +---------------------+---------+---------+---------+ If you have a pretty good idea about the contents of your table, you can sometimes eliminate the extra sort column. For example, srcuser is never NULL in the mail table, so the previous query can be rewritten as follows to use one less column in the ORDER BY clause (assuming that NULL values sort ahead of all non-NULL values): mysql> SELECT t, srcuser, dstuser, size -> FROM mail -> ORDER BY IF(srcuser=dstuser,NULL,srcuser), dstuser; +---------------------+---------+---------+---------+ | t | srcuser | dstuser | size | +---------------------+---------+---------+---------+ | 2001-05-14 14:42:21 | barb | barb | 98151 | | 2001-05-15 07:17:48 | gene | gene | 3824 | | 2001-05-15 17:35:31 | gene | gene | 3856 | | 2001-05-19 22:21:51 | gene | gene | 23992 | | 2001-05-12 15:02:49 | phil | phil | 1048 | | 2001-05-15 08:50:57 | phil | phil | 978 | | 2001-05-11 10:15:08 | barb | tricia | 58274 | | 2001-05-13 13:59:18 | barb | tricia | 271 | | 2001-05-14 09:31:37 | gene | barb | 2291 | | 2001-05-16 09:00:28 | gene | barb | 613 | | 2001-05-15 10:25:52 | gene | tricia | 998532 | | 2001-05-16 23:04:19 | phil | barb | 10294 | | 2001-05-14 11:52:17 | phil | tricia | 5781 | | 2001-05-17 12:49:23 | phil | tricia | 873 | | 2001-05-12 12:48:13 | tricia | gene | 194925 | | 2001-05-14 17:03:01 | tricia | phil | 2394482 | +---------------------+---------+---------+---------+ 6.18 Sorting in User-Defined Orders 6.18.1 Problem You want to define the sort order for all values in a column. 6.18.2 Solution Use FIELD( ) to map column values onto a sequence that places the values in the desired order. 6.18.3 Discussion The previous section showed how to make a specific group of rows go to the head of the sort order. If you want to impose a specific order on all values in a column, use the FIELD( ) function to map them to a list of numeric values and use the numbers for sorting. FIELD( ) compares its first argument to the following arguments and returns a number indicating which one of them it matches. The following FIELD( ) call compares value to str1, str2, str3, and str4, and returns 1, 2, 3, or 4, depending on which one of them value is equal to: FIELD(value,str1,str2,str3,str4) The number of comparison values need not be four; FIELD( ) takes a variable-length argument list. If value is NULL or none of the values match, FIELD( ) returns 0. FIELD( ) can be used to sort an arbitrary set of values into any order you please. For example, to display driver_log records for Henry, Suzi, and Ben, in that order, do this: mysql> SELECT * FROM driver_log -> ORDER BY FIELD(name,'Henry','Suzi','Ben'); +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 3 | Henry | 2001-11-29 | 300 | | 4 | Henry | 2001-11-27 | 96 | | 6 | Henry | 2001-11-26 | 115 | | 8 | Henry | 2001-12-01 | 197 | | 10 | Henry | 2001-11-30 | 203 | | 2 | Suzi | 2001-11-29 | 391 | | 7 | Suzi | 2001-12-02 | 502 | | 1 | Ben | 2001-11-30 | 152 | | 5 | Ben | 2001-11-29 | 131 | | 9 | Ben | 2001-12-02 | 79 | +--------+-------+------------+-------+ You can use FIELD( ) with column substrings, too. To sort items from the housewares table by country of manufacture using the order US, UK, JP, SG, do this: mysql> SELECT id, description FROM housewares -> ORDER BY FIELD(RIGHT(id,2),'US','UK','JP','SG'); +------------+------------------+ | id | description | +------------+------------------+ | DIN40672US | dining table | | BTH00485US | shower stall | | KIT00372UK | garbage disposal | | KIT01729JP | microwave oven | | BTH00415JP | lavatory | | BED00038SG | bedside lamp | +------------+------------------+ More generally, FIELD( ) can be used to sort any kind of category-based values into specific orders when the categories don't sort naturally into any useful sequence. 6.19 Sorting ENUM Values 6.19.1 Problem ENUM values don't sort like other string columns. 6.19.2 Solution Learn how they work, and exploit those properties to your own advantage. 6.19.3 Discussion ENUM is considered a string column type, but ENUM values have the special property that they are stored numerically with values ordered the same way they are listed in the table definition. These numeric values affect how enumerations are sorted, which can be very useful. Suppose you have a table named weekday containing an enumeration column day that has weekday names as its members: CREATE TABLE weekday ( day ENUM('Sunday','Monday','Tuesday','Wednesday', 'Thursday','Friday','Saturday') ); Internally, MySQL defines the enumeration values Sunday through Saturday to have numeric values from 1 to 7. To see this for yourself, create the table using the definition just shown, then insert into it a record for each day of the week. However, to make the insertion order differ from sorted order (so you can see the effect of sorting), add the days in random order: mysql> INSERT INTO weekday (day) VALUES('Monday'),('Friday'), -> ('Tuesday'), ('Sunday'), ('Thursday'), ('Saturday'), ('Wednesday'); Then select the values, both as strings and as the internal numeric value (the latter are obtained by using +0 to effect a string-to-number conversion): mysql> SELECT day, day+0 FROM weekday; +-----------+-------+ | day | day+0 | +-----------+-------+ | Monday | 2 | | Friday | 6 | | Tuesday | 3 | | Sunday | 1 | | Thursday | 5 | | Saturday | 7 | | Wednesday | 4 | +-----------+-------+ Notice that because the query includes no ORDER BY clause, the records are returned in unsorted order. If you add an ORDER BY day clause, it becomes apparent that MySQL uses the internal numeric values for sorting: mysql> SELECT day, day+0 FROM weekday ORDER BY day; +-----------+-------+ | day | day+0 | +-----------+-------+ | Sunday | 1 | | Monday | 2 | | Tuesday | 3 | | Wednesday | 4 | | Thursday | 5 | | Friday | 6 | | Saturday | 7 | +-----------+-------+ What about occasions when you do want to sort ENUM values in lexical order? Force them to be treated as strings for sorting using the CONCAT( ) function. CONCAT( ) normally takes multiple arguments and concatenates them into a single string. But it can be used with just a single argument, which is useful when all you want is its behavior of producing a string result: mysql> SELECT day, day+0 FROM weekday ORDER BY CONCAT(day); +-----------+-------+ | day | day+0 | +-----------+-------+ | Friday | 6 | | Monday | 2 | | Saturday | 7 | | Sunday | 1 | | Thursday | 5 | | Tuesday | 3 | | Wednesday | 4 | +-----------+-------+ If you always (or nearly always) sort a non-enumeration column in a specific non-lexical order, consider changing the column type to ENUM, with its values listed in the desired sort order. To see how this works, create a color table containing a string column and populate it with some sample rows: mysql> CREATE TABLE color (name CHAR(10)); mysql> INSERT INTO color (name) VALUES ('blue'),('green'), -> ('indigo'),('orange'),('red'),('violet'),('yellow'); Sorting by the name column at this point produces lexical order because the column contains CHAR values: mysql> SELECT name FROM color ORDER BY name; +--------+ | name | +--------+ | blue | | green | | indigo | | orange | | red | | violet | | yellow | +--------+ Now suppose you want to sort the column by the order in which colors occur in the rainbow. (This order is given by the name "Roy G. Biv," where successive letters of that name indicate the first letter of the corresponding color name.) One way to produce a rainbow sort is to use FIELD( ): mysql> SELECT name FROM color -> ORDER BY -> FIELD(name,'red','orange','yellow','green','blue','indigo','violet'); +--------+ | name | +--------+ | red | | orange | | yellow | | green | | blue | | indigo | | violet | +--------+ To accomplish the same end without FIELD( ), use ALTER TABLE to convert the name column to an ENUM that lists the colors in the desired sort order: mysql> ALTER TABLE color -> MODIFY name -> ENUM('red','orange','yellow','green','blue','indigo','violet'); After converting the table, sorting on the name column produces rainbow sorting naturally with no special treatment: mysql> SELECT name FROM color ORDER BY name; +--------+ | name | +--------+ | red | | orange | | yellow | | green | | blue | | indigo | | violet | +--------+ Chapter 7. Generating Summaries Introduction Summarizing with COUNT( ) Summarizing with MIN( ) and MAX( ) Summarizing with SUM( ) and AVG( ) Using DISTINCT to Eliminate Duplicates Finding Values Associated with Minimum and Maximum Values Controlling String Case Sensitivity for MIN( ) and MAX( ) Dividing a Summary into Subgroups Summaries and NULL Values Selecting Only Groups with Certain Characteristics Determining Whether Values are Unique Grouping by Expression Results Categorizing Non-Categorical Data Controlling Summary Display Order Finding Smallest or Largest Summary Values Date-Based Summaries Working with Per-Group and Overall Summary Values Simultaneously Generating a Report That Includes a Summary and a List 7.1 Introduction Database systems are useful for storing and retrieving records, but they also can boil down information to summarize your data in more concise form. Summaries are useful when you want the overall picture rather than the details. They're also typically more readily understood than a long list of records. Summary techniques allow you to answer questions such as "How many?" or "What is the total?" or "What is the range of values?" If you're running a business, you may want to know how many customers you have in each state, or how much sales volume you're generating each month. You could determine the per-state count by producing a list of customer records and counting them yourself, but that makes no sense when MySQL can count them for you. Similarly, to determine sales volume by month, a list of raw order information records is not especially useful if you have to add up the order amounts yourself. Let MySQL do it. The examples just mentioned illustrate two common summary types. The first (the number of customer records per state) is a counting summary. The content of each record is important only for purposes of placing it into the proper group or category for counting. Such summaries are essentially histograms, where you sort items into a set of bins and count the number of items in each bin. The second example (sales volume per month) is an instance of a summary that's based on the contents of records—sales totals are computed from sales values in individual order records. Yet another kind of summary produces neither counts nor sums, but simply a list of unique values. This is useful if you don't care how many instances of each value are present, but only which values are present. If you want to know the states in which you have customers, you want a list of the distinct state names contained in the records, not a list consisting of the state value from every record. Sometimes it's even useful to apply one summary technique to the result of another summary. For example, to determine how many states your customers live in, generate a list of unique customer states, then count them. The type of summaries you can perform may depend on the kind of data you're working with. A counting summary can be generated from any kind of values, whether they be numbers, strings, or dates. For summaries that involve sums or averages, only numeric values can be used. You can count instances of customer state names to produce a demographic analysis of your customer base, but you cannot add or average state names—that doesn't make sense. Summary operations in MySQL involve the following SQL constructs: · To compute a summary value from a set of individual values, use one of the functions known as aggregate functions. These are so called because they operate on aggregates (groups) of values. Aggregate functions include COUNT( ), which counts records or values in a query result; MIN( ) and MAX( ), which find smallest and largest values; and SUM( ) and AVG( ), which produce sums and means of values. These functions can be used to compute a value for the entire result set, or with a GROUP BY clause to group the rows into subsets and obtain an aggregate value for each one. · To obtain a list of unique values, use SELECT DISTINCT rather than SELECT. · To count how may distinct values there are, use COUNT(DISTINCT) rather than COUNT( ). The recipes in this chapter first illustrate basic summary techniques, then show how to perform more complex summary operations. You'll find additional examples of summary methods in later chapters, particularly those that cover joins and statistical operations. (See Chapter 12 and Chapter 13.) The primary tables used for examples here are the driver_log and mail tables. These were also used heavily in Chapter 6, so they should look familiar. A third table used recurrently throughout the chapter is states, which has rows containing a few pieces of information for each of the United States: mysql> SELECT * FROM states ORDER BY name; +----------------+--------+------------+----------+ | name | abbrev | statehood | pop | +----------------+--------+------------+----------+ | Alabama | AL | 1819-12-14 | 4040587 | | Alaska | AK | 1959-01-03 | 550043 | | Arizona | AZ | 1912-02-14 | 3665228 | | Arkansas | AR | 1836-06-15 | 2350725 | | California | CA | 1850-09-09 | 29760021 | | Colorado | CO | 1876-08-01 | 3294394 | | Connecticut | CT | 1788-01-09 | 3287116 | ... The name and abbrev columns list the full state name and the corresponding abbreviation. The statehood column indicates the day on which the state entered the Union. pop is the state population as of April, 1990, as reported by the U.S. Census Bureau. Other tables are used occasionally as well. You can create most of them with the scripts found in the tables directory of the recipes distribution. The tables containing data from the baseball1.com baseball database can be created using the instructions in the baseball1 directory, and the kjv table is described in Recipe 4.12. 7.2 Summarizing with COUNT( ) 7.2.1 Problem You want to count the number of rows in a table, the number of rows that match certain conditions, or the number of times that particular values occur. 7.2.2 Solution Use the COUNT( ) function. 7.2.3 Discussion To count the number of rows in an entire table or that match particular conditions, use the COUNT( ) function. For example, to display the contents of the records in a table, you could use a SELECT * query, but to count them instead, use SELECT COUNT(*). Without a WHERE clause, the query counts all the records in the table, such as in the following query, which shows how many rows the driver_log table contains: mysql> SELECT COUNT(*) FROM driver_log; +----------+ | COUNT(*) | +----------+ | 10 | +----------+ If you don't know how many U.S. states there are, this query tells you: mysql> SELECT COUNT(*) FROM states; +----------+ | COUNT(*) | +----------+ | 50 | +----------+ COUNT(*) with no WHERE clause is very quick for ISAM or MyISAM tables. For BDB or InnoDB tables, you may want to avoid it; the query requires a full table scan for those table types, which can be slow for large tables. If an approximate row count is all you require and you have MySQL 3.23 or later, a workaround that avoids a full scan is to use SHOW TABLE STATUS and examine the Rows value in the output. Were states an InnoDB table, the query output might look like this: mysql> SHOW TABLE STATUS FROM cookbook LIKE 'states'\G *************************** 1. row *************************** Name: states Type: InnoDB Row_format: Dynamic Rows: 50 Avg_row_length: 327 Data_length: 16384 Max_data_length: NULL Index_length: 0 Data_free: 0 Auto_increment: NULL Create_time: NULL Update_time: NULL Check_time: NULL Create_options: Comment: InnoDB free: 479232 kB To count only the number of rows that match certain conditions, add an appropriate WHERE clause to the query. The conditions can be arbitrary, making COUNT( ) useful for answering many kinds of questions: · How many times did drivers travel more than 200 miles in a day? · mysql> SELECT COUNT(*) FROM driver_log WHERE miles > 200; · +----------+ · | COUNT(*) | · +----------+ · | 4 | +----------+ · How many days did Suzi drive? · mysql> SELECT COUNT(*) FROM driver_log WHERE name = 'Suzi'; · +----------+ · | COUNT(*) | · +----------+ · | 2 | +----------+ · How many states did the United States consist of at the beginning of the 20th century? · mysql> SELECT COUNT(*) FROM states WHERE statehood < '1900-01-01'; · +----------+ · | COUNT(*) | · +----------+ · | 45 | +----------+ · How many of those states joined the Union in the 19th century? · mysql> SELECT COUNT(*) FROM states · -> WHERE statehood BETWEEN '1800-01-01' AND '1899-12-31'; · +----------+ · | COUNT(*) | · +----------+ · | 29 | +----------+ The COUNT( ) function actually has two forms. The form we've been using, COUNT(*), counts rows. The other form, COUNT(expr), takes a column name or expression argument and counts the number of non-NULL values. The following query shows how to produce both a row count for a table and a count of the number of non-NULL values in one of its columns: SELECT COUNT(*), COUNT(mycol) FROM mytbl; The fact that COUNT(expr) doesn't count NULL values is useful when producing multiple counts from the same set of values. To count the number of Saturday and Sunday trips in the driver_log table with a single query, do this: mysql> SELECT -> COUNT(IF(DAYOFWEEK(trav_date)=7,1,NULL)) AS 'Saturday trips', -> COUNT(IF(DAYOFWEEK(trav_date)=1,1,NULL)) AS 'Sunday trips' -> FROM driver_log; +----------------+--------------+ | Saturday trips | Sunday trips | +----------------+--------------+ | 1 | 2 | +----------------+--------------+ Or to count weekend versus weekday trips, do this: mysql> SELECT -> COUNT(IF(DAYOFWEEK(trav_date) IN (1,7),1,NULL)) AS 'weekend trips', -> COUNT(IF(DAYOFWEEK(trav_date) IN (1,7),NULL,1)) AS 'weekday trips' -> FROM driver_log; +---------------+---------------+ | weekend trips | weekday trips | +---------------+---------------+ | 3 | 7 | +---------------+---------------+ The IF( ) expressions determine, for each column value, whether or not it should be counted. If so, the expression evaluates to 1 and COUNT( ) counts it. If not, the expression evaluates to NULL and COUNT( ) ignores it. The effect is to count the number of values that satisfy the condition given as the first argument to IF( ). 7.2.4 See Also The difference between COUNT(*) and COUNT(expr) is discussed further in "Summaries and NULL Values." 7.3 Summarizing with MIN( ) and MAX( ) 7.3.1 Problem You need to determine the smallest or largest of a set of values. 7.3.2 Solution Use MIN( ) to find the smallest value, MAX( ) to find the largest. 7.3.3 Discussion Finding smallest or largest values is somewhat akin to sorting, except that instead of producing an entire set of sorted values, you select only a single value at one end or the other of the sorted range. This kind of operation applies to questions about smallest, largest, oldest, newest, most expensive, least expensive, and so forth. One way to find such values is to use the MIN( ) and MAX( ) functions. (Another way to address these questions is to use LIMIT; see the discussions in Recipe 3.17 and Recipe 3.19.) Because MIN( ) and MAX( ) determine the extreme values in a set, they're useful for characterizing ranges: · What date range is represented by the rows in the mail table? What are the smallest and largest messages sent? · mysql> SELECT · -> MIN(t) AS earliest, MAX(t) AS latest, · -> MIN(size) AS smallest, MAX(size) AS largest · -> FROM mail; · +---------------------+---------------------+----------+---------+ · | earliest | latest | smallest | largest | · +---------------------+---------------------+----------+---------+ · | 2001-05-11 10:15:08 | 2001-05-19 22:21:51 | 271 | 2394482 | +---------------------+---------------------+----------+---------+ · What are the shortest and longest trips in the driver_log table? · mysql> SELECT MIN(miles) AS shortest, MAX(miles) AS longest · -> FROM driver_log; · +----------+---------+ · | shortest | longest | · +----------+---------+ · | 79 | 502 | +----------+---------+ · What are the lowest and highest U.S. state populations? · mysql> SELECT MIN(pop) AS 'fewest people', MAX(pop) AS 'most people' · -> FROM states; · +---------------+-------------+ · | fewest people | most people | · +---------------+-------------+ · | 453588 | 29760021 | +---------------+-------------+ · What are the first and last state names, lexically speaking? · mysql> SELECT MIN(name), MAX(name) FROM states; · +-----------+-----------+ · | MIN(name) | MAX(name) | · +-----------+-----------+ · | Alabama | Wyoming | +-----------+-----------+ MIN( ) and MAX( ) need not be applied directly to column values. They also work with expressions or values that are derived from column values. For example, to find the lengths of the shortest and longest state names, do this: mysql> SELECT MIN(LENGTH(name)) AS shortest, MAX(LENGTH(name)) AS longest -> FROM states; +----------+---------+ | shortest | longest | +----------+---------+ | 4 | 14 | +----------+---------+ 7.4 Summarizing with SUM( ) and AVG( ) 7.4.1 Problem You need to add up a set of numbers or find their average. 7.4.2 Solution Use the SUM( ) or AVG( ) functions. 7.4.3 Discussion SUM( ) and AVG( ) produce the total and average (mean) of a set of values: · What is the total amount of mail traffic and the average size of each message? · mysql> SELECT SUM(size) AS 'total traffic', · -> AVG(size) AS 'average message size' · -> FROM mail; · +---------------+----------------------+ · | total traffic | average message size | · +---------------+----------------------+ · | 3798185 | 237386.5625 | +---------------+----------------------+ · How many miles did the drivers in the driver_log table travel? What was the average miles traveled per day? · mysql> SELECT SUM(miles) AS 'total miles', · -> AVG(miles) AS 'average miles/day' · -> FROM driver_log; · +-------------+-------------------+ · | total miles | average miles/day | · +-------------+-------------------+ · | 2166 | 216.6000 | +-------------+-------------------+ · What is the total population of the United States? · mysql> SELECT SUM(pop) FROM states; · +-----------+ · | SUM(pop) | · +-----------+ · | 248102973 | +-----------+ (The value represents the population reported for April, 1990. The figure shown here differs from the U.S. population reported by the U.S. Census Bureau, because the states table doesn't contain a count for Washington, D.C.) SUM( ) and AVG( ) are strictly numeric functions, so they can't be used with strings or temporal values. On the other hand, sometimes you can convert non-numeric values to useful numeric forms. Suppose a table stores TIME values that represent elapsed time: mysql> SELECT t1 FROM time_val; +----------+ | t1 | +----------+ | 15:00:00 | | 05:01:30 | | 12:30:20 | +----------+ To compute the total elapsed time, use TIME_TO_SEC( ) to convert the values to seconds before summing them. The result also will be in seconds; pass it to SEC_TO_TIME( ) should you wish the sum to be in TIME format: mysql> SELECT SUM(TIME_TO_SEC(t1)) AS 'total seconds', -> SEC_TO_TIME(SUM(TIME_TO_SEC(t1))) AS 'total time' -> FROM time_val; +---------------+------------+ | total seconds | total time | +---------------+------------+ | 117110 | 32:31:50 | +---------------+------------+ 7.4.4 See Also The SUM( ) and AVG( ) functions are especially useful in applications that compute statistics. They're explored further in Chapter 13, along with STD( ), a related function that calculates standard deviations. 7.5 Using DISTINCT to Eliminate Duplicates 7.5.1 Problem You want to know which values are present in a set of values, without listing duplicate values a bunch of times. Or you want to know how many distinct values there are. 7.5.2 Solution Use DISTINCT to select unique values, or COUNT(DISTINCT) to count them. 7.5.3 Discussion A summary operation that doesn't use aggregate functions is to determine which values or rows are contained in a dataset by eliminating duplicates. Do this with DISTINCT (or DISTINCTROW, which is synonymous). DISTINCT is useful for boiling down a query result, and often is combined with ORDER BY to place the values in more meaningful order. For example, if you want to know the names of the drivers listed in the driver_log table, use the following query: mysql> SELECT DISTINCT name FROM driver_log ORDER BY name; +-------+ | name | +-------+ | Ben | | Henry | | Suzi | +-------+ A query without DISTINCT produces the same names, but is not nearly as easy to understand: mysql> SELECT name FROM driver_log; +-------+ | name | +-------+ | Ben | | Suzi | | Henry | | Henry | | Ben | | Henry | | Suzi | | Henry | | Ben | | Henry | +-------+ If you want to know how many different drivers there are, use COUNT(DISTINCT): mysql> SELECT COUNT(DISTINCT name) FROM driver_log; +----------------------+ | COUNT(DISTINCT name) | +----------------------+ | 3 | +----------------------+ COUNT(DISTINCT) ignores NULL values. If you also want to count NULL as one of the values in the set if it's present, do this: COUNT(DISTINCT val) + IF(COUNT(IF(val IS NULL,1,NULL))=0,0,1) The same effect can be achieved using either of the following expressions: COUNT(DISTINCT val) + IF(SUM(ISNULL(val))=0,0,1) COUNT(DISTINCT val) + (SUM(ISNULL(val))!=0) COUNT(DISTINCT) is available as of MySQL 3.23.2. Prior to that, you have to use some kind of workaround based on counting the number of rows in a SELECT DISTINCT query. One way to do this is to select the distinct values into another table, then use COUNT(*) to count the number of rows in that table. DISTINCT queries often are useful in conjunction with aggregate functions to obtain a more complete characterization of your data. For example, applying COUNT(*) to a customer table indicates how many customers you have, using DISTINCT on the state values in the table tells you which states you have customers in, and COUNT(DISTINCT) on the state values tells you how many states your customer base represents. When used with multiple columns, DISTINCT shows the different combinations of values in the columns and COUNT(DISTINCT) counts the number of combinations. The following queries show the different sender/recipient pairs in the mail table, and how many such pairs there are: mysql> SELECT DISTINCT srcuser, dstuser FROM mail -> ORDER BY srcuser, dstuser; +---------+---------+ | srcuser | dstuser | +---------+---------+ | barb | barb | | barb | tricia | | gene | barb | | gene | gene | | gene | tricia | | phil | barb | | phil | phil | | phil | tricia | | tricia | gene | | tricia | phil | +---------+---------+ mysql> SELECT COUNT(DISTINCT srcuser, dstuser) FROM mail; +----------------------------------+ | COUNT(DISTINCT srcuser, dstuser) | +----------------------------------+ | 10 | +----------------------------------+ DISTINCT works with expressions, too, not just column values. To determine the number of hours of the day during which messages in the mail were sent, count the distinct HOUR( ) values: mysql> SELECT COUNT(DISTINCT HOUR(t)) FROM mail; +-------------------------+ | COUNT(DISTINCT HOUR(t)) | +-------------------------+ | 12 | +-------------------------+ To find out which hours those were, list them: mysql> SELECT DISTINCT HOUR(t) FROM mail ORDER BY 1; +---------+ | HOUR(t) | +---------+ | 7 | | 8 | | 9 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 17 | | 22 | | 23 | +---------+ Note that this query doesn't tell you how many messages were sent each hour. That's covered in Recipe 7.16. 7.6 Finding Values Associated with Minimum and Maximum Values 7.6.1 Problem You want to know the values for other columns in the row containing the minimum or maximum value. 7.6.2 Solution Use two queries and a SQL variable. Or use the "MAX-CONCAT trick." Or use a join. 7.6.3 Discussion MIN( ) and MAX( ) find the endpoints of a range of values, but sometimes when finding a minimum or maximum value, you're also interested in other values from the row in which the value occurs. For example, you can find the largest state population like this: mysql> SELECT MAX(pop) FROM states; +----------+ | MAX(pop) | +----------+ | 29760021 | +----------+ But that doesn't show you which state has this population. The obvious way to try to get that information is like this: mysql> SELECT name, MAX(pop) FROM states WHERE pop = MAX(pop); ERROR 1111 at line 1: Invalid use of group function Probably everyone attempts something like that sooner or later, but it doesn't work, because aggregate functions like MIN( ) and MAX( ) cannot be used in WHERE clauses. The intent of the statement is to determine which record has the maximum population value, then display the associated state name. The problem is that while you and I know perfectly well what we'd mean by writing such a thing, it makes no sense at all to MySQL. The query fails because MySQL uses the WHERE clause to determine which records to select, but it knows the value of an aggregate function only after selecting the records from which the function's value is determined! So, in a sense, the statement is self-contradictory. You could solve this problem using a subselect, except that MySQL won't have those until Version 4.1. Meanwhile, you can use a two-stage approach involving one query that selects the maximum size into a SQL variable, and another that refers to the variable in its WHERE clause: mysql> SELECT @max := MAX(pop) FROM states; mysql> SELECT @max AS 'highest population', name FROM states WHERE pop = @max; +--------------------+------------+ | highest population | name | +--------------------+------------+ | 29760021 | California | +--------------------+------------+ This technique also works even if the minimum or maximum value itself isn't actually contained in the row, but is only derived from it. If you want to know the length of the shortest verse in the King James Version, that's easy to find: mysql> SELECT MIN(LENGTH(vtext)) FROM kjv; +--------------------+ | MIN(LENGTH(vtext)) | +--------------------+ | 11 | +--------------------+ If you want to ask "What verse is that?," do this instead: mysql> SELECT @min := MIN(LENGTH(vtext)) FROM kjv; mysql> SELECT bname, cnum, vnum, vtext FROM kjv WHERE LENGTH(vtext) = @min; +-------+------+------+-------------+ | bname | cnum | vnum | vtext | +-------+------+------+-------------+ | John | 11 | 35 | Jesus wept. | +-------+------+------+-------------+ Another technique you can use for finding values associated with minima or maxima is found in the MySQL Reference Manual, where it's called the "MAX-CONCAT trick." It's pretty gruesome, but can be useful if your version of MySQL precedes the introduction of SQL variables. The technique involves appending a column to the summary column using CONCAT( ), finding the maximum of the resulting values using MAX( ), and extracting the non- summarized part of the value from the result. For example, to find the name of the state with the largest population, you can select the maximum combined value of the pop and name columns, then extract the name part from it. It's easiest to see how this works by proceeding in stages. First, determine the maximum population value to find out how wide it is: mysql> SELECT MAX(pop) FROM states; +----------+ | MAX(pop) | +----------+ | 29760021 | +----------+ That's eight characters. It's important to know this, because each column within the combined population-plus-name values should occur at a fixed position so that the state name can be extracted reliably later. (By padding the pop column to a length of eight, the name values will all begin at the ninth character.) However, we must be careful how we pad the populations. The values produced by CONCAT( ) are strings, so the population-plus-name values will be treated as such by MAX( ) for sorting purposes. If we left justify the pop values by padding them on the right with RPAD( ), we'll get combined values like the following: mysql> SELECT CONCAT(RPAD(pop,8,' '),name) FROM states; +------------------------------+ | CONCAT(RPAD(pop,8,' '),name) | +------------------------------+ | 4040587 Alabama | | 550043 Alaska | | 3665228 Arizona | | 2350725 Arkansas | ... Those values will sort lexically. That's okay for finding the largest of a set of string values with MAX( ). But pop values are numbers, so we want the values in numeric order. To make the lexical ordering correspond to the numeric ordering, we must right justify the population values by padding on the left with LPAD( ): mysql> SELECT CONCAT(LPAD(pop,8,' '),name) FROM states; +------------------------------+ | CONCAT(LPAD(pop,8,' '),name) | +------------------------------+ | 4040587Alabama | | 550043Alaska | | 3665228Arizona | | 2350725Arkansas | ... Next, use the CONCAT( ) expression with MAX( ) to find the value with the largest population part: mysql> SELECT MAX(CONCAT(LPAD(pop,8,' '),name)) FROM states; +-----------------------------------+ | MAX(CONCAT(LPAD(pop,8,' '),name)) | +-----------------------------------+ | 29760021California | +-----------------------------------+ To obtain the final result (the state name associated with the maximum population), extract from the maximum combined value the substring that begins with the ninth character: mysql> SELECT SUBSTRING(MAX(CONCAT(LPAD(pop,8,' '),name)),9) FROM states; +------------------------------------------------+ | SUBSTRING(MAX(CONCAT(LPAD(pop,8,' '),name)),9) | +------------------------------------------------+ | California | +------------------------------------------------+ Clearly, using a SQL variable to hold an intermediate result is much easier. In this case, it's also more efficient because it avoids the overhead for concatenating column values for sorting and decomposing the result for display. Yet another way to select other columns from rows containing a minimum or maximum value is to use a join. Select the value into another table, then join it to the original table to select the row that matches the value. To find the record for the state with the highest population, use a join like this: mysql> CREATE TEMPORARY TABLE t -> SELECT MAX(pop) as maxpop FROM states; mysql> SELECT states.* FROM states, t WHERE states.pop = t.maxpop; +------------+--------+------------+----------+ | name | abbrev | statehood | pop | +------------+--------+------------+----------+ | California | CA | 1850-09-09 | 29760021 | +------------+--------+------------+----------+ 7.6.4 See Also For more information about joins, see Chapter 12. 7.7 Controlling String Case Sensitivity for MIN( ) and MAX( ) 7.7.1 Problem MIN( ) and MAX( ) select strings in case sensitive fashion when you don't want them to, or vice versa. 7.7.2 Solution Alter the case sensitivity of the strings. 7.7.3 Discussion When applied to string values, MIN( ) and MAX( ) produce results determined according to lexical sorting rules. One factor in string sorting is case sensitivity, so MIN( ) and MAX( ) are affected by that as well. In Chapter 6, we used a textblob_val table containing two columns of apparently identical values: mysql> SELECT tstr, bstr FROM textblob_val; +------+------+ | tstr | bstr | +------+------+ | aaa | aaa | | AAA | AAA | | bbb | bbb | | BBB | BBB | +------+------+ However, although the values look the same, they don't behave the same. bstr is a BLOB column and is case sensitive. tstr, a TEXT column, is not. As a result, MIN( ) and MAX( ) will not necessarily produce the same results for the two columns: mysql> SELECT MIN(tstr), MIN(bstr) FROM textblob_val; +-----------+-----------+ | MIN(tstr) | MIN(bstr) | +-----------+-----------+ | aaa | AAA | +-----------+-----------+ To make tstr case sensitive, use BINARY: mysql> SELECT MIN(BINARY tstr) FROM textblob_val; +------------------+ | MIN(BINARY tstr) | +------------------+ | AAA | +------------------+ To make bstr not case sensitive, you can convert the values to a given lettercase: mysql> SELECT MIN(LOWER(bstr)) FROM textblob_val; +------------------+ | MIN(LOWER(bstr)) | +------------------+ | aaa | +------------------+ Unfortunately, doing so also changes the displayed value. If that's an issue, use this technique instead (and note that it may yield a somewhat different result): mysql> SELECT @min := MIN(LOWER(bstr)) FROM textblob_val; mysql> SELECT bstr FROM textblob_val WHERE LOWER(bstr) = @min; +------+ | bstr | +------+ | aaa | | AAA | +------+ 7.8 Dividing a Summary into Subgroups 7.8.1 Problem You want to calculate a summary for each subgroup of a set of rows, not an overall summary value. 7.8.2 Solution Use a GROUP BY clause to arrange rows into groups. 7.8.3 Discussion The summary queries shown so far calculate summary values over all rows in the result set. For example, the following query determines the number of daily driving records in the driver_log table, and thus the total number of days that drivers were on the road: mysql> SELECT COUNT(*) FROM driver_log; +----------+ | COUNT(*) | +----------+ | 10 | +----------+ But sometimes it's desirable to break a set of rows into subgroups and summarize each group. This is done by using aggregate functions in conjunction with a GROUP BY clause. To determine the number of days driven by each driver, group the rows by driver name, count how many rows there are for each name, and display the names with the counts: mysql> SELECT name, COUNT(name) FROM driver_log GROUP BY name; +-------+-------------+ | name | COUNT(name) | +-------+-------------+ | Ben | 3 | | Henry | 5 | | Suzi | 2 | +-------+-------------+ That query summarizes the same column used for grouping (name), but that's not always necessary. Suppose you want a quick characterization of the driver_log table, showing for each person listed in it the total number of miles driven and the average number of miles per day. In this case, you still use the name column to place the rows in groups, but the summary functions operate on the miles values: mysql> SELECT name, -> SUM(miles) AS 'total miles', -> AVG(miles) AS 'miles per day' -> FROM driver_log GROUP BY name; +-------+-------------+---------------+ | name | total miles | miles per day | +-------+-------------+---------------+ | Ben | 362 | 120.6667 | | Henry | 911 | 182.2000 | | Suzi | 893 | 446.5000 | +-------+-------------+---------------+ Use as many grouping columns as necessary to achieve as fine-grained a summary as you require. The following query produces a coarse summary showing how many messages were sent by each message sender listed in the mail table: mysql> SELECT srcuser, COUNT(*) FROM mail -> GROUP BY srcuser; +---------+----------+ | srcuser | COUNT(*) | +---------+----------+ | barb | 3 | | gene | 6 | | phil | 5 | | tricia | 2 | +---------+----------+ To be more specific and find out how many messages each sender sent from each host, use two grouping columns. This produces a result with nested groups (groups within groups): mysql> SELECT srcuser, srchost, COUNT(*) FROM mail -> GROUP BY srcuser, srchost; +---------+---------+----------+ | srcuser | srchost | COUNT(*) | +---------+---------+----------+ | barb | saturn | 2 | | barb | venus | 1 | | gene | mars | 2 | | gene | saturn | 2 | | gene | venus | 2 | | phil | mars | 3 | | phil | venus | 2 | | tricia | mars | 1 | | tricia | saturn | 1 | +---------+---------+----------+ Getting Distinct Values Without Using DISTINCT If you use GROUP BY without selecting the value of any aggregate functions, you achieve the same effect as DISTINCT without using DISTINCT explicitly: mysql> SELECT name FROM driver_log GROUP BY name; +-------+ | name | +-------+ | Ben | | Henry | | Suzi | +-------+ Normally with this kind of query you'd select a summary value (for example, by invoking COUNT(name) to count the instances of each name), but it's legal not to. The net effect is to produce a list of the unique grouped values. I prefer to use DISTINCT, because it makes the point of the query more obvious. (Internally, MySQL actually maps the DISTINCT form of the query onto the GROUP BY form.) The preceding examples in this section have used COUNT( ), SUM( ) and AVG( ) for per- group summaries. You can use MIN( ) or MAX( ), too. With a GROUP BY clause, they will tell you the smallest or largest value per group. The following query groups mail table rows by message sender, displaying for each one the size of the largest message sent and the date of the most recent message: mysql> SELECT srcuser, MAX(size), MAX(t) FROM mail GROUP BY srcuser; +---------+-----------+---------------------+ | srcuser | MAX(size) | MAX(t) | +---------+-----------+---------------------+ | barb | 98151 | 2001-05-14 14:42:21 | | gene | 998532 | 2001-05-19 22:21:51 | | phil | 10294 | 2001-05-17 12:49:23 | | tricia | 2394482 | 2001-05-14 17:03:01 | +---------+-----------+---------------------+ You can group by multiple columns and display a maximum for each combination of values in those columns. This query finds the size of the largest message sent between each pair of sender and recipient values listed in the mail table: mysql> SELECT srcuser, dstuser, MAX(size) FROM mail GROUP BY srcuser, dstuser; +---------+---------+-----------+ | srcuser | dstuser | MAX(size) | +---------+---------+-----------+ | barb | barb | 98151 | | barb | tricia | 58274 | | gene | barb | 2291 | | gene | gene | 23992 | | gene | tricia | 998532 | | phil | barb | 10294 | | phil | phil | 1048 | | phil | tricia | 5781 | | tricia | gene | 194925 | | tricia | phil | 2394482 | +---------+---------+-----------+ When using aggregate functions to produce per-group summary values, watch out for the following trap. Suppose you want to know the longest trip per driver in the driver_log table. That's produced by this query: mysql> SELECT name, MAX(miles) AS 'longest trip' -> FROM driver_log GROUP BY name; +-------+--------------+ | name | longest trip | +-------+--------------+ | Ben | 152 | | Henry | 300 | | Suzi | 502 | +-------+--------------+ But what if you also want to show the date on which each driver's longest trip occurred? Can you just add trav_date to the output column list? Sorry, that won't work: mysql> SELECT name, trav_date, MAX(miles) AS 'longest trip' -> FROM driver_log GROUP BY name; +-------+------------+--------------+ | name | trav_date | longest trip | +-------+------------+--------------+ | Ben | 2001-11-30 | 152 | | Henry | 2001-11-29 | 300 | | Suzi | 2001-11-29 | 502 | +-------+------------+--------------+ The query does produce a result, but if you compare it to the full table (shown below), you'll see that although the dates for Ben and Henry are correct, the date for Suzi is not: +--------+-------+------------+-------+ | rec_id | name | trav_date | miles | +--------+-------+------------+-------+ | 1 | Ben | 2001-11-30 | 152 | <-- Ben's longest trip | 2 | Suzi | 2001-11-29 | 391 | | 3 | Henry | 2001-11-29 | 300 | <-- Henry's longest trip | 4 | Henry | 2001-11-27 | 96 | | 5 | Ben | 2001-11-29 | 131 | | 6 | Henry | 2001-11-26 | 115 | | 7 | Suzi | 2001-12-02 | 502 | <-- Suzi's longest trip | 8 | Henry | 2001-12-01 | 197 | | 9 | Ben | 2001-12-02 | 79 | | 10 | Henry | 2001-11-30 | 203 | +--------+-------+------------+-------+ So what's going on? Why does the summary query produce incorrect results? This happens because when you include a GROUP BY clause in a query, the only values you can select are the grouped columns or the summary values calculated from them. If you display additional columns, they're not tied to the grouped columns and the values displayed for them are indeterminate. (For the query just shown, it appears that MySQL may simply be picking the first date for each driver, whether or not it matches the driver's maximum mileage value.) The general solution to the problem of displaying contents of rows associated with minimum or maximum group values involves a join. The technique is described in Chapter 12. If you don't want to read ahead, or you don't want to use another table, consider using the MAX-CONCAT trick described earlier. It produces the correct result, although the query is fairly ugly: mysql> SELECT name, -> SUBSTRING(MAX(CONCAT(LPAD(miles,3,' '), trav_date)),4) AS date, -> LEFT(MAX(CONCAT(LPAD(miles,3,' '), trav_date)),3) AS 'longest trip' -> FROM driver_log GROUP BY name; +-------+------------+--------------+ | name | date | longest trip | +-------+------------+--------------+ | Ben | 2001-11-30 | 152 | | Henry | 2001-11-29 | 300 | | Suzi | 2001-12-02 | 502 | +-------+------------+--------------+ 7.9 Summaries and NULL Values 7.9.1 Problem You're summarizing a set of values that may include NULL values and you need to know how to interpret the results. 7.9.2 Solution Understand how aggregate functions handle NULL values. 7.9.3 Discussion Most aggregate functions ignore NULL values. Suppose you have a table expt that records experimental results for subjects who are to be given four tests each and that lists the test score as NULL for those tests that have not yet been administered: mysql> SELECT subject, test, score FROM expt ORDER BY subject, test; +---------+------+-------+ | subject | test | score | +---------+------+-------+ | Jane | A | 47 | | Jane | B | 50 | | Jane | C | NULL | | Jane | D | NULL | | Marvin | A | 52 | | Marvin | B | 45 | | Marvin | C | 53 | | Marvin | D | NULL | +---------+------+-------+ By using a GROUP BY clause to arrange the rows by subject name, the number of tests taken by each subject, as well as the total, average, lowest, and highest score can be calculated like this, mysql> SELECT subject, -> COUNT(score) AS n, -> SUM(score) AS total, -> AVG(score) AS average, -> MIN(score) AS lowest, -> MAX(score) AS highest -> FROM expt GROUP BY subject; +---------+---+-------+---------+--------+---------+ | subject | n | total | average | lowest | highest | +---------+---+-------+---------+--------+---------+ | Jane | 2 | 97 | 48.5000 | 47 | 50 | | Marvin | 3 | 150 | 50.0000 | 45 | 53 | +---------+---+-------+---------+--------+---------+ You can see from results in the column labeled n (number of tests) that the query counts only five values. Why? Because the values in that column correspond to the number of non-NULL test scores for each subject. The other summary columns display results that are calculated only from the non-NULL scores as well. It makes a lot of sense for aggregate functions to ignore NULL values. If they followed the usual SQL arithmetic rules, adding NULL to any other value would produce a NULL result. That would make aggregate functions really difficult to use because you'd have to filter out NULL values yourself every time you performed a summary to avoid getting a NULL result. Ugh. By ignoring NULL values, aggregate functions become a lot more convenient. However, be aware that even though aggregate functions may ignore NULL values, some of them can still produce NULL as a result. This happens if there's nothing to summarize. The following query is the same as the previous one, with one small difference. It selects only NULL test scores, so there's nothing for the aggregate functions to operate on: mysql> SELECT subject, -> COUNT(score) AS n, -> SUM(score) AS total, -> AVG(score) AS average, -> MIN(score) AS lowest, -> MAX(score) AS highest -> FROM expt WHERE score IS NULL GROUP BY subject; +---------+---+-------+---------+--------+---------+ | subject | n | total | average | lowest | highest | +---------+---+-------+---------+--------+---------+ | Jane | 0 | 0 | NULL | NULL | NULL | | Marvin | 0 | 0 | NULL | NULL | NULL | +---------+---+-------+---------+--------+---------+ Even under these circumstances, the summary functions still return the most sensible value. The number of scores and total score per subject each are zero and are reported that way. AVG( ), on the other hand, returns NULL. An average is a ratio, calculated as a sum of values divided by the number of values. When there aren't any values to summarize, the ratio is 0/0, which is undefined. NULL is therefore the most reasonable result for AVG( ) to return. Similarly, MIN( ) and MAX( ) have nothing to work with, so they return NULL. If you don't want these functions to produce NULL in the query output, use IFNULL( ) to map their results appropriately: mysql> SELECT subject, -> COUNT(score) AS n, -> SUM(score) AS total, -> IFNULL(AVG(score),0) AS average, -> IFNULL(MIN(score),'Unknown') AS lowest, -> IFNULL(MAX(score),'Unknown') AS highest -> FROM expt WHERE score IS NULL GROUP BY subject; +---------+---+-------+---------+---------+---------+ | subject | n | total | average | lowest | highest | +---------+---+-------+---------+---------+---------+ | Jane | 0 | 0 | 0 | Unknown | Unknown | | Marvin | 0 | 0 | 0 | Unknown | Unknown | +---------+---+-------+---------+---------+---------+ COUNT( ) is somewhat different with regard to NULL values than the other aggregate functions. Like other aggregate functions, COUNT(expr) counts only non-NULL values, but COUNT(*) counts rows, regardless of their content. You can see the difference between the forms of COUNT( ) like this: mysql> SELECT COUNT(*), COUNT(score) FROM expt; +----------+--------------+ | COUNT(*) | COUNT(score) | +----------+--------------+ | 8 | 5 | +----------+--------------+ This tells us that there are eight rows in the expt table but that only five of them have the score value filled in. The different forms of COUNT( ) can be very useful for counting missing values; just take the difference: mysql> SELECT COUNT(*) - COUNT(score) AS missing FROM expt; +---------+ | missing | +---------+ | 3 | +---------+ Missing and non-missing counts can be determined for subgroups as well. The following query does so for each subject. This provides a quick way to assess the extent to which the experiment has been completed: mysql> SELECT subject, -> COUNT(*) AS total, -> COUNT(score) AS 'non-missing', -> COUNT(*) - COUNT(score) AS missing -> FROM expt GROUP BY subject; +---------+-------+-------------+---------+ | subject | total | non-missing | missing | +---------+-------+-------------+---------+ | Jane | 4 | 2 | 2 | | Marvin | 4 | 3 | 1 | +---------+-------+-------------+---------+ 7.10 Selecting Only Groups with Certain Characteristics 7.10.1 Problem You want to calculate group summaries, but display the results only for those groups that match certain criteria. 7.10.2 Solution Use a HAVING clause. 7.10.3 Discussion You're familiar with the use of WHERE to specify conditions that individual records must satisfy to be selected by a query. It's natural, therefore, to use WHERE to write conditions that involve summary values. The only trouble is that it doesn't work. If you want to identify drivers in the driver_log table who drove more than three days, you'd probably first think to write the query like this: mysql> SELECT COUNT(*), name -> FROM driver_log -> WHERE COUNT(*) > 3 -> GROUP BY name; ERROR 1111 at line 1: Invalid use of group function The problem here is that WHERE specifies the initial constraints that determine which rows to select, but the value of COUNT( ) can be determined only after the rows have been selected. The solution is to put the COUNT( ) expression in a HAVING clause instead. HAVING is analogous to WHERE, but it applies to group characteristics rather than to single records. That is, HAVING operates on the already-selected-and-grouped set of rows, applying additional constraints based on aggregate function results that aren't known during the initial selection process. The preceding query therefore should be written like this: mysql> SELECT COUNT(*), name -> FROM driver_log -> GROUP BY name -> HAVING COUNT(*) > 3; +----------+-------+ | COUNT(*) | name | +----------+-------+ | 5 | Henry | +----------+-------+ When you use HAVING, you can still include a WHERE clause—but only to select rows, not to test summary values. HAVING can refer to aliases, so the previous query can be rewritten like this: mysql> SELECT COUNT(*) AS count, name -> FROM driver_log -> GROUP BY name -> HAVING count > 3; +-------+-------+ | count | name | +-------+-------+ | 5 | Henry | +-------+-------+ 7.11 Determining Whether Values are Unique 7.11.1 Problem You want to know whether table values are unique. 7.11.2 Solution Use HAVING in conjunction with COUNT( ). 7.11.3 Discussion You can use HAVING to find unique values in situations to which DISTINCT does not apply. DISTINCT eliminates duplicates, but doesn't show which values actually were duplicated in the original data. HAVING can tell you which values were unique or non-unique. The following queries show the days on which only one driver was active, and the days on which more than one driver was active. They're based on using HAVING and COUNT( ) to determine which trav_date values are unique or non-unique: mysql> SELECT trav_date, COUNT(trav_date) -> FROM driver_log -> GROUP BY trav_date -> HAVING COUNT(trav_date) = 1; +------------+------------------+ | trav_date | COUNT(trav_date) | +------------+------------------+ | 2001-11-26 | 1 | | 2001-11-27 | 1 | | 2001-12-01 | 1 | +------------+------------------+ mysql> SELECT trav_date, COUNT(trav_date) -> FROM driver_log -> GROUP BY trav_date -> HAVING COUNT(trav_date) > 1; +------------+------------------+ | trav_date | COUNT(trav_date) | +------------+------------------+ | 2001-11-29 | 3 | | 2001-11-30 | 2 | | 2001-12-02 | 2 | +------------+------------------+ This technique works for combinations of values, too. For example, to find message sender/recipient pairs between whom only one message was sent, look for combinations that occur only once in the mail table: mysql> SELECT srcuser, dstuser -> FROM mail -> GROUP BY srcuser, dstuser -> HAVING COUNT(*) = 1; +---------+---------+ | srcuser | dstuser | +---------+---------+ | barb | barb | | gene | tricia | | phil | barb | | tricia | gene | | tricia | phil | +---------+---------+ Note that this query doesn't print the count. The first two examples did so, to show that the counts were being used properly, but you can use a count in a HAVING clause without including it in the output column list. 7.12 Grouping by Expression Results 7.12.1 Problem You want to group rows into subgroups based on values calculated from an expression. 7.12.2 Solution Put the expression in the GROUP BY clause. For older versions of MySQL that don't support GROUP BY expressions, use a workaround. 7.12.3 Discussion GROUP BY shares the property with ORDER BY that as of MySQL 3.23.2 it can refer to expressions. This means you can use calculations as the basis for grouping. For example, to find the distribution of the length of state names, group by LENGTH(name): mysql> SELECT LENGTH(name), COUNT(*) -> FROM states GROUP BY LENGTH(name); +--------------+----------+ | LENGTH(name) | COUNT(*) | +--------------+----------+ | 4 | 3 | | 5 | 3 | | 6 | 5 | | 7 | 8 | | 8 | 12 | | 9 | 4 | | 10 | 4 | | 11 | 2 | | 12 | 4 | | 13 | 3 | | 14 | 2 | +--------------+----------+ Prior to MySQL 3.23.2, you cannot use expressions in GROUP BY clauses, so the preceding query would fail. In Recipe 6.4, workarounds for this problem were given with regard to ORDER BY, and the same methods apply to GROUP BY. One workaround is to give the expression an alias in the output column list and refer to the alias in the GROUP BY clause: mysql> SELECT LENGTH(name) AS len, COUNT(*) -> FROM states GROUP BY len; +------+----------+ | len | COUNT(*) | +------+----------+ | 4 | 3 | | 5 | 3 | | 6 | 5 | | 7 | 8 | | 8 | 12 | | 9 | 4 | | 10 | 4 | | 11 | 2 | | 12 | 4 | | 13 | 3 | | 14 | 2 | +------+----------+ Another is to write the GROUP BY clause to refer to the output column position: mysql> SELECT LENGTH(name), COUNT(*) -> FROM states GROUP BY 1; +--------------+----------+ | LENGTH(name) | COUNT(*) | +--------------+----------+ | 4 | 3 | | 5 | 3 | | 6 | 5 | | 7 | 8 | | 8 | 12 | | 9 | 4 | | 10 | 4 | | 11 | 2 | | 12 | 4 | | 13 | 3 | | 14 | 2 | +--------------+----------+ Of course, these alternative ways of writing the query work in MySQL 3.23.2 and up as well— and you may find them more readable. You can group by multiple expressions if you like. To find days of the year on which more than one state joined the Union, group by statehood month and day, then use HAVING and COUNT( ) to find the non-unique combinations: mysql> SELECT MONTHNAME(statehood), DAYOFMONTH(statehood), COUNT(*) -> FROM states GROUP BY 1, 2 HAVING COUNT(*) > 1; +----------------------+-----------------------+----------+ | MONTHNAME(statehood) | DAYOFMONTH(statehood) | COUNT(*) | +----------------------+-----------------------+----------+ | February | 14 | 2 | | June | 1 | 2 | | March | 1 | 2 | | May | 29 | 2 | | November | 2 | 2 | +----------------------+-----------------------+----------+ 7.13 Categorizing Non-Categorical Data 7.13.1 Problem You need to perform a summary on a set of values that are mostly unique and do not categorize well. 7.13.2 Solution Use an expression to group the values into categories. 7.13.3 Discussion One important application for grouping by expression results is to provide categories for values that are not particularly categorical. This is useful because GROUP BY works best for columns with repetitive values. For example, you might attempt to perform a population analysis by grouping records in the states table using values in the pop column. As it happens, that would not work very well, due to the high number of distinct values in the column. In fact, they're all distinct, as the following query shows: mysql> SELECT COUNT(pop), COUNT(DISTINCT pop) FROM states; +------------+---------------------+ | COUNT(pop) | COUNT(DISTINCT pop) | +------------+---------------------+ | 50 | 50 | +------------+---------------------+ In situations like this, where values do not group nicely into a small number of sets, you can use a transformation that forces them into categories. First, determine the population range: mysql> SELECT MIN(pop), MAX(pop) FROM states; +----------+----------+ | MIN(pop) | MAX(pop) | +----------+----------+ | 453588 | 29760021 | +----------+----------+ We can see from that result that if we divide the pop values by five million, they'll group into six categories—a reasonable number. (The category ranges will be 1 to 5,000,000; 5,000,001 to 10,000,000; and so forth.) To put each population value in the proper category, divide by five million and use the integer result: mysql> SELECT FLOOR(pop/5000000) AS 'population (millions)', -> COUNT(*) AS 'number of states' -> FROM states GROUP BY 1; +-----------------------+------------------+ | population (millions) | number of states | +-----------------------+------------------+ | 0 | 35 | | 1 | 8 | | 2 | 4 | | 3 | 2 | | 5 | 1 | +-----------------------+------------------+ Hm. That's not quite right. The expression groups the population values into a small number of categories, all right, but doesn't report the category values properly. Let's try multiplying the FLOOR( ) results by five: mysql> SELECT FLOOR(pop/5000000)*5 AS 'population (millions)', -> COUNT(*) AS 'number of states' -> FROM states GROUP BY 1; +-----------------------+------------------+ | population (millions) | number of states | +-----------------------+------------------+ | 0 | 35 | | 5 | 8 | | 10 | 4 | | 15 | 2 | | 25 | 1 | +-----------------------+------------------+ Hey, that still isn't correct! The maximum state population was 29,760,021, which should go into a category for 30 million, not one for 25 million. The problem is that the category- producing expression groups values toward the lower bound of each category. To group values toward the upper bound instead, use the following little trick. For categories of size n, you can place a value x into the proper category using the following expression: FLOOR((x+(n-1))/n) So the final form of our query looks like this: mysql> SELECT FLOOR((pop+4999999)/5000000)*5 AS 'population (millions)', -> COUNT(*) AS 'number of states' -> FROM states GROUP BY 1; +-----------------------+------------------+ | population (millions) | number of states | +-----------------------+------------------+ | 5 | 35 | | 10 | 8 | | 15 | 4 | | 20 | 2 | | 30 | 1 | +-----------------------+------------------+ The result shows clearly that the majority of U.S. states have a population of five million or less. This technique works for all kinds of numeric values. For example, you can group mail table records into categories of 100,000 bytes as follows: mysql> SELECT FLOOR((size+99999)/100000) AS 'size (100KB)', -> COUNT(*) AS 'number of messages' -> FROM mail GROUP BY 1; +--------------+--------------------+ | size (100KB) | number of messages | +--------------+--------------------+ | 1 | 13 | | 2 | 1 | | 10 | 1 | | 24 | 1 | +--------------+--------------------+ In some instances, it may be more appropriate to categorize groups on a logarithmic scale. For example, the state population values can be treated that way as follows: mysql> SELECT FLOOR(LOG10(pop)) AS 'log10(population)', -> COUNT(*) AS 'number of states' -> FROM states GROUP BY 1; +-------------------+------------------+ | log10(population) | number of states | +-------------------+------------------+ | 5 | 7 | | 6 | 36 | | 7 | 7 | +-------------------+------------------+ How Repetitive Is a Set of Values? To assess how much repetition is present in a set of values, use the ratio of COUNT(DISTINCT) and COUNT( ). If all values are unique, both counts will be the same and the ratio will be 1. This is the case for the t values in the mail table and the pop values in the states table: mysql> SELECT COUNT(DISTINCT t) / COUNT(t) FROM mail; +------------------------------+ | COUNT(DISTINCT t) / COUNT(t) | +------------------------------+ | 1.00 | +------------------------------+ mysql> SELECT COUNT(DISTINCT pop) / COUNT(pop) FROM states; +----------------------------------+ | COUNT(DISTINCT pop) / COUNT(pop) | +----------------------------------+ | 1.00 | +----------------------------------+ For a more repetitive set of values, COUNT(DISTINCT) will be less than COUNT( ) and the ratio will be smaller: mysql> SELECT COUNT(DISTINCT name) / COUNT(name) FROM driver_log; +------------------------------------+ | COUNT(DISTINCT name) / COUNT(name) | +------------------------------------+ | 0.30 | +------------------------------------+ What's the practical use for this ratio? A result close to zero indicates a high degree of repetition, which means the values will group into a small number of categories naturally. A result of 1 or close to it indicates many unique values, with the consequence that GROUP BY won't be very efficient for grouping the values into categories. (That is, there will be a lot of categories, relative to the number of values.) This tells you that to generate a summary, you'll probably find it necessary to impose an artificial categorization on the values, using the techniques described in this section. 7.14 Controlling Summary Display Order 7.14.1 Problem You want to sort the result of a summary query. 7.14.2 Solution Use an ORDER BY clause—if GROUP BY doesn't produce the desired sort order. 7.14.3 Discussion In MySQL, GROUP BY not only groups, it sorts. Thus there is often no need for an ORDER BY clause in a summary query. But you can still use ORDER BY if you want a sort order other than the one that GROUP BY produces by default. For example, to determine the number of days driven and total miles for each person in the driver_log table, run this query: mysql> SELECT name, COUNT(*) AS days, SUM(miles) AS mileage -> FROM driver_log GROUP BY name; +-------+------+-------------+ | name | days | total miles | +-------+------+-------------+ | Ben | 3 | 362 | | Henry | 5 | 911 | | Suzi | 2 | 893 | +-------+------+-------------+ But that sorts by the names. If you want to sort drivers according to who drove the most days or miles, add the appropriate ORDER BY clause: mysql> SELECT name, COUNT(*) AS days, SUM(miles) AS mileage -> FROM driver_log GROUP BY name -> ORDER BY days DESC; +-------+------+---------+ | name | days | mileage | +-------+------+---------+ | Henry | 5 | 911 | | Ben | 3 | 362 | | Suzi | 2 | 893 | +-------+------+---------+ mysql> SELECT name, COUNT(*) AS days, SUM(miles) AS mileage -> FROM driver_log GROUP BY name -> ORDER BY mileage DESC; +-------+------+---------+ | name | days | mileage | +-------+------+---------+ | Henry | 5 | 911 | | Suzi | 2 | 893 | | Ben | 3 | 362 | +-------+------+---------+ It's necessary to use an alias (or a column position number) in the ORDER BY clause to refer to the summary values. This is true even for MySQL 3.23.2 and up, which normally allows expressions in an ORDER BY clause; those expressions must refer to individual values, not values computed from a set. Sometimes you can reorder a summary without an ORDER BY clause by choosing an appropriate GROUP BY expression. For example, if you count how many states joined the Union on each day of the week, grouped by day name, the results will be sorted in lexical order: mysql> SELECT DAYNAME(statehood), COUNT(*) FROM states -> GROUP BY DAYNAME(statehood); +--------------------+----------+ | DAYNAME(statehood) | COUNT(*) | +--------------------+----------+ | Friday | 8 | | Monday | 9 | | Saturday | 11 | | Thursday | 5 | | Tuesday | 6 | | Wednesday | 11 | +--------------------+----------+ From this you can see that no state entered the Union on a Sunday, but that becomes apparent only after you stare at the query result for a while. The output would be more easily understood were it sorted into day-of-week order. It's possible to do that by adding an explicit ORDER BY to sort on the numeric day-of-week value, but another way to achieve the same result without ORDER BY is to group by DAYOFWEEK( ) rather than by DAYNAME( ): mysql> SELECT DAYNAME(statehood), COUNT(*) -> FROM states GROUP BY DAYOFWEEK(statehood); +--------------------+----------+ | DAYNAME(statehood) | COUNT(*) | +--------------------+----------+ | Monday | 9 | | Tuesday | 6 | | Wednesday | 11 | | Thursday | 5 | | Friday | 8 | | Saturday | 11 | +--------------------+----------+ GROUP BY may not sort output rows in other database systems. To write queries for MySQL that are less likely to need revision when used with other databases, you may find it beneficial to add an explicit ORDER BY clause in all cases. 7.15 Finding Smallest or Largest Summary Values 7.15.1 Problem You want to compute per-group summary values, but display only the smallest or largest of them. 7.15.2 Solution Add a LIMIT clause to the query. 7.15.3 Discussion MIN( ) and MAX( ) find the values at the endpoints of a range of values, but if you want to know the extremes of a set of summary values, those functions won't work. The arguments to MIN( ) and MAX( ) cannot be other aggregate functions. For example, you can easily find per-driver mileage totals: mysql> SELECT name, SUM(miles) -> FROM driver_log -> GROUP BY name; +-------+------------+ | name | SUM(miles) | +-------+------------+ | Ben | 362 | | Henry | 911 | | Suzi | 893 | +-------+------------+ But to select only the record for the driver with the most miles, this doesn't work: mysql> SELECT name, SUM(miles) -> FROM driver_log -> GROUP BY name -> HAVING SUM(miles) = MAX(SUM(name)); ERROR 1111 at line 1: Invalid use of group function Instead, order the rows with the largest SUM( ) values first and use LIMIT to select the first record: mysql> SELECT name, SUM(miles) AS 'total miles' -> FROM driver_log -> GROUP BY name -> ORDER BY 'total miles' DESC LIMIT 1; +-------+-------------+ | name | total miles | +-------+-------------+ | Henry | 911 | +-------+-------------+ An alias is used in the ORDER BY clause because ORDER BY cannot refer directly to aggregate functions, as discussed earlier in Recipe 7.14. Note that if there is more than one row with the given summary value, this type of query won't tell you that. For example, you might attempt to ascertain the most common initial letter for state names like this: mysql> SELECT LEFT(name,1) AS letter, COUNT(*) AS count FROM states -> GROUP BY letter ORDER BY count DESC LIMIT 1; +--------+-------+ | letter | count | +--------+-------+ | M | 8 | +--------+-------+ But eight state names also begin with N. If you need to know all most-frequent values when there may be more than one of them, a two-query approach will be more useful: mysql> SELECT LEFT(name,1) AS letter, @max:=COUNT(*) AS count FROM states -> GROUP BY letter ORDER BY count DESC LIMIT 1; mysql> SELECT LEFT(name,1) AS letter, COUNT(*) AS count FROM states -> GROUP BY letter HAVING count = @max; +--------+-------+ | letter | count | +--------+-------+ | M | 8 | | N | 8 | +--------+-------+ 7.16 Date-Based Summaries 7.16.1 Problem You want to produce a summary based on date or time values. 7.16.2 Solution Use GROUP BY to categorize temporal values into bins of the appropriate duration. Often this will involve using expressions to extract the significant parts of dates or times. 7.16.3 Discussion To put records in time order, you use an ORDER BY clause to sort a column that has a temporal type. If instead you want to summarize records based on groupings into time intervals, you need to determine how to categorize each record into the proper interval and use GROUP BY to group them accordingly. Sometimes you can use temporal values directly if they group naturally into the desired categories. This is quite likely if a table represents date or time parts using separate columns. For example, the baseball1.com master ballplayer table represents birth dates using separate year, month, and day columns. To see how many ballplayers were born on each day of the year, perform a calendar date summary that uses the month and day values but ignores the year: mysql> SELECT birthmonth, birthday, COUNT(*) -> FROM master -> WHERE birthmonth IS NOT NULL AND birthday IS NOT NULL -> GROUP BY birthmonth, birthday; +------------+----------+----------+ | birthmonth | birthday | COUNT(*) | +------------+----------+----------+ | 1 | 1 | 47 | | 1 | 2 | 40 | | 1 | 3 | 50 | | 1 | 4 | 38 | ... | 12 | 28 | 33 | | 12 | 29 | 32 | | 12 | 30 | 32 | | 12 | 31 | 27 | +------------+----------+----------+ A less fine-grained summary can be obtained by using only the month values: mysql> SELECT birthmonth, COUNT(*) -> FROM master -> WHERE birthmonth IS NOT NULL -> GROUP BY birthmonth; +------------+----------+ | birthmonth | COUNT(*) | +------------+----------+ | 1 | 1311 | | 2 | 1144 | | 3 | 1243 | | 4 | 1179 | | 5 | 1118 | | 6 | 1105 | | 7 | 1244 | | 8 | 1438 | | 9 | 1314 | | 10 | 1438 | | 11 | 1314 | | 12 | 1269 | +------------+----------+ Sometimes temporal values can be used directly, even when not represented as separate columns. To determine how many drivers were on the road and how many miles were driven each day, group the records in the driver_log table by date: mysql> SELECT trav_date, -> COUNT(*) AS 'number of drivers', SUM(miles) As 'miles logged' -> FROM driver_log GROUP BY trav_date; +------------+-------------------+--------------+ | trav_date | number of drivers | miles logged | +------------+-------------------+--------------+ | 2001-11-26 | 1 | 115 | | 2001-11-27 | 1 | 96 | | 2001-11-29 | 3 | 822 | | 2001-11-30 | 2 | 355 | | 2001-12-01 | 1 | 197 | | 2001-12-02 | 2 | 581 | +------------+-------------------+--------------+ However, this summary will grow lengthier as you add more records to the table. At some point, the number of distinct dates likely will become so large that the summary fails to be useful, and you'd probably decide to change the category size from daily to weekly or monthly. When a temporal column contains so many distinct values that it fails to categorize well, it's typical for a summary to group records using expressions that map the relevant parts of the date or time values onto a smaller set of categories. For example, to produce a time-of-day summary for records in the mail table, do this:[1] [1] Note that the result includes an entry only for hours of the day actually represented in the data. To generate a summary with an entry for every hour, use a join to fill in the "missing" values. See Recipe 12.10. mysql> SELECT HOUR(t) AS hour, -> COUNT(*) AS 'number of messages', -> SUM(size) AS 'number of bytes sent' -> FROM mail -> GROUP BY hour; +------+--------------------+----------------------+ | hour | number of messages | number of bytes sent | +------+--------------------+----------------------+ | 7 | 1 | 3824 | | 8 | 1 | 978 | | 9 | 2 | 2904 | | 10 | 2 | 1056806 | | 11 | 1 | 5781 | | 12 | 2 | 195798 | | 13 | 1 | 271 | | 14 | 1 | 98151 | | 15 | 1 | 1048 | | 17 | 2 | 2398338 | | 22 | 1 | 23992 | | 23 | 1 | 10294 | +------+--------------------+----------------------+ To produce a day-of-week summary instead, use the DAYOFWEEK( ) function: mysql> SELECT DAYOFWEEK(t) AS weekday, -> COUNT(*) AS 'number of messages', -> SUM(size) AS 'number of bytes sent' -> FROM mail -> GROUP BY weekday; +---------+--------------------+----------------------+ | weekday | number of messages | number of bytes sent | +---------+--------------------+----------------------+ | 1 | 1 | 271 | | 2 | 4 | 2500705 | | 3 | 4 | 1007190 | | 4 | 2 | 10907 | | 5 | 1 | 873 | | 6 | 1 | 58274 | | 7 | 3 | 219965 | +---------+--------------------+----------------------+ To make the output more meaningful, you might want to use DAYNAME( ) to display weekday names instead. However, because day names sort lexically (for example, "Tuesday" sorts after "Friday"), use DAYNAME( ) only for display purposes. Continue to group on the numeric day values so that output rows sort that way: mysql> SELECT DAYNAME(t) AS weekday, -> COUNT(*) AS 'number of messages', -> SUM(size) AS 'number of bytes sent' -> FROM mail -> GROUP BY DAYOFWEEK(t); +-----------+--------------------+----------------------+ | weekday | number of messages | number of bytes sent | +-----------+--------------------+----------------------+ | Sunday | 1 | 271 | | Monday | 4 | 2500705 | | Tuesday | 4 | 1007190 | | Wednesday | 2 | 10907 | | Thursday | 1 | 873 | | Friday | 1 | 58274 | | Saturday | 3 | 219965 | +-----------+--------------------+----------------------+ A similar technique can be used for summarizing month-of-year categories that are sorted by numeric value but displayed by month name. Uses for temporal categorizations are plentiful: · DATETIME or TIMESTAMP columns have the potential to contain many unique values. To produce daily summaries, strip off the time of day part to collapse all values occurring within a given day to the same value. Any of the following GROUP BY clauses will do this, though the last one is likely to be slowest: · GROUP BY FROM_DAYS(TO_DAYS(col_name)) · GROUP BY YEAR(col_name), MONTH(col_name), DAYOFMONTH(col_name) GROUP BY DATE_FORMAT(col_name,'%Y-%m-%e') · To produce monthly or quarterly sales reports, group by MONTH(col_name) or QUARTER(col_name) to place dates into the correct part of the year. · To summarize web server activity, put your server's logs into MySQL and run queries that collapse the records into different time categories. Chapter 18 discusses how to do this for Apache. 7.17 Working with Per-Group and Overall Summary Values Simultaneously 7.17.1 Problem You want to produce a report that requires different levels of summary detail. Or you want to compare per-group summary values to an overall summary value. 7.17.2 Solution Use two queries that retrieve different levels of summary information. Or use a programming language to do some of the work so that you can use a single query. 7.17.3 Discussion Sometimes a report involves different levels of summary information. For example, the following report displays the total number of miles per driver from the driver_log table, along with each driver's miles as a percentage of the total miles in the entire table: +-------+--------------+------------------------+ | name | miles/driver | percent of total miles | +-------+--------------+------------------------+ | Ben | 362 | 16.712834718375 | | Henry | 911 | 42.059095106187 | | Suzi | 893 | 41.228070175439 | +-------+--------------+------------------------+ The percentages represent the ratio of each driver's miles to the total miles for all drivers. To perform the percentage calculation, you need a per-group summary to get each driver's miles and also an overall summary to get the total miles. Generating the report in SQL involves a couple of queries, because you can't calculate a per-group summary and an overall summary in a single query.[2] First, run a query to get the overall mileage total: [2] Well... that's not strictly true. With a subselect, you could generate the summary with a single query. But MySQL won't have subselects until Version 4.1. mysql> SELECT @total := SUM(miles) AS 'total miles' FROM driver_log; +-------------+ | total miles | +-------------+ | 2166 | +-------------+ Then calculate the per-group values and use the overall total to compute the percentages: mysql> SELECT name, -> SUM(miles) AS 'miles/driver', -> (SUM(miles)*100)/@total AS 'percent of total miles' -> FROM driver_log GROUP BY name; +-------+--------------+------------------------+ | name | miles/driver | percent of total miles | +-------+--------------+------------------------+ | Ben | 362 | 16.712834718375 | | Henry | 911 | 42.059095106187 | | Suzi | 893 | 41.228070175439 | +-------+--------------+------------------------+ A different form of multiple-query solution that doesn't involve a variable is to retrieve the overall summary into another table, then join that with the original table: mysql> CREATE TEMPORARY TABLE t -> SELECT SUM(miles) AS total FROM driver_log; mysql> SELECT driver_log.name, -> SUM(driver_log.miles) AS 'miles/driver', -> (SUM(driver_log.miles)*100)/t.total AS 'percent of total miles' -> FROM driver_log, t GROUP BY driver_log.name; +-------+--------------+------------------------+ | name | miles/driver | percent of total miles | +-------+--------------+------------------------+ | Ben | 362 | 16.71 | | Henry | 911 | 42.06 | | Suzi | 893 | 41.23 | +-------+--------------+------------------------+ If you're generating the report from within a program, you can do some of the summary math using your programming language and eliminate one of the queries. Here's an example in Python: # issue query to calculate per-driver totals cursor = conn.cursor ( ) cursor.execute ("SELECT name, SUM(miles) FROM driver_log GROUP BY name") rows = cursor.fetchall ( ) cursor.close ( ) # iterate once through result to calculate overall total miles total = 0 for (name, miles) in rows: total = total + miles # iterate again to print report print "name miles/driver percent of total miles" for (name, miles) in rows: print "%-8s %5d %f" \ % (name, miles, (100*miles)/total) Another type of problem that uses different levels of summary information occurs when you want to compare per-group summary values with the corresponding overall summary value. Suppose you want to determine which drivers had a lower average miles per day than the group average. Using only SQL, this task can't be performed with a single query, but you can easily do it with two. First, calculate the overall average and save it in a variable: mysql> SELECT @overall_avg := AVG(miles) FROM driver_log; +----------------------------+ | @overall_avg := AVG(miles) | +----------------------------+ | 216.6000 | +----------------------------+ Then compare each driver's average to the saved value using a HAVING clause: mysql> SELECT name, AVG(miles) AS driver_avg FROM driver_log -> GROUP BY name -> HAVING driver_avg < @overall_avg; +-------+------------+ | name | driver_avg | +-------+------------+ | Ben | 120.6667 | | Henry | 182.2000 | +-------+------------+ Just as when producing a report that uses different levels of summary information, you can solve this problem without using two queries if you're writing a program by using your programming language to do some of the work: 1. Issue a query to retrieve the per-group summary information. 2. Iterate through the result set once to calculate the overall summary value. 3. Iterate through the result set again, comparing each per-group summary value to the overall value and displaying only those records for which the comparison succeeds. 7.18 Generating a Report That Includes a Summary and a List 7.18.1 Problem You want to write a query that displays a summary, together with the list of records associated with each summary value. 7.18.2 Solution Recognize that this is a variant on working with different levels of summary information, and solve the problem using the same techniques. 7.18.3 Discussion Suppose you want to produce a report that looks like this: Name: Ben; days on road: 3; miles driven: 362 date: 2001-11-29, trip length: 131 date: 2001-11-30, trip length: 152 date: 2001-12-02, trip length: 79 Name: Henry; days on road: 5; miles driven: 911 date: 2001-11-26, trip length: 115 date: 2001-11-27, trip length: 96 date: 2001-11-29, trip length: 300 date: 2001-11-30, trip length: 203 date: 2001-12-01, trip length: 197 Name: Suzi; days on road: 2; miles driven: 893 date: 2001-11-29, trip length: 391 date: 2001-12-02, trip length: 502 The report shows, for each driver in the driver_log table, the following information: · A summary line showing the driver name, the number of days on the road, and the number of miles driven. · A list of the dates and mileages for the individual trips from which the summary values are calculated. This scenario is a variation on the "different levels of summary information" problem discussed in the previous recipe. It may not seem like it at first, because one of the types of information is a list rather than a summary. But that's really just a "level zero" summary. This kind of problem appears in many other forms: · You have a database that lists contributions to candidates in your political party. The party chair requests a printout that shows, for each candidate, the number of contributions and total amount contributed, as well as a list of contributor names and addresses. · You want to make a handout for a company presentation that summarizes total sales per sales region, with a list under each region showing the sales for each state in the region. In each case, the solutions are like those discussed in the previous recipe: · Run separate queries to get the information for each level of detail that you require. (Just as a single query won't produce per-group summary values and an overall summary value at the same time, neither will one query produce per-group summary values and a list of each group's individual records.) · Fetch the rows that make up the lists and perform the summary calculations yourself to eliminate the summary query. Let's use each approach to produce the driver report shown at the beginning of this section. The following implementation (in Python) generates the report using one query to summarize the days and miles per driver, and another to fetch the individual trip records for each driver: # select total miles per driver and construct a dictionary that # maps each driver name to days on the road and miles driven name_map = { } cursor = conn.cursor ( ) cursor.execute (""" SELECT name, COUNT(name), SUM(miles) FROM driver_log GROUP BY name """) for (name, days, miles) in cursor.fetchall ( ): name_map[name] = (days, miles) # select trips for each driver and print the report, displaying the # summary entry for each driver prior to the list of trips cursor.execute (""" SELECT name, trav_date, miles FROM driver_log ORDER BY name, trav_date """) cur_name = "" for (name, trav_date, miles) in cursor.fetchall ( ): if cur_name != name: # new driver; print driver's summary info print "Name: %s; days on road: %d; miles driven: %d" \ % (name, name_map[name][0], name_map[name][1]) cur_name = name print " date: %s, trip length: %d" % (trav_date, miles) cursor.close ( ) By performing summary calculations in the program, you can reduce the number of queries required. If you iterate through the trip list and calculate the per-driver day counts and mileage totals yourself, a single query suffices: # get list of trips for the drivers cursor = conn.cursor ( ) cursor.execute (""" SELECT name, trav_date, miles FROM driver_log ORDER BY name, trav_date """) rows = cursor.fetchall ( ) cursor.close ( ) # iterate through rows once to construct a dictionary that # maps each driver name to days on the road and miles driven # (the dictionary entries are lists rather than tuples because # we need mutable values that can be modified in the loop) name_map = { } for (name, trav_date, miles) in rows: if not name_map.has_key (name): # initialize entry if nonexistent name_map[name] = [0, 0] name_map[name][0] = name_map[name][0] + 1 # count days name_map[name][1] = name_map[name][1] + miles # sum miles # iterate through rows again to print the report, displaying the # summary entry for each driver prior to the list of trips cur_name = "" for (name, trav_date, miles) in rows: if cur_name != name: # new driver; print driver's summary info print "Name: %s; days on road: %d; miles driven: %d" \ % (name, name_map[name][0], name_map[name][1]) cur_name = name print " date: %s, trip length: %d" % (trav_date, miles) Should you require more levels of summary information, this type of problem gets more difficult. For example, you might want the report showing driver summaries and trip logs to be preceded by a line that shows the total miles for all drivers: Total miles driven by all drivers combined: 2166 Name: Ben; days on road: 3; miles driven: 362 date: 2001-11-29, trip length: 131 date: 2001-11-30, trip length: 152 date: 2001-12-02, trip length: 79 Name: Henry; days on road: 5; miles driven: 911 date: 2001-11-26, trip length: 115 date: 2001-11-27, trip length: 96 date: 2001-11-29, trip length: 300 date: 2001-11-30, trip length: 203 date: 2001-12-01, trip length: 197 Name: Suzi; days on road: 2; miles driven: 893 date: 2001-11-29, trip length: 391 date: 2001-12-02, trip length: 502 In this case, you need either another query to produce the total mileage, or another calculation in your program that computes the overall total. Chapter 8. Modifying Tables with ALTER TABLE Introduction Dropping, Adding, or Repositioning a Column Changing a Column Definition or Name The Effect of ALTER TABLE on Null and Default Value Attributes Changing a Column's Default Value Changing a Table Type Renaming a Table Adding or Dropping Indexes Eliminating Duplicates by Adding an Index Using ALTER TABLE to Normalize a Table 8.1 Introduction You'll probably find it necessary on occasion to redesign some of your tables. A change in an application's specification may require that you record information not accounted for in the original definition of a table used by that application. Or you may find that an AUTO_INCREMENT column is running out of room to generate new sequence numbers and you need to change the column to use a larger integer type. MySQL offers many possibilities for modifying a table's structure. This chapter describes how to make the following types of changes: · Dropping, adding, or repositioning a column. Columns that have become unnecessary or that you discover to be redundant may be removed to simplify a table and to save space. Or you may move columns from one table to another as part of a normalization procedure. Columns may be added when you need to record additional types of information. · Changing a column definition or name. If a column as originally created does not serve your purposes, you may be able to correct the problem by redefining it. For example, you can convert a string column that is case sensitive to one that is not, or vice versa. Or you may have an AUTO_INCREMENT column that is a TINYINT and has room only for 127 sequence values. By changing the column to be unsigned or to use a larger integer type, you can extend the range of the sequence. Renaming a column can be useful if after an upgrade to a more recent version of MySQL you find that a column name is now a reserved word. Or maybe you just want to rename a column like num to something more descriptive like test_score to make the column's purpose more explicit. · Changing a table's type. The various table types in MySQL have differing characteristics. If a table's type is less suitable for your applications than another type, you can convert it. · Renaming a table. Like renaming a column, this can be done if you come up with a better name. Or you can rename for other purposes such as rotating the names of a set of tables used for logging. · Modifying a table's index structure Dropping an index that is rarely used can improve performance of inserts and updates of table rows, because that index then need not be updated. Adding an index to a column that you reference frequently in queries can be useful for improving SELECT performance. Indexing can also be used to remove duplicate values from a table. Most of these operations are handled by ALTER TABLE, one of MySQL's most powerful but least appreciated statements. By that I mean you can do a lot with ALTER TABLE, but many MySQL users do not fully exploit its capabilities. Perhaps this is because the ALTER TABLE statement has so many options that its syntax is somewhat daunting. I hope that this chapter will demystify the statement and make its utility more apparent. Before you begin reading the rest of this chapter, create the following table for use in working through the examples: CREATE TABLE mytbl ( i INT, c CHAR(1) ); As you make each of the modifications shown in the following sections, you can see the resulting changes in this table's structure, either by issuing a SHOW COLUMNS FROM mytbl statement or a SHOW CREATE TABLE mytbl statement. For example, after you create mytbl, SHOW COLUMNS should display the following information: mysql> SHOW COLUMNS FROM mytbl; +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | i | int(11) | YES | | NULL | | | c | char(1) | YES | | NULL | | +-------+---------+------+-----+---------+-------+ Observe that MySQL automatically assigns default values and determines whether the columns can contain NULL values, even though the CREATE TABLE statement does not explicitly specify these attributes. The significance of this is discussed in Recipe 8.4. 8.2 Dropping, Adding, or Repositioning a Column 8.2.1 Problem You want to get rid of a table column, add a new column, or move a column around within a table. 8.2.2 Solution Use the DROP or ADD clauses of ALTER TABLE to remove or add a column. To move a column, drop it and then put it back where you want it. 8.2.3 Discussion To remove a column from a table, use DROP followed by the column name. This statement drops the i column, leaving only the c column in mytbl: ALTER TABLE mytbl DROP i; DROP will not work if the column is the only one left in the table. (To verify this, try to drop the c column from mytbl after dropping the i column; an error will occur.) To add a column, use ADD and specify the column definition. The following statement restores the i column to mytbl: ALTER TABLE mytbl ADD i INT; After issuing this statement, mytbl will contain the same two columns that it had when you first created the table, but will not have quite the same structure. That's because new columns are added to the end of the table by default. So even though i originally was the first column in mytbl, now it is the last one: mysql> SHOW COLUMNS FROM mytbl; +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | c | char(1) | YES | | NULL | | | i | int(11) | YES | | NULL | | +-------+---------+------+-----+---------+-------+ To indicate that you want a column at a specific position within the table, either use FIRST to make it the first column, or AFTER col_name to indicate that the new column should be placed after col_name. Try the following ALTER TABLE statements, using SHOW COLUMNS after each one to see what effect each one has: ALTER TABLE mytbl DROP i; ALTER TABLE mytbl ADD i INT FIRST; ALTER TABLE mytbl DROP i; ALTER TABLE mytbl ADD i INT AFTER c; The FIRST and AFTER specifiers work only with the ADD clause. This means that if you want to reposition an existing column within a table, you first must DROP it and then ADD it at the new position. Column Repositioning and TIMESTAMP Columns Be careful if you reposition columns in a table that contains more than one TIMESTAMP column. The first TIMESTAMP column has special properties not shared by the others. (See Recipe 5.32, which describes the differences.) If you change the order of the TIMESTAMP columns, you'll change the way your table behaves. 8.3 Changing a Column Definition or Name 8.3.1 Problem You want to change how a column is defined. 8.3.2 Solution Use MODIFY or CHANGE. MODIFY is simpler, but cannot change the column name. CHANGE is more confusing to use, but can change both the name and the definition. 8.3.3 Discussion To change a column's definition, use MODIFY or CHANGE.[1] Of the two, MODIFY has the simpler syntax: name the column, then specify its new definition. For example, to change column c from CHAR(1) to CHAR(10), do this: [1] MODIFY requires MySQL 3.22.16 or later. ALTER TABLE mytbl MODIFY c CHAR(10); With CHANGE, the syntax is a bit different. After the CHANGE keyword, you name the column you want to change, then specify the new definition, which includes the new name. The second column name is required, because CHANGE also allows you to rename the column, not just change its definition. For example, to change i from INT to BIGINT and rename it to j at the same time, the statement looks like this: ALTER TABLE mytbl CHANGE i j BIGINT; If you now use CHANGE to convert j from BIGINT back to INT without changing the column name, the statement may look a bit odd: ALTER TABLE mytbl CHANGE j j INT; At first glance, the statement seems incorrect—the column name appears to be given one too many times. However, it's correct as written. The fact that the CHANGE syntax requires two column names (even if they're both the same) is simply something you have to get used to. This is especially important to remember if your version of MySQL is old enough that you can't use MODIFY. Any ALTER TABLE statement that uses MODIFY col_name can be replaced by one that uses CHANGE col_name col_name. That is, the following two statements are equivalent: ALTER TABLE tbl_name MODIFY col_name ... ; ALTER TABLE tbl_name CHANGE col_name col_name ... ; It would be nice to have a form of the ALTER TABLE statement that renamed a column without the need to repeat the definition, especially for working with ENUM and SET columns that have many member values. Unfortunately, there is no such statement, which makes these column types somewhat difficult to work with when using ALTER TABLE. Suppose you add to mytbl an ENUM column e that has several members: ALTER TABLE mytbl ADD e ENUM('hardware','software','books','office supplies', 'telecommunications','furniture','utilities', 'shipping','tax'); If you want to rename the column from e to e2, you use CHANGE to indicate the new name. But you must also repeat the column definition as well: ALTER TABLE mytbl CHANGE e e2 ENUM('hardware','software','books','office supplies', 'telecommunications','furniture','utilities', 'shipping','tax'); Ugh. That's too much typing. Manually entering the proper ALTER TABLE statement for this kind of operation is quite a lot of work, not to mention error-prone. One way to avoid retyping the definition is to capture the current definition in a file and edit the file to produce the proper ALTER TABLE statement: · Run mysqldump to get the CREATE TABLE statement that contains the column definition: % mysqldump --no-data cookbook mytbl > test.txt The resulting file, test.txt, should contain this statement: CREATE TABLE mytbl ( c char(10) default NULL, j bigint(20) NOT NULL default '100', e enum('hardware','software','books','office supplies','telecommunications', 'furniture','utilities','shipping','tax') default NULL ) TYPE=MyISAM; The --no-data option tells mysqldump not to dump the data from the table; it's used here because only the table creation statement is needed. · Edit the test.txt file to remove everything but the definition for the e column: · e enum('hardware','software','books','office supplies','telecommunications', 'furniture','utilities','shipping','tax') default NULL · Modify the definition to produce an ALTER TABLE statement with a semicolon at the end: · ALTER TABLE mytbl CHANGE e e2 · enum('hardware','software','books','office supplies','telecommunications', 'furniture','utilities','shipping','tax') default NULL; · Write test.txt back out to save it, then get out of the editor and feed test.txt as a batch file to mysql: % mysql cookbook < test.txt For simple columns, this procedure is more work than just typing the ALTER TABLE statement manually, of course. But for ENUM and SET columns with long and ungainly definitions, using an editor to create a mysql batch file from mysqldump output makes a lot of sense. You can also use this technique to make it easier to reorder the items in an ENUM or SET column, or to add or delete members from the column definition. For another approach to column manipulation, see Recipe 9.9, which develops a utility script that makes it trivial to add member values. The script examines the table structure and uses that information to figure out the proper ALTER TABLE statement for modifying an ENUM or SET column. 8.4 The Effect of ALTER TABLE on Null and Default Value Attributes 8.4.1 Problem You changed a column definition, but MySQL modified the column's NULL value and default value attributes when you didn't tell it to. 8.4.2 Solution Those attributes are part of the column definition. If you don't specify them explicitly, MySQL chooses their values for you. So just be more specific about how you want the column defined. 8.4.3 Discussion When you MODIFY or CHANGE a column, you can also specify whether or not the column can contain NULL values, and what its default value is. In fact, if you don't do this, MySQL automatically assigns values for these attributes, with the result that the column may end up defined not quite the way you intend. To see this, try the following sequence of commands. First, modify j so that it cannot contain NULL values and to have a default value of 100, then see what SHOW COLUMNS tells you:[2] [2] The LIKE 'str' clause for SHOW COLUMNS causes the statement to show information only for columns having names that match the string. The string can contain SQL pattern characters if you want it to match several column names. See Recipe 9.6. mysql> ALTER TABLE mytbl MODIFY j INT NOT NULL DEFAULT 100; mysql> SHOW COLUMNS FROM mytbl LIKE 'j'; +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | j | int(11) | | | 100 | | +-------+---------+------+-----+---------+-------+ So far, so good. Now if you were to decide to change j from INT to BIGINT, you might try the following statement: mysql> ALTER TABLE mytbl MODIFY j BIGINT; However, that also undoes the NULL and DEFAULT specifications of the previous ALTER TABLE statement: mysql> SHOW COLUMNS FROM mytbl LIKE 'j'; +-------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------+------+-----+---------+-------+ | j | bigint(20) | YES | | NULL | | +-------+------------+------+-----+---------+-------+ To avoid this, the MODIFY statement should specify the null and default value attributes explicitly: mysql> ALTER TABLE mytbl MODIFY j BIGINT NOT NULL DEFAULT 100; mysql> SHOW COLUMNS FROM mytbl LIKE 'j'; +-------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------+------+-----+---------+-------+ | j | bigint(20) | | | 100 | | +-------+------------+------+-----+---------+-------+ The implication of this exercise is that if a column is defined such that its null and default value attributes are not what MySQL would assign automatically, you must specify them explicitly in your ALTER TABLE statement if you don't want them to change when you modify some other aspect of the column definition. This fact is important for some of the recipes shown in Chapter 9, such as one program that converts a table to use VARCHAR rather than CHAR columns, and another that adds new elements to ENUM or SET columns. In each case, the programs take care to avoid unintended column changes by including NULL and DEFAULT specifiers in the ALTER TABLE statements that they generate. 8.5 Changing a Column's Default Value 8.5.1 Problem You want to leave a column definition alone except for the default value. 8.5.2 Solution Use SET DEFAULT to specify the default value explicitly, or DROP DEFAULT to remove the current default and allow MySQL to assign the "default default." 8.5.3 Discussion A column's default value is part of its definition, but can be modified separately from other aspects of the definition. To change a default value, use ALTER col_name SET DEFAULT: ALTER TABLE mytbl ALTER j SET DEFAULT 1000; Default values must be constants. For example, you cannot set the default for a date-valued column to NOW( ), although that would be very useful. To drop a default value, use ALTER col_name DROP DEFAULT: ALTER TABLE mytbl ALTER j DROP DEFAULT; In this case, the column's default value reverts to the standard default for the column type. For columns that can contain NULL values, this will be NULL. Otherwise, the general defaults are 0, the empty string, or the "zero" date or time for numeric, string, or date or time columns, respectively. (The exceptions are for AUTO_INCREMENT, ENUM, and TIMESTAMP columns, for which the defaults are the next sequence number, the first enumeration member, and the current date and time.) 8.6 Changing a Table Type 8.6.1 Problem A table has one type, and now you realize that another table type has properties that are more desirable for the way you use the table. 8.6.2 Solution Use ALTER TABLE to change its type with a TYPE clause. 8.6.3 Discussion MySQL supports several tables types, each of which have differing characteristics. Sometimes it's necessary or desirable to convert a table from one type to another. Some situations where a change of table type can be useful are as follows: · Table conversions sometimes are done to gain access to features that are supported by one table type but not another. For example, ISAM tables do not allow NULL values in indexed columns. Also, AUTO_INCREMENT behavior in ISAM tables is such that sequence values may be non-monotonic under certain conditions. (See Chapter 11, for information about this.) You can convert an ISAM table to the MyISAM type, which does not suffer from these problems. Or you might find that you need to perform transactions on a table created using a type that doesn't provide transactional capabilities. To handle this problem, you can alter the table to a type such as InnoDB or BDB that does support transactions. · The oldest table type supported by MySQL is ISAM, but ISAM tables are deprecated and at some point no longer will be supported. If you have ISAM tables, you should convert them at some point to another table type. Otherwise, after ISAM support is dropped, you'll be unable to upgrade to new releases of MySQL. Changing a table type is easy; use ALTER TABLE with a TYPE specifier. For example, to convert a table to the MyISAM type, use this statement: ALTER TABLE tbl_name TYPE = MYISAM; To find out the current type of a table, use the SHOW TABLE STATUS statement (introduced in MySQL 3.23.0) or SHOW CREATE TABLE (introduced in MySQL 3.23.20): mysql> SHOW TABLE STATUS LIKE 'mytbl'\G *************************** 1. row *************************** Name: mytbl Type: MyISAM Row_format: Fixed Rows: 0 Avg_row_length: 0 Data_length: 0 Max_data_length: 85899345919 Index_length: 1024 Data_free: 0 Auto_increment: NULL Create_time: 2002-07-15 21:28:34 Update_time: 2002-07-15 21:28:34 Check_time: NULL Create_options: Comment: mysql> SHOW CREATE TABLE mytbl\G *************************** 1. row *************************** Table: mytbl Create Table: CREATE TABLE `mytbl` ( `c` char(10) default NULL, `j` bigint(20) default NULL, `e2` enum('hardware','software','books','office supplies', 'telecommunications','furniture','utilities','shipping','tax') default NULL ) TYPE=MyISAM Alternatively, use the mysqldump command-line utility: % mysqldump --no-data cookbook mytbl CREATE TABLE mytbl ( c char(10) default NULL, j bigint(20) default NULL, e2 enum('hardware','software','books','office supplies', 'telecommunications','furniture','utilities','shipping','tax') default NULL ) TYPE=MyISAM; 8.7 Renaming a Table 8.7.1 Problem A table needs to be renamed. 8.7.2 Solution You can use ALTER TABLE or RENAME TABLE for this. 8.7.3 Discussion To rename a table, use the RENAME option of the ALTER TABLE statement: ALTER TABLE old_name RENAME TO new_name; As of Version 3.23.23, MySQL includes an explicit RENAME TABLE statement: RENAME TABLE old_name TO new_name; RENAME TABLE allows you to rename multiple tables, which allows you to do things such as swap the names of two tables in a single statement: RENAME TABLE name1 TO temp_name, name2 TO name1, tmp_name to name2; You can achieve the same result with ALTER TABLE, except that you need three separate statements. Because of that, the tables become available to other clients in the brief intervals between statements, which may be undesirable. Using a single RENAME TABLE statement avoids this problem. RENAME TABLE is also useful for rotating tables. To do this without having an interval in which the log table is unavailable to clients, create an empty version under a temporary name, then rotate the files using a single RENAME TABLE statement. For example, if you want to keep monthly log tables, named using the year and month, you might do something like this: CREATE TABLE log_temp (...); RENAME TABLE log TO log_2001_05, log_temp TO log; To rotate log tables to keep a set of daily tables covering the last week, you could run the following statements daily: CREATE TABLE log_temp (...); DROP TABLE IF exists log_7; RENAME TABLE log_6 TO log_7, log_5 TO log_6, log_4 TO log_5, log_3 TO log_4, log_2 TO log_3, log_1 TO log_2, log TO log_1, log_tmp TO log; 8.8 Adding or Dropping Indexes 8.8.1 Problem Table lookups are slow. Or INSERTS and UPDATES are slow. 8.8.2 Solution ALTER TABLE can not only drop or add columns, it can drop or add indexes on those columns. These operations often are useful for improving the performance of a database. Typically, indexing a column that you query frequently helps SELECT statements run faster because the index allows MySQL to avoid full table scans. Dropping indexes can sometimes be useful as well. Whenever a row is modified, MySQL must update any indexes that include the modified columns. If you don't actually use a particular index very much, it's possible that your table is overindexed and that dropping the index will speed up performance of table updates. 8.8.3 Discussion For the discussion in this section, it's useful to begin again with a new copy of the mytbl example table. Use DROP TABLE and CREATE TABLE to remove the existing version and recreate it in its original form: DROP TABLE mytbl; CREATE TABLE mytbl ( i INT, c CHAR(1) ); In earlier sections of this chapter, SHOW COLUMNS was used to see the effect of table modifications. For index-changing operations, use SHOW INDEX rather than SHOW COLUMNS. Currently, the table has no indexes, because none were specified in the CREATE TABLE statement: mysql> SHOW INDEX FROM mytbl; Empty set (0.00 sec) 8.8.4 Adding Indexes There are four types of statements for adding indexes to a table: ALTER TABLE tbl_name ADD PRIMARY KEY (column_list); ALTER TABLE tbl_name ADD UNIQUE index_name (column_list); ALTER TABLE tbl_name ADD INDEX index_name (column_list); ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list); The first statement adds a PRIMARY KEY, which means that indexed values must be unique and cannot be NULL. The second creates an index for which values must be unique (with the exception of NULL values, which may appear multiple times). The third adds an ordinary index in which any value may appear more than once. The fourth creates a special FULLTEXT index that is used for text-searching purposes. FULLTEXT searches are discussed in more detail in Recipe 4.12. For those statements that include index_name in the syntax, the index name is optional. If you don't specify a name, MySQL assigns one automatically. column_list indicates which columns to index; it should be a list of one or more column names separated by commas. As simple examples, the first of the following statements creates a single-column index on c, and the second creates a multiple-column index that includes both c and i: ALTER TABLE mytbl ADD INDEX (c); ALTER TABLE mytbl ADD INDEX (c,i); In many cases, indexed columns must be declared NOT NULL. For example, if you create mytbl as an ISAM table type, the preceding ADD INDEX statements will fail because ISAM tables do not allow NULL in any kind of index. And no matter what the table type, columns in a PRIMARY KEY cannot contain NULL values. If you try to add an index and MySQL issues a NULL-related complaint, use ALTER TABLE to change the relevant column or columns to NOT NULL and then try adding the index again. For example, if you try to make column i a PRIMARY KEY as follows, an error results: mysql> ALTER TABLE mytbl ADD PRIMARY KEY (i); ERROR 1171 at line 5: All parts of a PRIMARY KEY must be NOT NULL; If you need NULL in a key, use UNIQUE instead To deal with this, redefine i to be NOT NULL, then try again: mysql> ALTER TABLE mytbl MODIFY i INT NOT NULL; mysql> ALTER TABLE mytbl ADD PRIMARY KEY (i); Alternatively, as the error message indicates, you can create a UNIQUE index rather than a PRIMARY KEY should you wish to allow NULL values in the index. 8.8.5 Dropping Indexes To drop an index, use one of the following statements: ALTER TABLE tbl_name DROP PRIMARY KEY; ALTER TABLE tbl_name DROP INDEX index_name; Dropping a PRIMARY KEY is easiest, because you need not know the index name: ALTER TABLE mytbl DROP PRIMARY KEY; To drop an index that is not a PRIMARY KEY, you must specify the index name. If you don't know the name, use SHOW INDEX. Vertical-format output (specified by \G) often is useful with this statement, to avoid long line wraparound: mysql> SHOW INDEX FROM mytbl\G *************************** 1. row *************************** Table: mytbl Non_unique: 1 Key_name: c Seq_in_index: 1 Column_name: c Collation: A Cardinality: NULL Sub_part: NULL Packed: NULL Comment: *************************** 2. row *************************** Table: mytbl Non_unique: 1 Key_name: c_2 Seq_in_index: 1 Column_name: c Collation: A Cardinality: NULL Sub_part: NULL Packed: NULL Comment: *************************** 3. row *************************** Table: mytbl Non_unique: 1 Key_name: c_2 Seq_in_index: 2 Column_name: i Collation: A Cardinality: NULL Sub_part: NULL Packed: NULL Comment: The Key_name and Seq_in_index values show the index names and the positions of columns within an index. Those values indicate in the preceding output that mytbl has a single-column index named c and a multiple-column index named c_2. (These are the names that MySQL chose for the first two indexes created earlier.) The statement to drop the indexes looks like this: ALTER TABLE mytbl DROP INDEX c, DROP INDEX c_2; This statement illustrates that you can perform multiple actions with a single ALTER TABLE statement, if you separate the actions by commas. 8.8.6 See Also An alternative to ALTER TABLE for modifying indexes is to use the CREATE INDEX and DROP INDEX statements. Internally, MySQL maps these onto ALTER TABLE statements, so there's nothing you can do with them that you can't do with ALTER TABLE. See the MySQL Reference Manual for more information. 8.9 Eliminating Duplicates by Adding an Index 8.9.1 Problem A table has duplicates and you'd like to get rid of them. 8.9.2 Solution One way to do this is to create a unique index on the column or columns containing duplicates. 8.9.3 Discussion If MySQL discovers duplicate key values when you try to create a PRIMARY KEY or a UNIQUE index, it aborts the ALTER TABLE operation. To ignore the duplicates and proceed anyway, use ALTER IGNORE TABLE rather than ALTER TABLE. The IGNORE keyword tells MySQL to retain the first row containing a duplicated key value and discard the others. This is, in fact, a useful way to eliminate duplicates in a column or set of columns: just create a unique-valued index and let MySQL throw away the duplicates. (If you need to identify which key values are duplicated, though, that's not a suitable technique. See Recipe 14.4 for information on duplicate identification.) To see how IGNORE works to eliminate duplicates, use mytbl, which now has no indexes if you've issued the index-modification statements shown earlier. First, insert some duplicate values into the table: mysql> INSERT INTO mytbl (i,c) VALUES(1,'a'),(1,'a'),(1,NULL),(1,NULL), -> (2,'a'),(2,'a'),(2,'b'),(2,'b'); mysql> SELECT * FROM mytbl; +---+------+ | i | c | +---+------+ | 1 | a | | 1 | a | | 1 | NULL | | 1 | NULL | | 2 | a | | 2 | a | | 2 | b | | 2 | b | +---+------+ Now suppose you want to create a unique-valued index comprising the i and c columns. A PRIMARY KEY cannot be used here, because c contains NULL values. You can create a UNIQUE index, but if you try to do so without using IGNORE, you'll get an error: mysql> ALTER TABLE mytbl ADD UNIQUE (i,c); ERROR 1062 at line 1: Duplicate entry '1-a' for key 1 Add IGNORE to the statement, then use SELECT to have a look at the table contents to see how the duplicates have been removed: mysql> ALTER IGNORE TABLE mytbl ADD UNIQUE (i,c); mysql> SELECT * FROM mytbl; +---+------+ | i | c | +---+------+ | 1 | NULL | | 1 | NULL | | 1 | a | | 2 | a | | 2 | b | +---+------+ The output shows that duplicate records have been eliminated—except those that contain NULL in the key values. That's because UNIQUE indexes allow multiple NULL values. For another technique that removes even duplicates that contain NULLs, see Recipe 14.7. 8.10 Using ALTER TABLE to Normalize a Table 8.10.1 Problem You have a table that's not in normal form. 8.10.2 Solution ALTER TABLE can help you normalize it. 8.10.3 Discussion The preceding sections describe how to use ALTER TABLE in fairly general terms. This section shows a more concrete application of the statement by demonstrating how ALTER TABLE can help you redesign tables that you discover to contain unnecessarily redundant data and therefore to be in non-normal form. Suppose you have a client_billing table for recording billable items that is defined as follows: CREATE TABLE client_billing ( id INT UNSIGNED NOT NULL, # client ID number name CHAR(20) NOT NULL, # client name address CHAR(20) NOT NULL, # client adddress date DATE NOT NULL, # billable item date minutes INT NOT NULL, # number of billable minutes description CHAR(60) NOT NULL # what was done ); When you have just one row of information per client, the table looks perfectly fine: +----+------+---------------+------------+---------+------------------+ | id | name | address | date | minutes | description | +----+------+---------------+------------+---------+------------------+ | 21 | John | 46 North Ave. | 2001-07-15 | 48 | consult by phone | | 43 | Toby | 123 Elm St. | 2001-07-13 | 12 | office visit | +----+------+---------------+------------+---------+------------------+ But when you add more records and have multiple rows per client, it becomes apparent that some of the information is redundant. In particular, names and addresses are stored in every record, even though you really need that information only once for any given client: +----+------+---------------+------------+---------+------------------+ | id | name | address | date | minutes | description | +----+------+---------------+------------+---------+------------------+ | 21 | John | 46 North Ave. | 2001-07-15 | 48 | consult by phone | | 21 | John | 46 North Ave. | 2001-07-19 | 120 | court appearance | | 43 | Toby | 123 Elm St. | 2001-07-13 | 12 | office visit | | 43 | Toby | 123 Elm St. | 2001-07-14 | 60 | draft proposal | | 43 | Toby | 123 Elm St. | 2001-07-16 | 180 | present proposal | +----+------+---------------+------------+---------+------------------+ The way to fix the problem is to split the information into two tables and associate the records in them using the id values: · One table (client_info) holds the information that is unique to each client, one row per client: the ID, name, and address. · The other table (bill_item) holds information about each billable item: date, number of minutes, and the description of what was done. Each row also should include the client ID number so that the item can be associated with the proper client_info table record. In other words, the client information from the client_billing table can be separated as follows into the client_info and bill_item tables: client_info table: +----+------+---------------+ | id | name | address | +----+------+---------------+ | 21 | John | 46 North Ave. | | 43 | Toby | 123 Elm St. | +----+------+---------------+ bill_item table: +----+------------+---------+------------------+ | id | date | minutes | description | +----+------------+---------+------------------+ | 21 | 2001-07-15 | 48 | consult by phone | | 21 | 2001-07-19 | 120 | court appearance | | 43 | 2001-07-13 | 12 | office visit | | 43 | 2001-07-14 | 60 | draft proposal | | 43 | 2001-07-16 | 180 | present proposal | +----+------------+---------+------------------+ To accomplish this redesign, first create the client_info and bill_item tables using the following statements, where each table's columns are defined the same way as the corresponding columns from the original client_billing table: CREATE TABLE client_info ( id INT UNSIGNED NOT NULL, # client ID number name CHAR(20) NOT NULL, # client name address CHAR(20) NOT NULL # client adddress ); CREATE TABLE bill_item ( id INT UNSIGNED NOT NULL, # client ID number date DATE NOT NULL, # billable item date minutes INT NOT NULL, # number of billable minutes description CHAR(60) NOT NULL # what was done ); Next, use INSERT INTO ... SELECT to copy the appropriate columns from the client_billing table into the two new tables. For the client_info table, the client information can be copied like this: INSERT INTO client_info (id,name,address) SELECT id,name,address FROM client_billing; Copying information to the bill_item table is similar: INSERT INTO bill_item (id,date,minutes,description) SELECT id,date,minutes,description FROM client_billing; Records in the two new tables are associated based on id values, so it's a good idea to index that column in each table to allow them to be related efficiently. However, that's not simply a matter of issuing an ALTER TABLE tbl_name ADD INDEX (id) statement for each table. For one thing, the client_info table at this point has multiple records per client that should be collapsed down to a single record for each client. That means we should create a PRIMARY KEY or UNIQUE index on the id column, using the IGNORE keyword to tell MySQL to discard duplicate records. In addition, queries on the bill_item table are likely often to be date- based, so we can include the date column in the index. ALTER TABLE statements to create these indexes look like this: ALTER IGNORE TABLE client_info ADD PRIMARY KEY (id); ALTER TABLE bill_item ADD INDEX (id, date); After performing the procedure just described, the client_billing table no longer is needed and can be removed: DROP TABLE client_billing; With billing records stored in multiple tables, queries to retrieve information become somewhat more complex, but relating tables is what relational databases are good at, after all. For example, to show the client name and address from the client_info table along with a sum of the billable minutes listed per client in the bill_item table, the query looks like this: mysql> SELECT client_info.id, client_info.name, client_info.address, -> SUM(bill_item.minutes) AS 'total minutes' -> FROM client_info, bill_item -> WHERE client_info.id = bill_item.id -> GROUP BY client_info.id; +----+------+---------------+---------------+ | id | name | address | total minutes | +----+------+---------------+---------------+ | 21 | John | 46 North Ave. | 168 | | 43 | Toby | 123 Elm St. | 252 | +----+------+---------------+---------------+ Multiple-table queries are discussed further in Chapter 12. The preceding example illustrates how to normalize a table for which data values are repeated across rows. Another kind of non-normal form occurs when you have multiple columns within rows that record the same kind of information. For example, if you're running a study that involves administering two tests to subjects and recording the date and score for each test, you might use a table that has the following structure: CREATE TABLE test_subject ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name CHAR(20) NOT NULL, # subject name date1 DATE, # date and score of first test result1 INT, date2 DATE, # score of second test result2 INT, PRIMARY KEY (id) ); Information in the table looks like this: +----+--------+------------+---------+------------+---------+ | id | name | date1 | result1 | date2 | result2 | +----+--------+------------+---------+------------+---------+ | 1 | Fred | 2001-07-13 | 78 | 2001-07-14 | 85 | | 2 | Barry | 2001-07-12 | 79 | 2001-07-14 | 82 | | 3 | Portia | 2001-07-16 | 82 | 2001-07-18 | 95 | +----+--------+------------+---------+------------+---------+ When the information is contained in a table of this form, if you want to do something such as computing each subject's average score, you can do so with the following query: SELECT id, name, (result1 + result2) / 2 FROM test_subject; If you decide you need to add a third test, and a fourth, you can add columns to the table easily: ALTER TABLE test_subject ADD date3 DATE, ADD result3 INT, ADD date4 DATE, ADD result4 INT; But the query to compute average scores becomes more complex: SELECT id, name, (result1 + result2 + result3 + result4) / 4 FROM test_subject; In fact, if scores can be NULL to signify that a subject hasn't taken a test yet, the query is much messier than that, because you must add only the non-NULL values to avoid getting a NULL sum. This ballooning complexity is a clue that the table design could be improved. The problem is that the structure of the table is dependent on the number of tests you plan to give. If you change that number, you must change the table. A way around this problem is to use two tables, structured so that they need not be changed if you decide to administer additional tests: · The first table records information unique to each subject. · The second table records test results, one row per test. Each row can be associated with the proper subject using the subject ID number. This is very similar to the approach used in the preceding example, where we used two tables to hold client billing information. However, instead of creating two new tables and then removing the original table, we'll use a different procedure that preserves the original table, albeit in modified form: · Create a table test_result to hold test dates and scores, as well as the subject ID number. To allow scores to be ordered, we can also add a test number column. (The date might serve for ordering, unless it's possible for subjects to take multiple tests on the same day. An explicit test number does not have that problem.) · Copy the subject ID, date, and score information from test_subject to test_result. · Remove the date and score columns from test_subject, leaving only subject IDs and names. Begin by creating a table to hold test results: CREATE TABLE test_result ( id INT UNSIGNED NOT NULL, test_num INT NOT NULL, date DATE, result INT ); Copy the test information from test_subject to test_result. It's necessary to do this separately for each test, because each result is copied from a different set of columns: INSERT INTO test_result (id,test_num,date,result) SELECT id,1,date1,result1 FROM test_subject WHERE result1 IS NOT NULL; INSERT INTO test_result (id,test_num,date,result) SELECT id,2,date2,result2 FROM test_subject WHERE result2 IS NOT NULL; Each INSERT INTO ... SELECT statement specifies the test_num value "manually," because the appropriate value is not present in the test_subject table and cannot be derived directly from its contents. The WHERE clause serves to copy only rows with non-NULL test results. This handles the possibility that your test_subject records might be incomplete, such that a NULL score indicates a subject hasn't taken a given test. (If the test_subject table has no such missing test results, the WHERE clauses are unnecessary and can be omitted.) The test_result table is populated now and can be indexed. Note that although the id column is a unique-valued column in the test_subject table, it cannot be so in test_result because there will be multiple rows per subject. However, it's still possible to create a unique index by using both id and test_num, assuming each test is given to each subject only once: ALTER TABLE test_result ADD PRIMARY KEY (id, test_num); The test result columns in test_subject are now unneeded and can be removed: ALTER TABLE test_subject DROP date1, DROP result1, DROP date2, DROP result2; The advantage of using a two-table layout like this is that queries to perform operations such as score-averaging become independent of the number of tests administered: SELECT id, AVG(result) FROM test_result GROUP BY id; To show subject names, too, join the test_result table to the test_subject table: SELECT test_result.id, test_subject.name, AVG(test_result.result) FROM test_subject, test_result WHERE test_subject.id = test_result.id GROUP BY test_result.id; You also can easily identify subjects who have not completed all the tests. For example, if you've presented a total of four tests, you can find subjects who don't have four scores in the test_result table like this: SELECT test_subject.id, test_subject.name, COUNT(test_result.result) AS count FROM test_subject LEFT JOIN test_result ON test_subject.id = test_result.id GROUP BY test_subject.id HAVING count < 4; This query uses LEFT JOIN to make sure that a count for every subject is generated, even those to whom no tests have yet been administered. (A regular join will fail to identify a subject who has a record in the test_subject table but no records yet in the test_result table, because it will find no match between the tables.) LEFT JOIN is discussed in Chapter 12. Chapter 9. Obtaining and Using Metadata Introduction Obtaining the Number of Rows Affected by a Query Obtaining Result Set Metadata Determining Presence or Absence of a Result Set Formatting Query Results for Display Getting Table Structure Information Getting ENUM and SET Column Information Database-Independent Methods of Obtaining Table Information Applying Table Structure Information Listing Tables and Databases Testing Whether a Table Exists Testing Whether a Database Exists Getting Server Metadata Writing Applications That Adapt to the MySQL Server Version Determining the Current Database Determining the Current MySQL User Monitoring the MySQL Server Determining Which Table Types the Server Supports 9.1 Introduction Most of the queries used so far have been written to work with the data stored in the database. That is, after all, what the database is designed to hold. But sometimes you need more than just data values. You need information that characterizes or describes those values—that is, the query metadata. Metadata information is used most often in relation to processing result sets, but also is available for other aspects of your interaction with MySQL. This chapter describes how to obtain and use the following types of metadata: · Information about the result of queries. When you delete or update a set of rows, you can determine the number of rows that were changed. For a SELECT query, you can find out the number of columns in the result set, as well as information about each column in the result set, such as the column name and its display width. Such information often is essential for processing the results. For example, if you're formatting a tabular display, you can determine how wide to make each column and whether to justify values to the left or right. · Information about tables and databases. Information pertaining to the structure of tables and databases is useful for applications that need to enumerate a list of tables in a database or databases hosted on a server (for example, to present a display allowing the user to select one of the available choices). You can also use this information to determine whether tables or databases exist. Another use for table metadata is to determine the legal values for ENUM or SET columns. · Information about the MySQL server. Some APIs provide information about the database server or about the status of your current connection with the server. Knowing the server version can be useful for determining whether it supports a given feature, which helps you build adaptive applications. Information about the connection includes such items as the current user and the current database. Some APIs try to provide a database-independent interface for types of metadata that tend to be available across a variety of database engines (such as the names of the columns in a result set). But in general, metadata information is closely tied to the structure of the database system, so it tends to be somewhat database-dependent. This means that if you port an application that uses recipes in this chapter to other databases, it may need some modification. For example, lists of tables and databases in MySQL are available by issuing SHOW statements. However, SHOW is a MySQL-specific extension to SQL, so even if you're using an API like DBI, DB-API, or JDBC that gives you a database-independent way of issuing queries, the SQL itself is database-specific and will need to be changed to work with other engines. The scripts containing the code for the examples shown here are in the metadata directory of the recipes distribution. (Some of them use utility functions located in the lib directory.) To create any tables that you need for trying the examples, look in the tables directory. In several cases, recipes developed here construct queries using a database, table, or column name that is stored in a variable. For simplicity, generally such names are inserted as is into the query string. For example: $query = "SHOW COLUMNS FROM $tbl_name"; This works properly in the majority of cases, but there are some possible complications you should know about, and may wish to take into account when adapting these recipes for your own use. As of MySQL 3.23.6, names are allowed to contain almost any character, such as spaces. If you anticipate a need to deal with such names, surround the name with backticks: $query = "SHOW COLUMNS FROM `$tbl_name`"; If the server is running in ANSI mode, name quoting should be done with double quotes instead: $query = "SHOW COLUMNS FROM \"$tbl_name\""; To deal with these issues on a general basis, you can query the server to see if it is Version 3.23.6 or later (see Recipe 9.14), and you can also use SHOW VARIABLES to see if it is running in ANSI mode. The recipes here do not perform all these checks, because doing so would obscure their main point. 9.2 Obtaining the Number of Rows Affected by a Query 9.2.1 Problem You want to know how many rows were changed by a query. 9.2.2 Solution Some APIs provide the count as the return value of the function that issues the query. Others have a separate function that you call after issuing the query. 9.2.3 Discussion For queries that affect rows (UPDATE, DELETE, INSERT, REPLACE), each API provides a way to determine the number of rows involved. For MySQL, "affected by" normally means "changed by," so rows that are not changed by a query are not counted, even if they match the conditions specified in the query. For example, the following UPDATE statement would result in an "affected by" value of zero because it does not change any columns from their current values, no matter how many rows the WHERE clause matches: UPDATE limbs SET arms = 0 WHERE arms = 0; 9.2.4 Perl In DBI scripts, the affected-rows count is returned by do( ) or by execute( ), depending on how you execute the query: # execute $query using do( ) my $count = $dbh->do ($query); # report 0 rows if an error occurred printf "%d rows were affected\n", (defined ($count) ? $count : 0); # execute query using prepare( ) plus execute( ) my $sth = $dbh->prepare ($query); my $count = $sth->execute ( ); printf "%d rows were affected\n", (defined ($count) ? $count : 0); When you use DBI, you have the option of asking MySQL to return the "matched by" value rather than the "affected by" value. To do this, specify mysql_client_found_rows=1 in the options part of the data source name argument of the connect( ) call when you connect to the MySQL server. Here's an example: my $dsn = "DBI:mysql:cookbook:localhost;mysql_client_found_rows=1"; my $dbh = DBI->connect ($dsn, "cbuser", "cbpass", { PrintError => 0, RaiseError => 1 }); mysql_client_found_rows changes the row-reporting behavior for the duration of the connection. 9.2.5 PHP In PHP, invoke the mysql_affected_rows( ) function to find out how many rows a query changed: $result_id = mysql_query ($query, $conn_id); # report 0 rows if the query failed $count = ($result_id ? mysql_affected_rows ($conn_id) : 0); print ("$count rows were affected\n"); The argument to mysql_affected_rows( ) is a connection identifier. If you omit the argument, the current connection is used. 9.2.6 Python Python's DB-API makes the row count available as the value of the query cursor's rowcount attribute: cursor = conn.cursor ( ) cursor.execute (query) print "%d rows were affected" % cursor.rowcount 9.2.7 Java The Java JDBC interface provides row counts two different ways, depending on the method you invoke to execute the query. If you use executeUpdate( ), it returns the row count directly: Statement s = conn.createStatement ( ); int count = s.executeUpdate (query); s.close ( ); System.out.println (count + " rows were affected"); If you use execute( ), that method returns true or false to indicate whether or not the statement produces a result set. For statements such as UPDATE or DELETE that return no result set, the row count is available by calling the getUpdateCount( ) method: Statement s = conn.createStatement ( ); if (!s.execute (query)) { // there is no result set, print the row count System.out.println (s.getUpdateCount ( ) + " rows were affected"); } s.close ( ); For statements that modify rows, the MySQL Connector/J JDBC driver provides a rows- matched value for the row count, rather than a rows-affected value. 9.3 Obtaining Result Set Metadata 9.3.1 Problem You know how to retrieve the rows of a result set, but you want to know things about the result, such as the column names and data types, or the number of rows and columns there are. 9.3.2 Solution Use the appropriate capabilities provided by your API. 9.3.3 Discussion For queries that generate a result set, you can get a number of kinds of metadata. This section discusses the information provided by each API, using programs that show how to display the result set metadata available after issuing a sample query (SELECT name, foods FROM profile). The section also discusses some applications for this information. One of the simplest uses is illustrated by several of the example programs: When you retrieve a row of values from a result set and you want to process them in a loop, the column count stored in the metadata serves as the upper bound on the loop iterator. 9.3.4 Perl Using the DBI interface, you can obtain result sets two ways. These differ in the scope of result set metadata available to your scripts: · Process the query using a statement handle. In this case, you invoke prepare( ) to get the statement handle, then call its execute( ) method to generate the result set, then fetch the rows in a loop. With this approach, access to the metadata is available while the result set is active—that is, after the call to execute( ) and until the end of the result set is reached. When the row-fetching method finds that there are no more rows, it invokes finish( ) implicitly, which causes the metadata to become unavailable. (That also happens if you explicitly call finish( ) yourself.) Thus, normally it's best to access the metadata immediately after calling execute( ), making a copy of any values that you'll need to use beyond the end of the fetch loop. · Process the query using a database handle method that returns the result set in a single operation. With this method, any metadata generated while processing the query will have been disposed of by the time the method returns, although you can still determine the number of rows and columns from the size of the result set. When you use the statement handle approach to process a query, DBI makes result set metadata available after you invoke the handle's execute( ) method. This information is available primarily in the form of references to arrays. There is a separate array for each type of metadata, and each array has one element per column in the result set. Array references are accessed as attributes of the statement handle. For example, $sth->{NAME} points to the column name array. Individual column names are available as elements of this array: $name = $sth->{NAMES}->[$i]; Or you can access the entire array like this: @names = @{$sth->{NAMES}}; The following table lists the attribute names through which you access array-based metadata and the meaning of values in each array. Names that begin with uppercase are standard DBI attributes and should be available for most database engines. Attribute names that begin with mysql_ are MySQL-specific and non-portable; the kinds of information they provide may be available in other databases, but under different attribute names. Attribute name Array element meaning NAME Column name NAME_lc Column name, lowercased NAME_uc Column name, uppercased NULLABLE 1 if column values can be NULL, empty string if not PRECISION Column width SCALE Number of decimal places (for numeric columns) TYPE Numeric column type (DBI value) mysql_is_blob True if column has a BLOB (or TEXT) type mysql_is_key True if column is part of a non-unique key mysql_is_num True if column has a numeric type mysql_is_pri_key True if column is part of a primary key mysql_max_length Actual maximum length of column values in result set mysql_table Name of table the column is part of mysql_type Numeric column type (internal MySQL value) mysql_type_name Column type name The exception to array-based metadata is that the number of columns in a result set is available as a scalar value: $num_cols = $sth->{NUM_OF_FIELDS}; Here's some example code that shows how to execute a query and display the result set metadata: my $query = "SELECT name, foods FROM profile"; printf "Query: %s\n", $query; my $sth = $dbh->prepare ($query); $sth->execute( ); # metadata information becomes available at this point ... printf "NUM_OF_FIELDS: %d\n", $sth->{NUM_OF_FIELDS}; print "Note: query has no result set\n" if $sth->{NUM_OF_FIELDS} == 0; for my $i (0 .. $sth->{NUM_OF_FIELDS}-1) { printf "--- Column %d (%s) ---\n", $i, $sth->{NAME}->[$i]; printf "NAME_lc: %s\n", $sth->{NAME_lc}->[$i]; printf "NAME_uc: %s\n", $sth->{NAME_uc}->[$i]; printf "NULLABLE: %s\n", $sth->{NULLABLE}->[$i]; printf "PRECISION: %s\n", $sth->{PRECISION}->[$i]; printf "SCALE: %s\n", $sth->{SCALE}->[$i]; printf "TYPE: %s\n", $sth->{TYPE}->[$i]; printf "mysql_is_blob: %s\n", $sth->{mysql_is_blob}->[$i]; printf "mysql_is_key: %s\n", $sth->{mysql_is_key}->[$i]; printf "mysql_is_num: %s\n", $sth->{mysql_is_num}->[$i]; printf "mysql_is_pri_key: %s\n", $sth->{mysql_is_pri_key}->[$i]; printf "mysql_max_length: %s\n", $sth->{mysql_max_length}->[$i]; printf "mysql_table: %s\n", $sth->{mysql_table}->[$i]; printf "mysql_type: %s\n", $sth->{mysql_type}->[$i]; printf "mysql_type_name: %s\n", $sth->{mysql_type_name}->[$i]; } $sth->finish ( ); # release result set, since we didn't fetch its rows If you use the preceding code to execute the query SELECT name, foods FROM profile, the output looks like this: Query: SELECT name, foods FROM profile NUM_OF_FIELDS: 2 --- Column 0 (name) --- NAME_lc: name NAME_uc: NAME NULLABLE: PRECISION: 20 SCALE: 0 TYPE: 1 mysql_is_blob: mysql_is_key: mysql_is_num: 0 mysql_is_pri_key: mysql_max_length: 7 mysql_table: profile mysql_type: 254 mysql_type_name: char --- Column 1 (foods) --- NAME_lc: foods NAME_uc: FOODS NULLABLE: 1 PRECISION: 42 SCALE: 0 TYPE: 1 mysql_is_blob: mysql_is_key: mysql_is_num: 0 mysql_is_pri_key: mysql_max_length: 21 mysql_table: profile mysql_type: 254 mysql_type_name: char To get a row count from a result set generated by calling execute( ), you must fetch the rows and count them yourself. (The use of $sth->rows( ) to get a count for SELECT statements is specifically deprecated in the DBI documentation.) You can also obtain a result set by calling one of the DBI methods that uses a database handle rather than a statement handle, such as selectall_arrayref( ) or selectall_hashref( ). For these methods, no access to column metadata is provided. That information already will have been disposed of by the time the method returns, and is unavailable to your scripts. However, you can still derive column and row counts by examining the result set itself. The way you do this depends on the kind of data structure a method produces. These structures and the way you use them to obtain result set row and column counts are discussed in Recipe 2.5. 9.3.5 PHP In PHP, metadata information is available after a successful call to mysql_query( ) and remains accessible up to the point at which you call mysql_free_result( ). To access the metadata, pass the result set identifier returned by mysql_query( ) to the function that returns the information you want. To get a row or column count for a result set, invoke mysql_num_rows( ) or mysql_num_fields( ). Metadata information for a given column in a result set is packaged up in a single object. You get the object by passing the result set identifier and a column index to mysql_fetch_field( ), then access the various metadata attributes as members of that object. These members are summarized in the following table: Member name Member meaning blob 1 if column has a BLOB (or TEXT) type, 0 otherwise max_length Actual maximum length of column values in result set multiple_key 1 if column is part of a non-unique key, 0 otherwise name Column name not_null 1 if column values cannot be NULL, 0 otherwise numeric 1 if column has a numeric type, 0 otherwise primary_key 1 if column is part of a primary key, 0 otherwise table Name of table the column is part of type Column type name unique_key 1 if column is part of a unique key, 0 otherwise unsigned 1 if column has the UNSIGNED attribute, 0 otherwise zerofill 1 if column has the ZEROFILL attribute, 0 otherwise The following code shows how to access and display result set metadata: $query = "SELECT name, foods FROM profile"; print ("Query: $query\n"); $result_id = mysql_query ($query, $conn_id); if (!$result_id) die ("Query failed\n"); # metadata information becomes available at this point ... # @ is used below because mysql_num_rows( ) and mysql_num_fields( ) print # a message if there is no result set (under PHP 4, at least) $nrows = @mysql_num_rows ($result_id); print ("Number of rows: $nrows\n"); $ncols = @mysql_num_fields ($result_id); print ("Number of columns: $ncols\n"); if ($ncols == 0) print ("Note: query has no result set\n"); for ($i = 0; $i < $ncols; $i++) { $col_info = mysql_fetch_field ($result_id, $i); printf ("--- Column %d (%s) ---\n", $i, $col_info->name); printf ("blob: %s\n", $col_info->blob); printf ("max_length: %s\n", $col_info->max_length); printf ("multiple_key: %s\n", $col_info->multiple_key); printf ("not_null: %s\n", $col_info->not_null); printf ("numeric: %s\n", $col_info->numeric); printf ("primary_key: %s\n", $col_info->primary_key); printf ("table: %s\n", $col_info->table); printf ("type: %s\n", $col_info->type); printf ("unique_key: %s\n", $col_info->unique_key); printf ("unsigned: %s\n", $col_info->unsigned); printf ("zerofill: %s\n", $col_info->zerofill); } if ($ncols > 0) # dispose of result set, if there is one mysql_free_result ($result_id); The output from the program looks like this: Query: SELECT name, foods FROM profile Number of rows: 10 Number of columns: 2 --- Column 0 (name) --- blob: 0 max_length: 7 multiple_key: 0 not_null: 1 numeric: 0 primary_key: 0 table: profile type: string unique_key: 0 unsigned: 0 zerofill: 0 --- Column 1 (foods) --- blob: 0 max_length: 21 multiple_key: 0 not_null: 0 numeric: 0 primary_key: 0 table: profile type: string unique_key: 0 unsigned: 0 zerofill: 0 9.3.6 Python Python's DB-API is more limited than the other APIs in providing result set metadata. The row and column counts are available, but the information about individual columns is not as extensive. To get the row count for a result set, access the cursor's rowcount attribute. The column count is not available directly, but after calling fetchone( ) or fetchall( ), you can determine the count as the length of any result set row tuple. It's also possible to determine the column count without fetching any rows by using cursor.description. This is a tuple containing one element per column in the result set, so its length tells you how many columns are in the set. (However, be aware that if the query generates no result set, such as for an UPDATE statement, the value of description is None.) Each element of the description tuple is another tuple that represents the metadata for the corresponding column of the result. There are seven metadata values per column; the following code shows how to access them and what they mean: query = "SELECT name, foods FROM profile" print "Query: ", query cursor = conn.cursor ( ) cursor.execute (query) # metadata information becomes available at this point ... print "Number of rows:", cursor.rowcount if cursor.description == None: # no result set ncols = 0 else: ncols = len (cursor.description) print "Number of columns:", ncols if ncols == 0: print "Note: query has no result set" for i in range (ncols): col_info = cursor.description[i] # print name, then other information print "--- Column %d (%s) ---" % (i, col_info[0]) print "Type: ", col_info[1] print "Display size: ", col_info[2] print "Internal size:", col_info[3] print "Precision: ", col_info[4] print "Scale: ", col_info[5] print "Nullable: ", col_info[6] cursor.close The output from the program looks like this: Query: SELECT name, foods FROM profile Number of rows: 10L Number of columns: 2 --- Column 0 (name) --- Type: 254 Display size: 7 Internal size: 20 Precision: 20 Scale: 0 Nullable: 0 --- Column 1 (foods) --- Type: 254 Display size: 21 Internal size: 42 Precision: 42 Scale: 0 Nullable: 1 9.3.7 Java JDBC makes result set metadata available through a ResultSetMetaData object, which you obtain by calling the getMetaData( ) method of your ResultSet object. The metadata object provides access to several kinds of information. Its getColumnCount( ) method returns the number of columns in the result set. Other types of metadata, illustrated by the following code, provide information about individual columns and take a column index as their argument. Note that for JDBC, column indexes begin at 1, not 0, which differs from DBI, PHP, and DB-API. String query = "SELECT name, foods FROM profile"; System.out.println ("Query: " + query); Statement s = conn.createStatement ( ); s.executeQuery (query); ResultSet rs = s.getResultSet ( ); ResultSetMetaData md = rs.getMetaData ( ); // metadata information becomes available at this point ... int ncols = md.getColumnCount ( ); System.out.println ("Number of columns: " + ncols); if (ncols == 0) System.out.println ("Note: query has no result set"); for (int i = 1; i <= ncols; i++) // column index values are 1-based { System.out.println ("--- Column " + i + " (" + md.getColumnName (i) + ") ---"); System.out.println ("getColumnDisplaySize: " + md.getColumnDisplaySize (i)); System.out.println ("getColumnLabel: " + md.getColumnLabel (i)); System.out.println ("getColumnType: " + md.getColumnType (i)); System.out.println ("getColumnTypeName: " + md.getColumnTypeName (i)); System.out.println ("getPrecision: " + md.getPrecision (i)); System.out.println ("getScale: " + md.getScale (i)); System.out.println ("getTableName: " + md.getTableName (i)); System.out.println ("isAutoIncrement: " + md.isAutoIncrement (i)); System.out.println ("isNullable: " + md.isNullable (i)); System.out.println ("isCaseSensitive: " + md.isCaseSensitive (i)); System.out.println ("isSigned: " + md.isSigned (i)); } rs.close ( ); s.close ( ); The output from the program looks like this: Query: SELECT name, foods FROM profile Number of columns: 2 --- Column 1 (name) --- getColumnDisplaySize: 20 getColumnLabel: name getColumnType: 1 getColumnTypeName: CHAR getPrecision: 0 getScale: 0 getTableName: profile isAutoIncrement: false isNullable: 0 isCaseSensitive: true isSigned: false --- Column 2 (foods) --- getColumnDisplaySize: 42 getColumnLabel: foods getColumnType: 1 getColumnTypeName: CHAR getPrecision: 0 getScale: 0 getTableName: profile isAutoIncrement: false isNullable: 1 isCaseSensitive: true isSigned: false As with DBI, the row count is not available directly; you must fetch the rows and count them. There actually are several other JDBC result set metadata calls than the ones shown in the preceding example, but many of them provide no useful information for MySQL. If you want to try them out, get a JDBC reference to see what the calls are and modify the program to see what, if anything, they return. 9.4 Determining Presence or Absence of a Result Set 9.4.1 Problem You just executed a query obtained from an external source, so you're not sure whether it returned a result set. 9.4.2 Solution Check the column count in the metadata. If the count is zero, there is no result set. 9.4.3 Discussion If you write an application that accepts query strings from an external source such as a file or a user entering text at the keyboard, you may not necessarily know whether or not any given query returns a result set. That's an important distinction, because queries that return a result set are processed differently than those that do not. One way to tell the difference is to check the metadata value that indicates the column count after executing the query. Assuming that no error occurred, a column count of zero indicates that the query was an INSERT, UPDATE, or other statement that returns no result set. A nonzero value indicates the presence of a result set and you can go ahead and fetch the rows. This technique works to distinguish SELECT from non-SELECT queries, even for SELECT queries that return an empty result set. (An empty result is different than no result. The former returns no rows, but the column count is still correct; the latter has no columns at all.) Some APIs provide other ways to distinguish query types than checking the column count. In JDBC, you can issue arbitrary queries using the execute( ) method, which directly indicates whether there is a result set by returning true or false. In Python, the value of cursor.description is None for statements that produce no result set. 9.5 Formatting Query Results for Display 9.5.1 Problem You want to produce a nicely formatted result set display. 9.5.2 Solution Let the result set metadata help you. It can give you important information about the structure and content of the results. 9.5.3 Discussion Metadata information is valuable for formatting query results, because it tells you several important things about the columns (such as the names and display widths), even if you don't know what the query was. For example, you can write a general-purpose function that displays a result set in tabular format with no knowledge about what the query might have been. The following Java code shows one way to do this. It takes a result set object and uses it to get the metadata for the result. Then it uses both objects in tandem to retrieve and format the values in the result. The output is similar to that produced by mysql: a row of column headers followed by the rows of the result, with columns nicely boxed and lined up vertically. Here's a sample of what the function displays, given the result set generated by the query SELECT id, name, birth FROM profile: +----------+--------------------+----------+ |id |name |birth | +----------+--------------------+----------+ |1 |Fred |1970-04-13| |2 |Mort |1969-09-30| |3 |Brit |1957-12-01| |4 |Carl |1973-11-02| |5 |Sean |1963-07-04| |6 |Alan |1965-02-14| |7 |Mara |1968-09-17| |8 |Shepard |1975-09-02| |9 |Dick |1952-08-20| |10 |Tony |1960-05-01| |11 |Juan |NULL | +----------+--------------------+----------+ 11 rows selected The primary problem an application like this must solve is to determine the proper display width of each column. The getColumnDisplaySize( ) method returns the column width, but we actually need to take into account other pieces of information: · The length of the column name has to be considered (it might be longer than the column width). · We'll print the word "NULL" for NULL values, so if the column can contain NULL values, the display width must be at least four. The following Java function, displayResultSet( ), formats a result set, taking the preceding factors into account. It also counts rows as it fetches them to determine the row count, because JDBC doesn't make that value available directly from the metadata. public static void displayResultSet (ResultSet rs) throws SQLException { ResultSetMetaData md = rs.getMetaData ( ); int ncols = md.getColumnCount ( ); int nrows = 0; int[ ] width = new int[ncols + 1]; // array to store column widths StringBuffer b = new StringBuffer ( ); // buffer to hold bar line // calculate column widths for (int i = 1; i <= ncols; i++) { // some drivers return -1 for getColumnDisplaySize( ); // if so, we'll override that with the column name length width[i] = md.getColumnDisplaySize (i); if (width[i] < md.getColumnName (i).length ( )) width[i] = md.getColumnName (i).length ( ); // isNullable( ) returns 1/0, not true/false if (width[i] < 4 && md.isNullable (i) != 0) width[i] = 4; } // construct +---+---... line b.append ("+"); for (int i = 1; i <= ncols; i++) { for (int j = 0; j < width[i]; j++) b.append ("-"); b.append ("+"); } // print bar line, column headers, bar line System.out.println (b.toString ( )); System.out.print ("|"); for (int i = 1; i <= ncols; i++) { System.out.print (md.getColumnName (i)); for (int j = md.getColumnName (i).length ( ); j < width[i]; j++) System.out.print (" "); System.out.print ("|"); } System.out.println ( ); System.out.println (b.toString ( )); // print contents of result set while (rs.next ( )) { ++nrows; System.out.print ("|"); for (int i = 1; i <= ncols; i++) { String s = rs.getString (i); if (rs.wasNull ( )) s = "NULL"; System.out.print (s); for (int j = s.length ( ); j < width[i]; j++) System.out.print (" "); System.out.print ("|"); } System.out.println ( ); } // print bar line, and row count System.out.println (b.toString ( )); if (nrows == 1) System.out.println ("1 row selected"); else System.out.println (nrows + " rows selected"); } If you want to be more elaborate, you can also test whether a column contains numeric values, and format it right-justified if so. In DBI and PHP scripts, this is easy to check, because you can access the mysql_is_num or numeric metadata attributes provided by those APIs. In DB-API and JDBC, it's not so easy. There is no "column is numeric" metadata value available, so you'd have to look at the column type indicator to see if it's one of the several possible numeric types. Another shortcoming of the displayResultSet( ) function is that it prints columns using the width of the column as specified in the table definition, not the maximum width of the values actually present in the result set. The latter value is often smaller. You can see this in the sample output that precedes the listing for displayResultSet( ). The id and name columns are 10 and 20 characters wide, even though the widest values are only two and seven characters long, respectively. In DBI, PHP, and DB-API, you can get the maximum width of the values present in the result set. To determine these widths in JDBC, you must iterate through the result set and check the column value lengths yourself. This requires a JDBC 2.0 driver that provides scrollable result sets. Assuming that to be true, the column- width calculation code in the displayResultSet( ) function could be modified as follows: // calculate column widths for (int i = 1; i <= ncols; i++) { width[i] = md.getColumnName (i).length ( ); // isNullable( ) returns 1/0, not true/false if (width[i] < 4 && md.isNullable (i) != 0) width[i] = 4; } // scroll through result set and adjust display widths as necessary while (rs.next ( )) { for (int i = 1; i <= ncols; i++) { byte[ ] bytes = rs.getBytes (i); if (!rs.wasNull ( )) { int len = bytes.length; if (width[i] < len) width[i] = len; } } } rs.beforeFirst ( ); // rewind result set before displaying it With that change, the result is a more compact query output display: +--+-------+----------+ |id|name |birth | +--+-------+----------+ |1 |Fred |1970-04-13| |2 |Mort |1969-09-30| |3 |Brit |1957-12-01| |4 |Carl |1973-11-02| |5 |Sean |1963-07-04| |6 |Alan |1965-02-14| |7 |Mara |1968-09-17| |8 |Shepard|1975-09-02| |9 |Dick |1952-08-20| |10|Tony |1960-05-01| |11|Juan |NULL | +--+-------+----------+ 11 rows selected 9.6 Getting Table Structure Information 9.6.1 Problem You want to find out how a table is defined. 9.6.2 Solution Thre are several ways to do this, ranging from statements that return this information directly, to using metadata from a query on the table. 9.6.3 Discussion Information about the structure of tables allows you to answer questions such as "What columns does a table contain and what are their types?" or "What are the legal values for an ENUM or SET column?" In MySQL, there are several ways to find out about a table's structure: · Use a SHOW COLUMNS statement. · Use a SELECT query that selects columns from the table, then examine the query metadata for information about each column. · Use the mysqldump command-line program or the SHOW CREATE TABLE statement to obtain a CREATE TABLE statement that displays the table's structure. The following sections discuss how you can ask MySQL for table information using each of these methods. To try out the examples, create the following item table that lists item IDs, names, and the colors in which each item is available: CREATE TABLE item ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name CHAR(20), colors SET('chartreuse','mauve','lime green','puce') DEFAULT 'puce', PRIMARY KEY (id) ); 9.6.4 Using SHOW COLUMNS to Get Table Structure The SHOW COLUMNS statement produces one row of output for each column in the table, with each row providing various pieces of information about the corresponding column.[1] I suggest that you try the SHOW COLUMNS statement with several of your own tables to get a feel for the kind of output it produces for various column types. The following example demonstrates the output that SHOW COLUMNS produces for the item table. (Note the use of \G as the statement terminator to generate "vertical" output; SHOW COLUMNS output lines often are so long that they wrap around and become difficult to read.) [1] SHOW COLUMNS FROM tbl_name is equivalent to SHOW FIELDS FROM tbl_name or DESCRIBE tbl_name. mysql> SHOW COLUMNS FROM item\G *************************** 1. row *************************** Field: id Type: int(10) unsigned Null: Key: PRI Default: NULL Extra: auto_increment *************************** 2. row *************************** Field: name Type: char(20) Null: YES Key: Default: NULL Extra: *************************** 3. row *************************** Field: colors Type: set('chartreuse','mauve','lime green','puce') Null: YES Key: Default: puce Extra: The information displayed by the statement is as follows: Field Indicates the column's name Type Shows the column type Null YES if the column can contain NULL values, blank otherwise Key Provides information about whether or not the column is indexed Default Indicates the default value Extra Lists miscellaneous information The format of SHOW COLUMNS changes occasionally, but the values just described should always be available. Your version of MySQL may display additional information. SHOW COLUMNS output is easy to use from within programs. The important thing to know is that SHOW is like SELECT in that it returns a result set, so you process a SHOW query by issuing the statement and performing a row-retrieval fetch loop. Here's a PHP function that illustrates this process. It takes a table name argument, then uses SHOW COLUMNS to obtain a list of the table's column names: function get_column_names_with_show ($conn_id, $tbl_name) { $query = "SHOW COLUMNS FROM $tbl_name"; if (!($result_id = mysql_query ($query, $conn_id))) return (FALSE); $names = array( ); # create empty array # first value in each output row is the column name while (list ($name) = mysql_fetch_row ($result_id)) $names[ ] = $name; # append name to array mysql_free_result ($result_id); return ($names); } The array returned by the function contains column names in the same order the columns appear in the table. Notice that get_column_names_with_show( ) takes no argument for specifying a database name. It's not necessary, because MySQL understands fully qualified table references of the form db_name.tbl_name. To access a table in a database other than the current one, just pass a $tbl_name argument that includes the database name: $names = get_column_names_with_show ($conn_id, "some_db.some_tbl"); The equivalent function in Python looks like this: def get_column_names_with_show (conn, tbl_name): names = [ ] cursor = conn.cursor ( ) cursor.execute ("SHOW COLUMNS FROM " + tbl_name) rows = cursor.fetchall ( ) cursor.close ( ) for row in rows: names.append (row[0]) return (names) In DBI, this operation is trivial, because selectcol_arrayref( ) returns the first column of the query result directly: sub get_column_names_with_show { my ($dbh, $tbl_name) = @_; my $ref = $dbh->selectcol_arrayref ("SHOW COLUMNS FROM $tbl_name"); return (defined ($ref) ? @{$ref} : ( )); } Interpreting the Default Value Displayed by SHOW COLUMNS When you run SHOW COLUMNS from the mysql program, it displays the word "NULL" as the Default indicator for columns that may contain NULL values. However, if you issue a SHOW COLUMNS statement from within your own programs, don't look for the string "NULL." Look for the special value your API uses to represent NULL values, such as undef for DBI or None for DB-API. If you want information only about a single column, use a LIKE clause that matches the column name: mysql> SHOW COLUMNS FROM item LIKE 'colors'\G *************************** 1. row *************************** Field: colors Type: set('chartreuse','mauve','lime green','puce') Null: YES Key: Default: puce Extra: Observe that quotes surround the column name following the LIKE keyword. Quotes are required because the name isn't really a column name, it a SQL pattern string. The string is interpreted the same way as for the LIKE operator in the WHERE clause of a SELECT statement. (For information about pattern matching, see Recipe 4.7.) SHOW COLUMNS displays information for any columns having names that match the pattern; if you specify a literal column name, the string matches only that name and SHOW COLUMNS displays information only for that column. However, a trap awaits the unwary here. If your column name contains SQL pattern characters (% or _) and you want to match them literally, you must escape them with a backslash in the pattern string to avoid matching other names as well. The % character isn't used very often in column names, but _ is quite common, so it's possible that you'll run into this problem. Suppose you have a table that contains the results of carbon dioxide measurements in a column named co_2, and trigonometric cosine and cotangent calculations in columns named cos1, cos2, cot1, and cot2. If you want to get information only for the co_2 column, you can't use this query: SHOW COLUMNS FROM tbl_name LIKE 'co_2'; The _ character means "match any character" in pattern strings, so the query would return rows for co_2, cos2, and cot2. To match only the co_2 column, write the SHOW command like this: SHOW COLUMNS FROM tbl_name LIKE 'co\_2'; Within a program, you can use your API language's pattern matching capabilities to escape SQL pattern characters before putting the column name into a SHOW query. For example, in Perl, PHP, and Python, you can use the following expressions: Perl: $name =~ s/([%_])/\\$1/g; PHP: $name = ereg_replace ("([%_])", "\\\\1", $name); For Python, import the re module, then do this: name = re.sub (r'([%_])', r'\\\1', name) If these expressions appear to have too many backslashes, remember that the API language processor itself interprets backslashes and strips off a level before performing the pattern match. To get a literal backslash into the result, it must be doubled in the pattern. PHP has another level on top of that because it strips a set and the pattern processor strips a set. For Java, you'll need to select a regular expression class library. The following example uses the ORO library available at jakarta.apache.org, which includes classes that emulate Perl5 regular expressions: import org.apache.oro.text.perl.*; Perl5Util util = new Perl5Util ( ); name = util.substitute ("s/([_%])/\\\\$1/g", name); The need to escape % and _ characters to match a LIKE value literally also applies to other forms of the SHOW statement that allow a name pattern in the LIKE clause, such as SHOW TABLES, SHOW DATABASES, and SHOW VARIABLES. 9.6.5 Using Result Set Metadata to Get Table Structure Another way to obtain table column information is to use the metadata generated when you issue a SELECT statement. (See Recipe 9.3.) Metadata information is available for any arbitrary query, and therefore can be obtained specifically for the columns of a given table. For example, the result set for SELECT * FROM tbl_name will contain metadata for each column in tbl_name. However, if you're interested only in the metadata, not in the data contained in the table, you'll naturally want to minimize the size of the result set so as to generate as little network traffic as possible. It's easy to guarantee that the result will be empty by adding a WHERE clause that is always false: SELECT * FROM tbl_name WHERE 1 = 0 Although this query selects no rows, it's perfectly legal and MySQL goes ahead and generates the metadata, from which you can extract whatever information you want. For example, earlier in this section we wrote a PHP function get_column_names_with_show( ) that gets a list of the column names by issuing a SHOW COLUMNS statement. The function can be reimplemented as follows to get the column names from the query metadata instead by running a SELECT query and calling mysql_fetch_field( ): function get_column_names_with_meta ($conn_id, $tbl_name) { $query = "SELECT * FROM $tbl_name WHERE 1 = 0"; if (!($result_id = mysql_query ($query, $conn_id))) return (FALSE); $names = array( ); # create empty array for ($i = 0; $i < mysql_num_fields ($result_id); $i++) { if ($field = mysql_fetch_field ($result_id, $i)) $names[ ] = $field->name; # append name to array } mysql_free_result ($result_id); return ($names); } The equivalent function in Perl is simpler. DBI organizes metadata into arrays, so we just need to access the $sth->{NAME} reference to the column name array. The only trick is that it's necessary to make a copy of the array before calling finish( ), because finish( ) destroys the metadata and renders the NAME array unavailable: sub get_column_names_with_meta { my ($dbh, $tbl_name) = @_; my ($sth, @names); $sth = $dbh->prepare ("SELECT * FROM $tbl_name WHERE 1=0"); $sth->execute ( ); @names = @{$sth->{NAME}}; # make a copy; finish( ) destroys meta info $sth->finish ( ); # release result set return (@names); } You can easily convert these functions that get column names into more general versions that allow you to specify which kind of metadata information you want. Name each function get_column_info( ) and add a parameter for the information type. In PHP, the function looks like this: function get_column_info ($conn_id, $tbl_name, $info_type) { $query = "SELECT * FROM $tbl_name WHERE 1 = 0"; if (!($result_id = mysql_query ($query, $conn_id))) return (FALSE); $info = array( ); # create empty array for ($i = 0; $i < mysql_num_fields ($result_id); $i++) { if ($field = mysql_fetch_field ($result_id, $i)) $info[ ] = $field->$info_type; # append info to array } mysql_free_result ($result_id); return ($info); } To use the function, call it as follows: $names = get_column_info ($conn_id, "item", "name"); $types = get_column_info ($conn_id, "item", "type"); $numeric = get_column_info ($conn_id, "item", "numeric"); The Perl version looks like this: sub get_column_info { my ($dbh, $tbl_name, $info_type) = @_; my ($sth, @info); $sth = $dbh->prepare ("SELECT * FROM $tbl_name WHERE 1=0"); $sth->execute ( ); @info = @{$sth->{$info_type}}; # make a copy; finish( ) destroys meta info $sth->finish ( ); # release result set return (@info); } And is invoked like this: my @names = get_column_info ($dbh, "item", "NAME"); my @types = get_column_info ($dbh, "item", "mysql_type_name"); my @numeric = get_column_info ($dbh, "item", "mysql_is_num"); One caution to observe with get_column_info( ) is that you can't use it to determine display widths for a table's columns. (That is, it is not useful for the mysql_max_length values in Perl or the max_length values in PHP.) When you use column metadata obtained from a SELECT statement, the column display widths reflect the widths of the values actually present in the result. When the query is SELECT ... WHERE 1=0, the result set is empty and the display widths are all zero! Portability of SELECT ... WHERE 1=0 The SELECT ... WHERE 1=0 query is reasonably portable across database systems, but won't necessarily work with all possible engines. If you want to use this query with database systems other than MySQL to obtain table information, be sure to test it first to make sure it works. Which Method Should You Use to Get Table Information? Can you get away with using just SHOW COLUMNS or just SELECT ... WHERE 1=0 for all your table information needs? Not necessarily. The information that these approaches provide overlaps, but not completely. If you want to determine column names or whether or not columns can be NULL, you can use either method. However, if you want to know legal members of an ENUM or SET column, you must use SHOW COLUMNS. Know your tools, and pick the right one for the job. The most appropriate method may depend on what you want to know. 9.6.6 Using CREATE TABLE to Get Table Structure A third way to obtain table structure information from MySQL is to use mysqldump --no-data from the command line to generate a CREATE TABLE statement that shows the structure of the table. The following command shows an example. The --no-data option tells mysqldump not to dump the data from the table, --all tells it to print all the CREATE TABLE options, and -- quote-names causes names to be quoted in case they contain special characters.[2] You can omit --all or --quote-names if you don't need their effect. [2] The --all option was introduced in MySQL 3.22.23 and --quote-names was introduced in 3.23.6. % mysqldump --no-data --all --quote-names cookbook item # MySQL dump 8.16 # # Host: localhost Database: cookbook #-------------------------------------------------------- # Server version 3.23.46-log # # Table structure for table 'item' # CREATE TABLE `item` ( `id` int(10) unsigned NOT NULL auto_increment, `name` char(20) default NULL, `colors` set('chartreuse','mauve','lime green','puce') default 'puce', PRIMARY KEY (`id`) ) TYPE=MyISAM; If you have MySQL 3.23.20 or later, you can get the same information using the SHOW CREATE TABLE statement: mysql> SHOW CREATE TABLE item; +-------+--------------+ | Table | Create Table | +-------+--------------+ | item | CREATE TABLE `item` ( `id` int(10) unsigned NOT NULL auto_increment, `name` char(20) default NULL, `colors` set('chartreuse','mauve','lime green','puce') default 'puce', PRIMARY KEY (`id`) ) TYPE=MyISAM | +-------+--------------+ This format is highly informative and easy to read because it shows column information in a format similar to the one you use to create the table in the first place. It also shows the index structure clearly, which the other methods do not. However, you'll probably find this method for checking table structure more useful for visual examination than for use within programs. The information isn't provided in regular row-and-column format, so it's more difficult to parse. Also, the format is somewhat subject to change whenever the CREATE TABLE statement is enhanced, which happens from time to time as MySQL's capabilities are extended. That's not to say there are no programmatic applications for SHOW CREATE TABLE output. It's useful, for example, for making an exact copy of a table, including all its indexes. The technique is described in Recipe 3.26, which discusses table cloning. 9.7 Getting ENUM and SET Column Information 9.7.1 Problem You want to know what the legal members of an ENUM or SET column are. 9.7.2 Solution Use SHOW COLUMNS to get the column definition and extract the member list from it. 9.7.3 Discussion It's often useful to know the list of legal values for an ENUM or SET column. Suppose you want to present a web form containing a pop-up menu that has options corresponding to each legal value of an ENUM column, such as the sizes in which a garment can be ordered, or the available shipping methods for delivering a package. You could hardwire the choices into the script that generates the form, but if you alter the column later (for example, to add a new enumeration value), you introduce a discrepancy between the column and the script that uses it. If instead you look up the legal values using the table metadata, the script always produces a pop-up that contains the proper set of values. A similar approach can be used with SET columns. To find out what values an ENUM or SET column can have, issue a SHOW COLUMNS statement for the column and look at the Type value in the result. For example, the colors column of the item table has a Type value that looks like this: set('chartreuse','mauve','lime green','puce') ENUM columns are similar, except that they say enum rather than set. For either column type, the allowable values can be extracted by stripping off the initial word and the parentheses, splitting at the commas, and removing the surrounding quotes from the individual values. Let's write a function get_enumorset_info( ) to break out these values from the column type definition.[3] While we're at it, we can have the function return the column's type, its default value, and whether or not values can be NULL. Then the function can be used by scripts that may need more than just the list of values. Here is a version in Python. It takes arguments representing a database connection, a table name, and a column name, and returns a dictionary with entries corresponding to the various aspects of the column definition: [3] Feel free to come up with a less horrible function name. def get_enumorset_info (conn, tbl_name, col_name): # create dictionary to hold column information info = { } try: cursor = conn.cursor ( ) # escape SQL pattern characters in column name to match it literally col_name = re.sub (r'([%_])', r'\\\1', col_name) # this is *not* a use of placeholders cursor.execute ("SHOW COLUMNS FROM %s LIKE '%s'" \ % (tbl_name, col_name)) row = cursor.fetchone ( ) cursor.close if row == None: return None except: return None info["name"] = row[0] # get column type string; make sure it begins with ENUM or SET s = row[1] match = re.match ("(enum|set)\((.*)\)$", s) if not match: return None info["type"] = match.group (1) # column type # get values by splitting list at commas, then applying a # quote stripping function to each one s = re.split (",", match.group (2)) f = lambda x: re.sub ("^'(.*)'$", "\\1", x) info["values"] = map (f, s) # determine whether or not column can contain NULL values info["nullable"] = (row[2] == "YES") # get default value (None represents NULL) info["default"] = row[4] return info The following example shows one way to access and display each element of the dictionary value returned by get_enumorset_info( ): info = get_enumorset_info (conn, tbl_name, col_name) print "Information for " + tbl_name + "." + col_name + ":" if info == None: print "No information available (not an ENUM or SET column?)" else: print "Name: " + info["name"] print "Type: " + info["type"] print "Legal values: " + string.join (info["values"], ",") if info["nullable"]: print "Nullable" else: print "Not nullable" if info["default"] == None: print "Default value: NULL" else: print "Default value: " + info["default"] That code produces the following output for the item table colors column: Information for item.colors: Type: set Legal values: chartreuse,mauve,lime green,puce Nullable Default value: puce Equivalent functions for other APIs are similar. They'll come in handy in the context of generating list elements in web forms. (See Recipe 18.3 and Recipe 18.4.) 9.8 Database-Independent Methods of Obtaining Table Information 9.8.1 Problem You want a way to get table information that doesn't use MySQL-specific queries like SHOW COLUMNS. 9.8.2 Solution This isn't possible for all APIs. One exception is JDBC, which provides a standard interface to table metadata. 9.8.3 Discussion The preceding methods for obtaining table information used specific SHOW or SELECT queries and showed how to process them using each API. These techniques are MySQL-specific. JDBC provides a way to access this information through a standard interface that makes no reference to particular queries, so you can use it portably with database engines other than MySQL. With this interface, you use your connection object to obtain a database metadata object, then invoke the getColumns( ) method of that object to retrieve column information. getColumns( ) returns a result set containing one row per column name, so you must run a fetch loop to retrieve information about successive columns. Elements of result set rows that are relevant for MySQL are: Index Meaning 3 Table name 4 Column name 6 Column type name 7 Column size (for numeric columns, this is the precision) 8 Number of decimal places, for numeric columns 18 Whether or not column values can be NULL Here's an example that shows how to use getColumns( ) to print a list of column names and types: DatabaseMetaData md = conn.getMetaData ( ); ResultSet rs = md.getColumns (dbName, "", tblName, "%"); int i = 0; while (rs.next ( )) { i++; System.out.println ("--- Column " + i + " ---"); System.out.println ("Name: " + rs.getString (4)); System.out.println ("Type: " + rs.getString (6)); } rs.close ( ); If the value of the tblName variable is "item", the output looks like this: --- Column 1 --- Name: id Type: int --- Column 2 --- Name: name Type: char --- Column 3 --- Name: colors Type: enum The four arguments to getColumns( ) are the names of the catalog, schema, and table, followed by a SQL pattern that column names must match to be selected. For MySQL, these arguments have the following meanings: · The catalog name is the database name. To use the current database, pass an empty string. · MySQL has no concept of schema, so the schema name argument is irrelevant and can be the empty string. · The table name argument is a string naming the table. · The column name pattern is analogous to using the LIKE clause in a SHOW COLUMNS statement. The example shown above uses "%", which matches all column names. You can pass a specific column name to get information for a single column. (Remember to escape any % and _ characters with a backslash if you want to match them literally.) 9.9 Applying Table Structure Information 9.9.1 Problem It's all well and good to be able to obtain table structure information, but what can you use it for? 9.9.2 Solution Lots of things: displaying lists of table columns, creating web form elements, producing ALTER TABLE statements for modifying ENUM or SET columns, and more. 9.9.3 Discussion This section describes some applications for the table structure information that MySQL provides. 9.9.4 Displaying Column Lists Probably the simplest use of table information is to present a list of the table's columns. This is common in web-based or GUI applications that allow users to construct queries interactively by selecting a table column from a list and entering a value against which to compare column values. The various versions of the get_column_names_with_show( ) or get_column_names_with_meta( ) functions shown earlier in the chapter can serve as the basis for such list displays. 9.9.5 Interactive Record Editing Knowledge of a table's structure can be very useful for interactive record-editing applications. Suppose you have an application that retrieves a record from the database, displays a form containing the record's content so a user can edit it, and then updates the record in the database after the user modifies the form and submits it. You can use table structure information for validating column values. For example, if a column is an ENUM, you can find out the valid enumeration values and check the value submitted by the user against them to determine whether or not it's legal. If the column is an integer type, you check the submitted value to make sure that it consists entirely of digits, possibly preceded by a sign character. If the column contains dates, look for a legal date format. But what if the user leaves a field empty? If the field corresponds to, say, a CHAR column in the table, do you set the column value to NULL or to the empty string? This too is a question that can be answered by checking the table's structure. Determine whether or not the column can contain NULL values. If it can, set the column to NULL; otherwise, set it to the empty string. 9.9.6 Mapping Column Types onto Web Page Elements Some column types such as ENUM and SET correspond naturally to elements of web forms: · An ENUM has a fixed set of values from which you choose a single value. This is analogous to a group of radio buttons, a pop-up menu, or a single-pick scrolling list. · A SET column is similar, except that you can select multiple values; this corresponds to a group of checkboxes or a multiple-pick scrolling list. If you access the information for these types of columns using SHOW COLUMNS, you can easily determine the legal values for a column and map them onto the appropriate form element automatically. This allows you to present users with a list of applicable values from which selections can be made easily without any typing. Earlier in this chapter we saw how to get ENUM and SET column metadata. The methods developed there are used in Chapter 18, which discusses form generation in more detail. 9.9.7 Adding Elements to ENUM or SET Column Definitions It's really a pain to add a new element to an ENUM or SET column definition when you use ALTER TABLE, because you have to list not only the new element, but all the existing elements as well. One approach for doing this using mysqldump and an editor is described in Recipe 8.3. Another way to accomplish this task is to write your own program that does most of the work for you by using column metadata. Let's develop a Python script add_element.py that generates the appropriate ALTER TABLE statement automatically when given a table name, an ENUM or SET column name, and the new element value. Suppose you want to add "hot pink" to the colors column of the item table. The current structure of the column looks like this: mysql> SHOW COLUMNS FROM item LIKE 'colors'\G *************************** 1. row *************************** Field: colors Type: set('chartreuse','mauve','lime green','puce') Null: YES Key: Default: puce Extra: add_element.py will use that information to figure out the correct ALTER TABLE statement and write it out: % ./add_element.py item colors "hot pink" ALTER TABLE item MODIFY colors set('chartreuse','mauve','lime green','puce','hot pink') NULL DEFAULT 'puce'; By having add_element.py produce the statement as its output, you have the choice of shoving it into mysql for immediate execution or saving the output into a file: % ./add_element.py item colors "hot pink" | mysql cookbook % ./add_element.py item colors "hot pink" > stmt.sql You might choose the latter course if you want the new element somewhere other than at the end of the list of values, which is where add_element.py will put it. In this case, edit stmt.sql to place the element where you want it, then execute the statement: % vi stmt.sql % mysql cookbook < stmt.sql The first part of the add_element.py script imports the requisite modules and checks the command-line arguments. This is fairly straightforward: #! /usr/bin/python # add_element.py - show ALTER TABLE statement for ENUM or SET column # (assumes cookbook database) import sys sys.path.insert (0, "/usr/local/apache/lib/python") import re import MySQLdb import Cookbook if len (sys.argv) != 4: print "Usage: add_element.py tbl_name col_name new_element" sys.exit (1) tbl_name = sys.argv[1] col_name = sys.argv[2] elt_val = sys.argv[3] After connecting to the MySQL server (code not shown), we need to run a SHOW COLUMNS query to retrieve information about the designated column. The following code does this, checking to make sure that the column really exists in the table: cursor = conn.cursor ( ) # escape SQL pattern characters in column name to match it literally esc_col_name = re.sub (r'([%_])', r'\\\1', col_name) # this is *not* a use of placeholders cursor.execute ("SHOW COLUMNS FROM %s LIKE '%s'" % (tbl_name, esc_col_name)) info = cursor.fetchone ( ) cursor.close if info == None: print "Could not retrieve information for table %s, column %s" \ % (tbl_name, col_name) sys.exit (1) At this point, if the SHOW COLUMNS statement succeeded, the information produced by it is available as a tuple stored in the info variable. We'll need to use several elements from this tuple. The most important is the column type value, which provides the enum(...) or set(...) string containing the column's current definition. We can use this to verify that the column really is an ENUM or SET, then add the new element to the string just before the closing parenthesis. For the colors column, we want to change this: set('chartreuse','mauve','lime green','puce') To this: set('chartreuse','mauve','lime green','puce','hot pink') It's also necessary to check whether column values can be NULL and what the default value is so that the program can add the appropriate information to the ALTER TABLE statement. The code that does all this is as follows: # get column type string; make sure it begins with ENUM or SET type = info[1] if not re.match ('(enum|set)', type): print "table %s, column %s is not an ENUM or SET" % (tbl_name, col_name) sys.exit(1) # add quotes, insert comma and new element just before closing paren elt_val = conn.literal (elt_val) type = re.sub ('\)$', ',' + elt_val + ')', type) # determine whether column can contain NULL values if info[2] == "YES": nullable = "NULL" else: nullable = "NOT NULL"; # construct DEFAULT clause (add surrounding quotes unless # value is NULL) default = "DEFAULT " + conn.literal (info[4]) print "ALTER TABLE %s\n\tMODIFY %s\n\t%s\n\t%s %s;" \ % (tbl_name, col_name, type, nullable, default) That's it. You now have a working ENUM- or SET-altering program. Still, add_element.py is fairly basic and could be improved in various ways: · Make sure that the element value you're adding to the column isn't already there. · Allow add_element.py to take more than one argument after the column name and add all of them to the column definition at the same time. · Add an option to indicate that the named element should be deleted rather than added. · Add an option that tells the script to execute the ALTER TABLE statement immediately rather than displaying it. · If you have a version of MySQL older than 3.22.16, it won't understand the MODIFY col_name syntax used by add_element.py. You may want to edit the script to use CHANGE col_name syntax instead. The following two statements are equivalent: · ALTER TABLE tbl_name MODIFY col_name col_definition; ALTER TABLE tbl_name CHANGE col_name col_name col_definition; add_element.py uses MODIFY because it's less confusing than CHANGE. 9.9.8 Retrieving Dates in Non-ISO Format MySQL stores dates in ISO 8601 format (CCYY-MM-DD), but it's often desirable or necessary to rewrite date values, such as when you need to transfer table data into another program that expects dates in another format. You can write a script that retrieves and prints table rows, using column metadata to detect DATE, DATETIME, and TIMESTAMP columns, and reformat them with DATE_FORMAT( ) into whatever date format you want. (For an example, see Recipe 10.34, which describes a short script named iso_to_us.pl that uses this technique to rewrite ISO dates into U.S. format.) 9.9.9 Converting Character Columns Between Fixed-Length and Variable-Length Types CHAR columns have a fixed length, whereas VARCHAR columns are variable length. In general, tables that use CHAR columns can be processed more quickly but take up more space than tables that use VARCHAR columns. To make it easier to convert tables to use CHAR or VARCHAR columns, you can use the information provided by SHOW COLUMNS to generate an ALTER TABLE statement that performs the requisite column conversions. Here is a Python function alter_to_char( ) that creates a statement for changing all the VARCHAR columns to CHAR: def alter_to_char (conn, tbl_name): cursor = conn.cursor ( ) cursor.execute ("SHOW COLUMNS FROM " + tbl_name) rows = cursor.fetchall ( ) cursor.close ( ) str = "" for info in rows: col_name = info[0] type = info[1] if re.match ('varchar', type): # it's a VARCHAR column type = re.sub ("var", "", type) # convert to CHAR # determine whether column can contain NULL values if info[2] == "YES": nullable = "NULL" else: nullable = "NOT NULL"; # construct DEFAULT clause (add surrounding quotes unless # value is NULL) default = "DEFAULT " + conn.literal (info[4]) # add MODIFY clause to string if str != "": str = str + ",\n\t" str = str + \ "MODIFY %s %s %s %s" % (col_name, type, nullable, default) cursor.close ( ) if str == "": return None return "ALTER TABLE " + tbl_name + "\n\t" + str Suppose you have a table that looks like this: CREATE TABLE chartbl ( c1 VARCHAR(10), c2 VARCHAR(10) BINARY, c3 VARCHAR(10) NOT NULL DEFAULT 'abc\'def' ); If you pass the name of that table to the alter_to_varchar( ) function, the statement that it returns looks like this: ALTER TABLE chartbl MODIFY c1 char(10) NULL DEFAULT NULL, MODIFY c2 char(10) binary NULL DEFAULT NULL, MODIFY c3 char(10) NOT NULL DEFAULT 'abc\'def' A function to convert columns in the other direction (from CHAR to VARCHAR) would be similar. Here is an example, this time in Perl: sub alter_to_varchar { my ($dbh, $tbl_name) = @_; my ($sth, $str); $sth = $dbh->prepare ("SHOW COLUMNS FROM $tbl_name"); $sth->execute ( ); while (my @row = $sth->fetchrow_array ( )) { if ($row[1] =~ /^char/) # it's a CHAR column { $row[1] = "var" . $row[1]; $str .= ",\n\t" if $str; $str .= "MODIFY $row[0] $row[1]"; $str .= ($row[2] eq "YES" ? "" : " NOT") . " NULL"; $str .= " DEFAULT " . $dbh->quote ($row[4]); } } $str = "ALTER TABLE $tbl_name\n\t$str" if $str; return ($str); } For completeness, the function generates an ALTER TABLE statement that explicitly converts all CHAR columns to VARCHAR. In practice, it's necessary to convert only one such column. MySQL notices the change of a column from fixed-length to variable-length format, and automatically converts any other fixed-length columns that have a variable-length equivalent. 9.9.10 Selecting All Except Certain Columns Sometimes you want to retrieve "almost all" the columns from a table. Suppose you have an image table that contains a BLOB column named data used for storing images that might be very large, and other columns that characterize the BLOB column, such as its ID, a description, and so forth. It's easy to write a SELECT * query that retrieves all the columns, but if all you need is the descriptive information about the images and not the images themselves, it's inefficient to drag the BLOB values over the connection along with the other columns. Instead, you want to select everything in the record except the data column. Unfortunately, there is no way to say directly in SQL, "select all columns except this one." You must explicitly name all the columns except data. On the other hand, it's easy to construct that kind of query by using table structure information. Extract the list of column names, delete the one to be excluded, then construct a SELECT query from those columns that remain. The following example shows how to do this in PHP, using the get_column_names_with_show( ) function developed earlier in the chapter to obtain the column names from a table: $names = get_column_names_with_show ($conn_id, $tbl_name); $query = ""; # construct list of columns to select: all but "data" reset ($names); while (list ($index, $name) = each ($names)) { if ($name == "data") continue; if ($query != "") # put commas between column names $query .= ","; $query .= $name; } $query = "SELECT $query FROM $tbl_name"; The equivalent Perl code for constructing the query is a bit shorter (and correspondingly more cryptic): my @names = get_column_names_with_show ($dbh, $tbl_name); my $query = "SELECT " . join (",", grep (!/^data$/, @names)) . " FROM $tbl_name"; Whichever language you use, the result is a query that you can use to select all columns but data. It will be more efficient than SELECT * because it won't pull the BLOB values over the network. Of course, this process does involve an extra round trip to the server to execute the statement that retrieves the column names, so you should consider the context in which you plan to use the SELECT query. If you're just going to retrieve a single record, it might be more efficient simply to select the entire row than to incur the overhead of the extra round trip. But if you're selecting many rows, the reduction in network traffic achieved by skipping the BLOB columns will be worth the overhead of the additional query for getting table structure. 9.10 Listing Tables and Databases 9.10.1 Problem You want a list of tables in a database or a list of databases hosted by the MySQL server. 9.10.2 Solution Use SHOW TABLES or SHOW DATABASES. 9.10.3 Discussion To obtain a list of tables in the current database, use this query: SHOW TABLES; However, if no database has been selected, the query will fail. To avoid this problem, you should either make sure there is a current database or name a database explicitly: SHOW TABLES FROM db_name; Another form of SHOW returns a list of databases hosted by the server: SHOW DATABASES; Be Careful with SHOW Statements Be careful how you interpret the results from SHOW TABLES and SHOW DATABASES. The result from SHOW TABLES will be empty if you don't have permission to access the table. The result from SHOW DATABASES may be empty as well. If the server was started with the --safe-show-database or --skip-show-database option, you may not be able to get much information with the SHOW DATABASES statement. If you're looking for a database-independent way to get table or database lists and you're using Perl or Java, try the following methods. In Perl, DBI provides a tables( ) function that returns a list of tables. It works for the current database only: my @tables = $dbh->tables ( ); In Java, you can use JDBC methods designed to return lists of tables or databases. For each method, invoke your connection object's getMetaData( ) method and use the resulting DatabaseMetaData object to retrieve the information you want. Here's how to list the tables in a given database: // get list of tables in database named by dbName; if // dbName is the empty string, the current database is used DatabaseMetaData md = conn.getMetaData ( ); ResultSet rs = md.getTables (dbName, "", "%", null); while (rs.next ( )) System.out.println (rs.getString (3)); // column 3 = table name rs.close ( ); A similar procedure produces a list of databases: // get list of databases DatabaseMetaData md = conn.getMetaData ( ); ResultSet rs = md.getCatalogs ( ); while (rs.next ( )) System.out.println (rs.getString (1)); // column 1 = database name rs.close ( ); 9.11 Testing Whether a Table Exists 9.11.1 Problem You want to know whether a table exists. 9.11.2 Solution Use SHOW TABLES to see if the table is listed. 9.11.3 Discussion You can use the SHOW TABLES statement to test whether a specific table exists by adding a LIKE clause that matches the name of the table: SHOW TABLES LIKE 'tbl_name'; SHOW TABLES FROM db_name LIKE 'tbl_name'; If you get a row back, the table exists. If not, it doesn't. Here's a Perl function that performs an existence test for a table: sub table_exists { my ($dbh, $tbl_name) = @_; my $db_clause = ""; ($db_clause, $tbl_name) = (" FROM $1", $2) if $tbl_name =~ /(.*)\.(.*)/; $tbl_name =~ s/([%_])/\\$1/g; # escape any special characters return ($dbh->selectrow_array ("SHOW TABLES $db_clause LIKE '$tbl_name'")); } The function checks the table name argument to see if it's in db_name.tbl_name form. If so, it strips off the database name and uses it to add a FROM clause to the statement. Otherwise, the test is against the current database. Note that the function returns false if the table exists but you have no privileges for accessing it. There are other ways to check whether or not a table exists besides SHOW TABLES. Either of the following SELECT statements will execute successfully if the table exists, and fail if it does not: SELECT * FROM tbl_name WHERE 1=0; SELECT COUNT(*) FROM tbl_name; To use these statements within a program, first set your API's error trapping not to terminate your program on an error. Then attempt to execute the statement and test whether it succeed or fails. The SELECT * statement is preferable to SELECT COUNT(*) for some table types such as BDB or InnoDB, which require a full table scan to evaluate COUNT(*). For ISAM and MyISAM tables, the COUNT(*) statement is optimized to use the record count stored in the table. 9.12 Testing Whether a Database Exists 9.12.1 Problem You want to know whether a database exists. 9.12.2 Solution Use SHOW DATABASES to see if the table is listed. 9.12.3 Discussion SHOW DATABASES can be used to determine whether a database exists if you add a LIKE clause that matches the database name: SHOW DATABASES LIKE 'db_name'; The following Perl function shows how to do this: sub database_exists { my ($dbh, $db_name) = @_; $db_name =~ s/([%_])/\\$1/g; # escape any special characters return ($dbh->selectrow_array ("SHOW DATABASES LIKE '$db_name'")); } The function returns false if the database exists but the server was started with the --skip- show-database option and you don't have MySQL root user privileges. 9.13 Getting Server Metadata 9.13.1 Problem You want to the MySQL server to tell you about itself. 9.13.2 Solution Several SELECT and SHOW statements return information about the server. 9.13.3 Discussion MySQL offers several SQL statements that provide you with information about the server itself and about your current client connection. A few that you may find useful are listed here. To obtain the information provided by any of them, issue the query, then process the result set to retrieve the query output. Both SHOW statements allow a LIKE 'pattern' clause for limiting the results only to those rows matching the pattern. Statement Information produced by statement SELECT VERSION( ) Server version string SELECT DATABASE( ) Current database name (empty if none) SELECT USER( ) Current username SHOW STATUS Server status indicators SHOW VARIABLES Server configuration variables These queries are all MySQL-specific. If you're working in Java, JDBC provides several database-independent methods for obtaining server metadata, some of which provide the same information as some of the preceding statements. Use your connection object to obtain the database metadata, then invoke the appropriate methods to get the information in which you're interested. You should consult a JDBC reference for a complete list, but here are a few representative examples: DatabaseMetaData md = conn.getMetaData ( ); // can also get this with SELECT VERSION( ) System.out.println ("Product version: " + md.getDatabaseProductVersion ( )); // this is similar to SELECT USER( ) but doesn't include the hostname System.out.println ("Username: " + md.getUserName ( )); 9.14 Writing Applications That Adapt to the MySQL Server Version 9.14.1 Problem You want to use a given feature that is only available as of a particular version of MySQL. 9.14.2 Solution Ask the server for its version number. If the server is too old, maybe you can fall back to a workaround for the missing feature, if one exists. 9.14.3 Discussion If you're writing an application that can perform certain functions only if the MySQL server supports the necessary underlying operations, the server version number allows you to determine whether those operations are available (or whether you need to perform some sort of workaround, assuming there is one). To get the server version, issue a SELECT VERSION( ) statement. The result is a string that looks something like 3.23.27-gamma. In other words, it returns a string consisting of major, minor, and "teeny" version numbers, and possibly some suffix. The version string can be used as is for presentation purposes if you want to produce a status display for the user. However, for comparisons, it's simpler to work with a number—in particular, a 5-digit number in Mmmtt format, where M, mm, tt are the major, minor, and teeny version numbers. The conversion can be performed by splitting the string at the periods, stripping off from the third piece the suffix that begins with the first non-numeric character, and then joining the pieces.[4] [4] My first attempt at the conversion algorithm was to break the version string at periods, then to strip the suffix from the third piece beginning with the - character. That algorithm failed with the release of MySQL 3.23.29a-gamma. (Stripping -gamma from 29a-gamma leaves 29a, which is not a number.) Here's a DBI function that takes a database handle argument and returns a two-element list containing both the string and numeric forms of the server version. The code assumes that the minor and teeny version parts are less than 100 and thus no more than two digits each. That should be a valid assumption, because the source code for MySQL itself uses the same format. sub get_server_version { my $dbh = shift; my ($ver_str, $ver_num); my ($major, $minor, $teeny); # fetch result into scalar string $ver_str = $dbh->selectrow_array ("SELECT VERSION( )"); return undef unless defined ($ver_str); ($major, $minor, $teeny) = split (/\./, $ver_str); $teeny =~ s/\D*$//; # strip any non-numeric suffix if present $ver_num = $major*10000 + $minor*100 + $teeny; return ($ver_str, $ver_num); } To get both forms of the version information at once, call the function like this: my ($ver_str, $ver_num) = get_server_version ($dbh); To get just one of the values, call it as follows: my $ver_str = (get_server_version ($dbh))[0]; # string form my $ver_num = (get_server_version ($dbh))[1]; # numeric form The following examples demonstrate how to use the numeric version value to check whether the server supports certain features: my $ver_num = (get_server_version ($dbh))[1]; printf "GET_LOCK( )/RELEASE_LOCK( ): %s\n", ($ver_num >= 32127 ? "yes" : "no"); printf "Functional GRANT statement: %s\n", ($ver_num >= 32211 ? "yes" : "no"); printf "Temporary tables: %s\n", ($ver_num >= 32302 ? "yes" : "no"); printf "Quoted identifiers: %s\n", ($ver_num >= 32306 ? "yes" : "no"); printf "UNION statement: %s\n", ($ver_num >= 40000 ? "yes" : "no"); printf "Subselects: %s\n", ($ver_num >= 40100 ? "yes" : "no"); 9.15 Determining the Current Database 9.15.1 Problem Has any database been selected as the current database? What is its name? 9.15.2 Solution Use the DATABASE( ) function. 9.15.3 Discussion SELECT DATABASE( ) returns the name of the current database, or the empty string if no database has been selected. This Python code uses the statement to present a status display containing information about the current connection: cursor = conn.cursor ( ) cursor.execute ("SELECT DATABASE( )") row = cursor.fetchone ( ) cursor.close if row == None or len (row) == 0 or row[0] == "": db = "(no database selected)" else: db = row[0] print "Current database:", db 9.16 Determining the Current MySQL User 9.16.1 Problem What is the name of the client user and from what host was the connection made? 9.16.2 Solution Use the USER( ) function. 9.16.3 Discussion SELECT USER( ) returns a string in the form user@host, indicating the name of the current user and the host from which the user connected.[5] To select just the name or host parts, use these queries: [5] Prior to MySQL 3.22.1, the value of USER( ) does not include the @host part. SELECT SUBSTRING_INDEX(USER( ),'@',1); SELECT SUBSTRING_INDEX(USER( ),'@',-1); You can use this information in various ways. For example, to have a Perl application greet the user, you could do something like this: my ($user, $host) = $dbh->selectrow_array (q{ SELECT SUBSTRING_INDEX(USER( ),'@',1), SUBSTRING_INDEX(USER( ),'@',-1) }); print "Hello, $user! Good to see you.\n"; print "I see you're connecting from $host.\n" unless $host eq ""; Alternatively, you could simply retrieve the entire USER( ) value and break it apart by using a pattern-match operation: my ($user, $host) = ($dbh->selectrow_array ( "SELECT USER( )") =~ /([^@]+)@?(.*)/); Or by splitting it: my ($user, $host) = split (/@/, $dbh->selectrow_array ("SELECT USER( )")); Another application for USER( ) values is to maintain a log of who's using an application. A simple log table might look like this (the values 16 and 60 reflect the lengths of the user and host columns in the MySQL grant tables): CREATE TABLE app_log ( t TIMESTAMP, user CHAR(16), host CHAR(60) ); To insert new records into the app_log table, use the following statement. The TIMESTAMP column gets set automatically to the current date and time; there's no need to specify a value for it. INSERT INTO app_log SET user = SUBSTRING_INDEX(USER( ),'@',1), host = SUBSTRING_INDEX(USER( ),'@',-1); The table stores the user and host values separately because it's more efficient to run summary queries against those values when you don't have to break them apart. For example, if you check periodically how many distinct hosts you're getting connections from, it's better to split the USER( ) value once when you create the record than to split the value each time you issue a SELECT to generate the summary. Also, you can index the host column if you store host values separately, which you can't do if you store combined user@host values. 9.17 Monitoring the MySQL Server 9.17.1 Problem You want to find out how the server was configured or monitor its state. 9.17.2 Solution SHOW VARIABLES and SHOW STATUS are useful for this. 9.17.3 Discussion The SHOW VARIABLES and SHOW STATUS statements provide server configuration and performance information: mysql> SHOW VARIABLES; +---------------------------------+-------------------+ | Variable_name | Value | +---------------------------------+-------------------+ | back_log | 50 | | basedir | /usr/local/mysql/ | | bdb_cache_size | 8388600 | | bdb_log_buffer_size | 0 | | bdb_home | | ... mysql> SHOW STATUS; +--------------------------+----------+ | Variable_name | Value | +--------------------------+----------+ | Aborted_clients | 319 | | Aborted_connects | 22 | | Bytes_received | 32085033 | | Bytes_sent | 26379272 | | Connections | 65684 | ... This information can be useful for writing administrative applications. For example, you might write a long-running program that probes the server periodically to monitor its activity. A simple application of this type might ask the server to report the number of connections it's received and its uptime, to determine a running display of average connection activity. The queries to obtain this information are: SHOW STATUS LIKE 'Connections'; SHOW STATUS LIKE 'Uptime'; If you want to avoid having to reconnect each time you issue the queries, you can ask the server for its client timeout period and probe it at intervals shorter than that value. You can get the timeout value (in seconds) with this query: SHOW VARIABLES LIKE 'wait_timeout'; The default value is 28800 (8 hours), but it may be different on your system. The "MySQL Uncertainty Principle" Heisenberg's uncertainty principle for measurement of quantum phenomena has a MySQL analog. If you monitor MySQL's status to see how it changes over time, you may notice a curious effect for some of the indicators: Each time you take a measurement, you change the value you're measuring! For example, you can determine the number of queries the server has received by using the following statement: SHOW STATUS LIKE 'Questions' However, that statement is itself a query, so each time you issue it, you cause the Questions value to change. In effect, your performance assessment instrument contaminates its own measurements, something you may want to take into account. 9.18 Determining Which Table Types the Server Supports 9.18.1 Problem You want to know whether you can create a table using a given table type. 9.18.2 Solution Ask the server which table types it supports. 9.18.3 Discussion SHOW VARIABLES can tell you whether or not certain table types are available. For example, you can test the have_bdb, have_innodb, and have_gemini variables to see if the server supports transaction-safe tables. The following PHP code demonstrates how to check for a value of YES for the have_bdb variable, using a two-stage approach. First, make sure that the variable exists by testing for a nonempty result set. (The variable will not be present at all if your version of MySQL predates the inclusion of support for the table type.) Then, fetch the variable's value to see if it's YES: $avail = FALSE; # escape the variable name properly $var_name = ereg_replace ("([%_])", "\\\\1", "have_bdb"); if ($result_id = mysql_query ("SHOW VARIABLES LIKE '$var_name'", $conn_id)) { if ($row = mysql_fetch_row ($result_id)) $avail = ($row[1] == "YES" ? TRUE : FALSE); mysql_free_result ($result_id); } After this code executes, $avail will be TRUE or FALSE to indicate whether the server supports BDB tables. To check for a different table type, modify the code to test the appropriate server variable name. A more general approach is to write a function that checks for all known handlers and returns a list of the ones that are supported. You cannot ask the server for a list of types directly, but if you know what the possible types are, you can determine which of them are supported using the following rules: · Prior to MySQL 3.23, only the ISAM type is available. · As of MySQL 3.23, MyISAM is always available. Other table handlers may also be available. For the ISAM, BDB, and Gemini types, check the have_isam, have_bdb, and have_gemini server variables (look for a value of YES). InnoDB table availability is indicated by have_innodb. However, that variable was at one time called have_innobase; for completeness, check them both. These rules are implemented by the Perl function get_table_handlers( ) shown below. It returns a list containing the words drawn from the list bdb, gemini, innodb, isam, and myisam, corresponding to those table types that are found to be supported: sub get_table_handlers { my $dbh = shift; my @types; my %typemap = ( "have_bdb" => "bdb", "have_gemini" => "gemini", "have_innodb" => "innodb", "have_innobase" => "innodb", # obsolete form of have_innodb "have_isam" => "isam" ); # get server version number my $ver_num = (get_server_version ($dbh))[1]; # numeric form if ($ver_num < 32300) # only ISAM available prior to 3.23.xx { @types = ("isam"); } else { @types = ("myisam"); # MyISAM always available as of 3.23.xx # Issue SHOW VARIABLES query to get the 'have_' server variables # that indicate presence of table handlers. (There are some 'have_' # variables that don't pertain to table types, but it's still more # efficient to issue a single query than a query for each variable.) my $sth = $dbh->prepare ("SHOW VARIABLES LIKE 'have\\_%'"); $sth->execute ( ); while (my ($var, $val) = $sth->fetchrow_array ( )) { push (@types, $typemap{$var}) if exists ($typemap{$var}) && $val eq "YES"; } } return (sort (@types)); Chapter 10. Importing and Exporting Data Introduction Importing Data with LOAD DATA and mysqlimport Specifying the Datafile Location Specifying the Datafile Format Dealing with Quotes and Special Characters Importing CSV Files Reading Files from Different Operating Systems Handling Duplicate Index Values Getting LOAD DATA to Cough Up More Information Don't Assume LOAD DATA Knows More than It Does Skipping Datafile Lines Specifying Input Column Order Skipping Datafile Columns Exporting Query Results from MySQL Exporting Tables as Raw Data Exporting Table Contents or Definitions in SQL Format Copying Tables or Databases to Another Server Writing Your Own Export Programs Converting Datafiles from One Format to Another Extracting and Rearranging Datafile Columns Validating and Transforming Data Validation by Direct Comparison Validation by Pattern Matching Using Patterns to Match Broad Content Types Using Patterns to Match Numeric Values Using Patterns to Match Dates or Times Using Patterns to Match Email Addresses and URLs Validation Using Table Metadata Validation Using a Lookup Table Converting Two-Digit Year Values to Four-Digit Form Performing Validity Checking on Date or Time Subparts Writing Date-Processing Utilities Using Dates with Missing Components Performing Date Conversion Using SQL Using Temporary Tables for Data Transformation Dealing with NULL Values Guessing Table Structure from a Datafile A LOAD DATA Diagnostic Utility Exchanging Data Between MySQL and Microsoft Access Exchanging Data Between MySQL and Microsoft Excel Exchanging Data Between MySQL and FileMaker Pro Exporting Query Results as XML Importing XML into MySQL Epilog 10.1 Introduction Suppose you have a file named somedata.csv that contains 12 columns of data in comma- separated values (CSV) format. From this file you want to extract only columns 2, 11, 5, and 9, and use them to create database records in a MySQL table that contains name, birth, height, and weight columns. You need to make sure that the height and weight are positive integers, and convert the birth dates from MM/DD/YY format to CCYY-MM-DD format. How can you do this? In one sense, that problem is very specialized. But in another, it's not at all atypical, because data transfer problems with specific requirements occur frequently when transferring data into MySQL. It would be nice if datafiles were always nicely formatted and ready to load into MySQL with no preparation, but that is frequently not so. As a result, it's often necessary to preprocess information to put it into a format that MySQL finds acceptable. The reverse also is true; data exported from MySQL may need massaging to be useful for other programs. Some data transfer operations are so difficult that they require a great deal of hand checking and reformatting, but in most cases, you can do at least part of the job automatically. Virtually all transfer problems involve at least some elements of a common set of conversion issues. This chapter discusses what these issues are, how to deal with them by taking advantage of the existing tools at your disposal, and how to write your own tools when necessary. The idea is not to cover all possible import and export situations (an impossible task), but to show some representative techniques and utilities, You can use them as is, or adapt them for problems that they don't handle. (There are also commercial conversion tools that may assist you, but my purpose here is to help you do things yourself.) The first recipes in the chapter cover MySQL's native facilities for importing data (the LOAD DATA statement and the mysqlimport command-line program), and for exporting data (the SELECT ... INTO OUTFILE statement and the mysqldump program). For operations that don't require any data validation or reformatting, these facilities often are sufficient. For situations where MySQL's native import and export capabilities do not suffice, the chapter moves on to cover techniques for using external supporting utilities and for writing your own. To some extent, you can avoid writing your own tools by using existing programs. For example, cut can extract columns from a file, and sed and tr can be used as postprocessors to convert query output into other formats. But you'll probably eventually reach the point where you decide to write your own programs. When you do, there are two broad sets of issues to consider: · How to manipulate the structure of datafiles. When a file is in a format that isn't suitable for import, you'll need to convert it to a different format. This many involve issues such as changing the column delimiters or line-ending sequences, or removing or rearranging columns in the file. · How to manipulate the content of datafiles. If you don't know whether the values contained in a file are legal, you may want to preprocess it to check or reformat them. Numeric values may need to be verified as lying within a specific range, dates may need to be converted to or from ISO format, and so forth. Source code for the program fragments and scripts discussed in this chapter is located in the transfer directory of the recipes distribution, with the exception that some of the utility functions are contained in library files located in the lib directory. The code for some of the shorter utilities is shown in full. For the longer ones, the chapter generally discusses only how they work and how to use them, but you have access to the source if you wish to investigate in more detail how they're written. The problems addressed in this chapter involve a lot of text processing and pattern matching. These are particular strengths of Perl, so the program fragments and utilities shown here are written mainly in Perl. PHP and Python provide pattern-matching capabilities, too, so they can of course do many of the same things. If you want to adapt the techniques described here for Java, you'll need to get a library that provides classes for regular expression-based pattern matching. See Appendix A for suggestions. 10.1.1 General Import and Export Issues Incompatible datafile formats and differing rules for interpreting various kinds of values lead to many headaches when transferring data between programs. Nevertheless, certain issues recur frequently. By being aware of them, you'll be able to identify more easily just what you need to do to solve particular import or export problems. In its most basic form, an input stream is just a set of bytes with no particular meaning. Successful import into MySQL requires being able to recognize which bytes represent structural information, and which represent the data values framed by that structure. Because such recognition is key to decomposing the input into appropriate units, the most fundamental import issues are these: · What is the record separator? Knowing this allows the input stream to be partitioned into records. · What is the field delimiter? Knowing this allows each record to be partitioned into field values. Recovering the original data values also may include stripping off quotes from around the values or recognizing escape sequences within them. The ability to break apart the input into records and fields is important for extracting the data values from it. However, the values still might not be in a form that can be used directly, and you may need to consider other issues: · Do the order and number of columns match the structure of the database table? Mismatches require columns to be rearranged or skipped. · Do data values need to be validated or reformatted? If the values are in a format that matches MySQL's expectations, no further processing is necessary. Otherwise, they need to be checked and possibly rewritten. · How should NULL or empty values be handled? Are they allowed? Can NULL values even be detected? (Some systems export NULL values as empty strings, making it impossible to distinguish one from the other.) For export from MySQL, the issues are somewhat the reverse. You probably can assume that values stored in the database are valid, but they may require reformatting, and it's necessary to add column and record delimiters to form an output stream that has a structure another program can recognize. The chapter deals with these issues primarily within the context of performing bulk transfers of entire files, but many of the techniques discussed here can be applied in other situations as well. Consider a web-based application that presents a form for a user to fill in, then processes its contents to create a new record in the database. That is a data import situation. Web APIs generally make form contents available as a set of already-parsed discrete values, so the application may not need to deal with record and column delimiters, On the other hand, validation issues remain paramount. You really have no idea what kind of values a user is sending your script, so it's important to check them. 10.1.2 File Formats Datafiles come in many formats, two of which are used frequently in this chapter: · Tab-delimited format. This is one of the simplest file structures; lines contain values separated by tab characters. A short tab-delimited file might look like this, where the whitespace between column values represents single tab characters: · a b c a,b,c d e f · Comma-separated values (CSV) format. Files written in CSV format vary somewhat, because there is apparently no actual standard describing the format. However, the general idea is that lines consist of values separated by commas, and values containing internal commas are surrounded by quotes to prevent the commas from being interpreted as value delimiters. It's also common for values containing spaces to be quoted as well. Here is an example, where each line contains three values: · a,b,c "a,b,c","d e",f It's trickier to process CSV files than tab-delimited files, because characters like quotes and commas have a dual meaning: they may represent file structure or be part of data values. Another important datafile characteristic is the line-ending sequence. The most common sequences are carriage returns, linefeeds, and carriage return/linefeed pairs, sometimes referred to here by the abbreviations CR, LF, and CRLF. Datafiles often begin with a row of column labels. In fact, a CSV file that begins with a row of names is what FileMaker Pro refers to as merge format. For some import operations, the row of labels is an annoyance because you must discard it to avoid having the labels be loaded into your table as a data record. But in other cases, the labels are quite useful: · For import into existing tables, the labels can be used to match up datafile columns with the table columns if they are not necessarily in the same order. · The labels can be used for column names when creating a new table automatically or semi-automatically from a datafile. For example, Recipe 10.37 later in the chapter discusses a utility that examines a datafile and guesses the CREATE TABLE statement that should be used to create a table from the file. If a label row is present, the utility uses them for column names. Otherwise, it's necessary to make up generic names like c1, c2, and so forth, which isn't very descriptive. Tab-Delimited, Linefeed-Terminated Format Although datafiles may be written in many formats, it's unlikely that you'll want to include machinery for reading several different formats within each file-processing utility that you write. I don't want to, either, so for that reason, many of the utilities described in this chapter assume for simplicity that their input is in tab-delimited, linefeed-terminated format. (This is also the default format for MySQL's LOAD DATA statement.) By making this assumption, it becomes easier to write programs that read files. On the other hand, something has to be able to read data in other formats. To handle that problem, we'll develop a cvt_file.pl script that can read or write several types of files. (See Recipe 10.19.) The script is based on the Perl Text::CSV_XS module, which despite its name can be used for more than just CSV data. cvt_file.pl can convert between many file types, making it possible for other programs that require tab-delimited lines to be used with files not originally written in that format. 10.1.3 Notes on Invoking Shell Commands This chapter shows a number of programs that you invoke from the command line using a shell like bash or tcsh under Unix or CMD.EXE ("the DOS prompt") under Windows. Many of the example commands for these programs use quotes around option values, and sometimes an option value is itself a quote character. Quoting conventions vary from one shell to another, but rules that seem to work with most of them (including CMD.EXE under Windows) are as follows: · For an argument that contains spaces, surround it with double quotes to prevent the shell from interpreting it as multiple separate arguments. The shell will strip off the quotes, then pass the argument to the command intact. · To include a double quote character in the argument itself, precede it with a backslash. Some shell commands are so long that they're shown as you would enter them using several lines, with a backslash character as the line-continuation character: % prog_name \ argument1 \ argument2 ... That works for Unix, but not for Windows, where you'll need to omit the continuation characters and type the entire command on one line: C:\> prog_name argument1 argument2 ... 10.2 Importing Data with LOAD DATA and mysqlimport 10.2.1 Problem You want to load a datafile into a table using MySQL's built in import capabilities. 10.2.2 Solution Use the LOAD DATA statement or the mysqlimport command-line program. 10.2.3 Discussion MySQL provides a LOAD DATA statement that acts as a bulk data loader. Here's an example statement that reads a file mytbl.txt from your current directory and loads it into the table mytbl in the current database: mysql> LOAD DATA LOCAL INFILE 'mytbl.txt' INTO TABLE mytbl; MySQL also includes a utility program named mysqlimport that acts as a wrapper around LOAD DATA so that you can load input files directly from the command line. The mysqlimport command that is equivalent to the preceding LOAD DATA statement looks like this, assuming that mytbl is in the cookbook database:[1] [1] For mysqlimport, as with other MySQL programs, you may need to specify connection parameter options such as --user or --host. If so, they should precede the database name argument. % mysqlimport --local cookbook mytbl.txt The following list describes LOAD DATA's general characteristics and capabilities; mysqlimport shares most of these behaviors. There are some differences that we'll note as we go along, but for the most part you can read "LOAD DATA" as "LOAD DATA or mysqlimport." LOAD DATA provides options to address many of the import issues mentioned in the chapter introduction, such as the line-ending sequence for recognizing how to break input into records, the column value delimiter that allows records to be broken into separate values, the quoting character that may surround column values, quoting and escaping issues within values, and NULL value representation: · By default, LOAD DATA expects the datafile to contain the same number of columns as the table into which you're loading data, and the datafile columns must be present in the same order as in the table. If the file doesn't contain a value for every column or the values aren't in the proper order, you can specify which columns are present and the order in which they appear. If the datafile contains fewer columns than the table, MySQL assigns default values to columns for which no values are present in the datafile. · LOAD DATA assumes that data values are separated by tab characters and that lines end with linefeeds (newlines). You can specify the data format explicitly if a file doesn't conform to these conventions. · You can indicate that data values may have quotes around them that should be stripped, and you can specify what the quote character is. · Several special escape sequences are recognized and converted during input processing. The default escape character is backslash (\), but you can change it if you like. The \N sequence is taken to represent a NULL value. The \b, \n, \r, \t, \\, and \0 sequences are interpreted as backspace, linefeed, carriage return, tab, backslash, and ASCII NUL characters. (NUL is a zero-valued byte, which is different than the SQL NULL value.) · LOAD DATA provides diagnostic information, but it's a summary that doesn't give you specific information about which input lines may have caused problems. There is work in progress for MySQL 4 on providing improved feedback. In the meantime, see Recipe 10.38, which describes a LOAD DATA diagnostic utility. The next few sections describe how to import datafiles into MySQL tables using LOAD DATA or mysqlimport. They assume your files contain legal data values that are acceptable to MySQL. Why make this assumption? Because although LOAD DATA has several options that control how it reads the datafile, they're concerned only with the structure of the file. LOAD DATA won't validate or reformat data values for you. It's necessary to perform such operations either by preprocessing the datafile before loading it, or by issuing SQL statements after loading it. If you need to check or reformat an input file first to make sure it's legal, several sections later in the chapter show how to do that. 10.3 Specifying the Datafile Location 10.3.1 Problem You're not sure how to tell LOAD DATA where to look for your datafile, particularly if it's located in another directory. 10.3.2 Solution It's a matter of knowing the rules that determine where MySQL looks for the file. 10.3.3 Discussion When you issue a LOAD DATA statement, the MySQL server normally assumes the datafile is located on the server host. However, you may not be able to load data that way: · If you access the MySQL server from a remote client host and have no means of transferring your file to the server host (such as a login account there), you won't be able to put the file on the server. · Even if you have a login account on the server host, your MySQL account must be enabled with the FILE privilege, and the file to be loaded must be either world readable or located in the data directory for the current database. Most MySQL users do not have the FILE privilege (because it allows you to do dangerous things), and you may not want to make the file world readable (for security reasons) or be able to put it in the database directory. Fortunately, if you have MySQL 3.22.15 or later, you can load local files that are located on the client host by using LOAD DATA LOCAL rather than LOAD DATA. The only permission you need to import a local file is the ability to read the file yourself.[2] [2] As of MySQL 3.23.49, use of the LOCAL keyword may be disabled by default. You may be able to turn it on using the --local-infile option for mysql. If that doesn't work, your server has been configured not to allow LOAD DATA LOCAL at all. If the LOCAL keyword is not present, MySQL looks for the datafile on the server host using the following rules: · An absolute pathname fully specifies the location of the file, beginning from the root of the filesystem. MySQL reads the file from the given location. · A relative pathname is interpreted two ways, depending on whether it has a single component or multiple components. For a single-component filename like mytbl.txt, MySQL looks for the file in the database directory for the current database. For a multiple-component filename like xyz/mytbl.txt, MySQL looks for the file beginning in the MySQL data directory. (It expects to find mytbl.txt in a directory named xyz.) Database directories are located directly under the data directory, so these two statements are equivalent if the current database is cookbook: mysql> LOAD DATA INFILE 'mytbl.txt' INTO TABLE mytbl; mysql> LOAD DATA INFILE 'cookbook/mytbl.txt' INTO TABLE mytbl; If the LOCAL keyword is specified, MySQL looks for the file on the client host, and interprets the pathname the same way your command interpreter does: · An absolute pathname fully specifies the location of the file, beginning from the root of the filesystem. · A relative pathname is interpreted relative to your current directory. If your file is located on the client host, but you forget to indicate that it's local, you'll get an error. mysql> LOAD DATA 'mytbl.txt' INTO TABLE mytbl; ERROR 1045: Access denied for user: 'cbuser@localhost' (Using password: YES) That Access denied message can be confusing, given that if you're able to connect to the server and issue the LOAD DATA statement, it would seem that you've already gained access to MySQL. What the error message means is that the MySQL tried to open mytbl.txt on the server host and could not access it. mysqlimport uses the same rules for finding files as LOAD DATA. By default, it assumes the datafile is located on the server host. To use a local file, specify the --local (or -L) option on the command line. LOAD DATA assumes the table is located in the current database unless you specify the database name explicitly. mysqlimport always requires a database argument: % mysqlimport --local cookbook mytbl.txt If you want to use LOAD DATA to load a file into a database other than the current one, you can qualify the table name with the database name. The following statement does this, indicating that the mytbl table is located in the other_db database: mysql> LOAD DATA LOCAL 'mytbl.txt' INTO TABLE other_db.mytbl; LOAD DATA assumes no relationship between the name of the datafile and the name of the table into which you're loading the file's contents. mysqlimport assumes a fixed relationship between the datafile name and the table name. Specifically, it uses the last component of the filename to determine the table name. For example, mysqlimport would interpret mytbl.txt, mytbl.dat, /tmp/mytbl.txt, /u/paul/data/mytbl.csv, and D:\projects\mytbl.txt all as files containing data for the mytbl table. Naming Datafiles Under Windows Windows systems use \ as the pathname separator in filenames. That's a bit of a problem, because MySQL interprets backslash as the escape character in string values. To specify a Windows pathname, either use doubled backslashes, or use forward slashes instead. These two statements show two ways of referring to the same Windows file: mysql> LOAD DATA LOCAL INFILE 'D:\\projects\\mydata.txt' INTO mytbl; mysql> LOAD DATA LOCAL INFILE 'D:/projects/mydata.txt' INTO mytbl; 10.4 Specifying the Datafile Format 10.4.1 Problem You have a datafile that's not in LOAD DATA's default format. 10.4.2 Solution Use FIELDS and LINES clauses to tell LOAD DATA how to interpret the file. 10.4.3 Discussion By default, LOAD DATA assumes that datafiles contain lines that are terminated by linefeeds (newlines) and that data values within a line are separated by tabs. The following statement does not specify anything about the format of the datafile, so MySQL assumes the default format: mysql> LOAD DATA LOCAL INFILE 'mytbl.txt' INTO TABLE mytbl; To specify a file format explicitly, use a FIELDS clause to describe the characteristics of fields within a line, and a LINES clause to specify the line-ending sequence. The following LOAD DATA statement specifies that the datafile contains values separated by colons and lines terminated by carriage returns: mysql> LOAD DATA LOCAL INFILE 'mytbl.txt' INTO TABLE mytbl -> FIELDS TERMINATED BY ':' -> LINES TERMINATED BY '\r'; Each clause follows the table name. If both are present, the FIELDS clause must precede the LINES clause. The line and field termination indicators can contain multiple characters. For example, \r\n indicates that lines are terminated by carriage return/linefeed pairs. If you use mysqlimport, command-line options provide the format specifiers. mysqlimport commands that correspond to the preceding two LOAD DATA statements look like this: % mysqlimport --local cookbook mytbl.txt % mysqlimport --local --fields-terminated-by=":" --lines-terminated-by="\r" \ cookbook mytbl.txt The order in which you specify the options doesn't matter for mysqlimport, except that they should all precede the database name. Specifying Binary Format Option Characters As of MySQL 3.22.10, you can use hex notation to specify arbitrary format characters for FIELDS and LINES clauses. Suppose a datafile has lines with Ctrl-A between fields and Ctrl-B at the end of lines. The ASCII values for Ctrl-A and Ctrl-B are 1 and 2, so you represent them as 0x01 and 0x02: FIELDS TERMINATED BY 0x01 LINES TERMINATED BY 0x02 mysqlimport understands hex constants for format specifiers as of MySQL 3.23.30. You may find this capability helpful if you don't like remembering how to type escape sequences on the command line or when it's necessary to use quotes around them. Tab is 0x09, linefeed is 0x0a, and carriage return is 0x0d. Here's an example that indicates that the datafile contains tab-delimited lines terminated by CRLF pairs: % mysqlimport --local --lines-terminated-by=0x0d0a \ --fields-terminated-by=0x09 cookbook mytbl.txt 10.5 Dealing with Quotes and Special Characters 10.5.1 Problem Your datafile contains quoted values or escaped characters. 10.5.2 Solution Tell LOAD DATA to be aware of them so that it doesn't load the values into the database uninterpreted. 10.5.3 Discussion The FIELDS clause can specify other format options besides TERMINATED BY. By default, LOAD DATA assumes that values are unquoted, and interprets the backslash (\) as an escape character for special characters. To indicate the value quoting character explicitly, use ENCLOSED BY; MySQL will strip that character from the ends of data values during input processing. To change the default escape character, use ESCAPED BY. The three subclauses of the FIELDS clause (ENCLOSED BY, ESCAPED BY, and TERMINATED BY) may be present in any order if you specify more than one of them. For example, these FIELDS clauses are equivalent: FIELDS TERMINATED BY ',' ENCLOSED BY '"' FIELDS ENCLOSED BY '"' TERMINATED BY ',' The TERMINATED BY sequence can consist of multiple characters. If data values are separated within input lines by something like *@*, you'd indicate that like this: FIELDS TERMINATED BY '*@*' To disable escape processing entirely, specify an empty escape sequence: FIELDS ESCAPED BY '' When you specify ENCLOSED BY to indicate that quote characters should be stripped from data values, it's possible to include the quote character literally within data values by doubling it or by preceding it with the escape character. For example, if the quote and escape characters are " and \, the input value "a""b\"c" will be interpreted as a"b"c. For mysqlimport, the corresponding command-line options for specifying quote and escape values are --fields-enclosed-by and --fields-escaped-by. (When using mysqlimport options that include quotes or backslashes or other characters that are special to your command interpreter, remember that you may need to quote or escape the quote or escape characters!) 10.6 Importing CSV Files 10.6.1 Problem You need to load a file that is in CSV format. 10.6.2 Solution Just add the appropriate format-specifier clauses to your LOAD DATA statement. 10.6.3 Discussion Datafiles in CSV format contain values that are delimited by commas rather than tabs and that may be quoted with double quote characters. For example, a CSV file mytbl.txt containing lines that end with carriage return/linefeed pairs can be loaded into mytbl as follows using LOAD DATA: mysql> LOAD DATA LOCAL INFILE 'mytbl.txt' INTO TABLE mytbl -> FIELDS TERMINATED BY ',' ENCLOSED BY '"' -> LINES TERMINATED BY '\r\n'; Or like this using mysqlimport: % mysqlimport --local --lines-terminated-by="\r\n" \ --fields-terminated-by="," --fields-enclosed-by="\"" \ cookbook mytbl.txt 10.7 Reading Files from Different Operating Systems 10.7.1 Problem Different operating systems use different line-ending sequences. 10.7.2 Solution That's why LOAD DATA has a LINES TERMINATED BY clause. 10.7.3 Discussion The line-ending sequence used in a datafile typically is determined by the system on which the file originates, not the system on which you import it. Keep this in mind when loading a file that is obtained from a different system. Unix files normally have lines terminated by linefeeds, which you can indicate in a LOAD DATA statement like this: LINES TERMINATED BY '\n' However, because \n happens to be the default line terminator for LOAD DATA, you don't need to specify a LINES TERMINATED BY clause in this case unless you want to indicate explicitly what the line ending sequence is. Files created under Mac OS or Windows usually have lines ending in carriage returns or carriage return/linefeed pairs. To handle these different kinds of line endings, use the appropriate LINES TERMINATED BY clause: LINES TERMINATED BY '\r' LINES TERMINATED BY '\r\n' For example, to load a Windows file that contains tab-delimited fields and lines ending with CRLF pairs, use this LOAD DATA statement: mysql> LOAD DATA LOCAL INFILE 'mytbl.txt' INTO TABLE mytbl -> LINES TERMINATED BY '\r\n'; The corresponding mysqlimport command is: % mysqlimport --local --lines-terminated-by="\r\n" cookbook mytbl.txt 10.8 Handling Duplicate Index Values 10.8.1 Problem Your input contains records that duplicate the values of unique keys in existing table records. 10.8.2 Solution Tell LOAD DATA to ignore the new records, or to replace the old ones. 10.8.3 Discussion By default, an error occurs if you attempt to load a record that duplicates an existing record in the column or columns that form a PRIMARY KEY or UNIQUE index. To control this behavior, specify IGNORE or REPLACE after the filename to tell MySQL to either ignore duplicate records or to replace old records with the new ones. Suppose you periodically receive meteorological data about current weather conditions from various monitoring stations, and that you store measurements of various types from these stations in a table that looks like this: CREATE TABLE weatherdata ( station INT UNSIGNED NOT NULL, type ENUM('precip','temp','cloudiness','humidity','barometer') NOT NULL, value FLOAT, UNIQUE (station, type) ); To make sure that you have only one record for each station for each type of measurement, the table includes a unique key on the combination of station ID and measurement type. The table is intended to hold