MySQL
  Home arrow MySQL arrow Page 3 - Planned Improvements in MySQL 5.1
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Moblin 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
MYSQL

Planned Improvements in MySQL 5.1
By: Apress Publishing
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 7
    2006-05-18

    Table of Contents:
  • Planned Improvements in MySQL 5.1
  • Trigger Syntax
  • Other Expected Improvements
  • Summary

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Planned Improvements in MySQL 5.1 - Other Expected Improvements


    (Page 3 of 4 )

    There are numerous other fixes, enhancements, and additions planned for future versions of MySQL. In this section, we’ll take a brief look at some of these, particularly those that are of interest with regard to optimizing database schemas and queries or speeding up general performance.

    Full (Outer) Joins

    Full joins may be supported in MySQL 5.0 or 5.1. Full joins, which return a NULL for any column in one table that isn’t matched in the other, are discussed in Chapter 5.

    User Variables

    User variables in MySQL 5.0 have already been changed in that the names are no longer case sensitive. Prior to this, @MYVAR and @myvar were treated as separate variables; beginning with version 5.0, they’ll be regarded as the same variable.

    Another planned change is to allow user variables to be updated in UPDATE statements. For example, if this is done, the following would be possible:

    UPDATE mytable SET @myvar := col1 + col2;

    Currently, this can be done only in a SELECT query. It’s also likely that user variables will eventually be usable in statements having GROUP BY clauses, like so:

    SELECT id, @count := COUNT(*) FROM products GROUP BY category_id;

    SET Functions

    Two new functions for working with SET columns are planned. These are ADD_TO_SET() and REMOVE_FROM_SET() . Suppose that we have a users table containing a SET column defined as

    language SET('English,German,Spanish')

    Were this function to be added, it would then be possible to update the column definition with something like this:

    ALTER TABLE users
    MODIFY language ADD_TO_SET('Portuguese', language);

    and this:

    ALTER TABLE users
    MODIFY language REMOVE_FROM_SET('German', language);

    without the need to reiterate all the elements in the set.

    Group Functions

    The SQL standard provides for three functions that allow you to find out very quickly whether or not any one, some, or all of a set of values is true:

    • ANY() : This function returns TRUE if one and only one value in the set is true; if no values in the set are true or if more than one value is true, then the function returns FALSE.
    • SOME() : This function returns TRUE if at least one value in a set of values is true.
    • EVERY() : This function returns TRUE if and only if all values in a set are true.

    Here are some examples, noting that the query SELECT price > 100 FROM products; will return a set of 1s and 0s, that is, TRUE and FALSE values:

    # If this query returns 1 (TRUE) then we know only one product has a pric e
    # greater than 100.00:
    SELECT ANY(SELECT (price > 100) FROM products);
    # If there are some products (possibly all of them, but at least one of
    # them) having a price greater than 100.00, then this query will return 1
    # (TRUE), otherwise it will return 0 (FALSE):
    SELECT SOME(SELECT price > 100 FROM products);
    # If *all* products in the table have prices greater than 100.00, then this
    # query will return 1 (TRUE):
    SELECT ALL(SELECT price > 100 FROM products);

    According to the SQL standard, these functions should work only with sets of Boolean values; however, this could work in MySQL with other types of sets as well, since MySQL interprets 0 as FALSE and any other number or string value as TRUE.

    More MySQL Articles
    More By Apress Publishing


       · This article is an excerpt from the book "Beginning MySQL Database Design and...
       · Myself I am really looking forward to see MySQL Cluster supporting disk storage...
     

    Buy this book now. This article is excerpted from chapter eight of Beginning MySQL Database Design and Optimization: From Novice to Professional, written by Jon Stephens and Chad Russell (Apress, ISBN: 1590593324). Check it out today at your favorite bookstore. Buy this book now.

       

    MYSQL ARTICLES

    - Take Some Load off MySQL with MemCached
    - MySQL Table Prefix Changer Tool in PHP
    - Using the SIGNAL Statement for Error Handling
    - Error Handling Examples
    - Error Handling
    - Completing a Search Engine with MySQL and PH...
    - Paginating Result Sets for a Search Engine B...
    - Building a Search Engine with MySQL and PHP 5
    - Using Boolean Operators for Full Text and Bo...
    - PHP, MySQL and the PEAR Database
    - Working with PHP and MySQL
    - Getting PHP to Talk to MySQL
    - Creating an RSS Reader: the Reader
    - MySQL Security Overview
    - Creating the Admin Script for a PHP/MySQL Bl...





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway
    Stay green...Green IT