There are a bunch of functions and classes written into PHP to help with these mismatches. I'm thinking of PDO, PHP Data Objects, for help with conversion from one database to another, and ORM, Object Relational Mapper, for taking database data and making them into PHP objects.

One specific area that always seems to have object-relational impedance mismatch is dates. Specifically, how to convert MySQL dates to PHP dates.

MySQL dates can be stored as either a string, or an integer. The available date formats in MySQL are: DATE, TIME, DATETIME, TIMESTAMP, and YEAR. The possible range of dates and time for each format are:

DATE
yyyy-mm-dd
1000-01-01 to 9999-12-31

DATETIME
yyyy-mm-dd hh:mm:ss
1000-01-01 00:00:00 to 9999-12-31 00:00:00

TIMESTAMP
yyyy-mm-dd hh:mm:ss
1970-01-01 00:00:00 to 2037-12-31 23:59:59

TIME
hh:mm:ss
-838:59:59 to 838:59:59

YEAR (2 or 4)
yy or yyyy
1970 to 2069 or 1901 to 2155

If we want to convert these dates and times to PHP to do things like date calculations, you begin to see some of the problems.

TIME and TIMESTAMP base their formats on the Unix Epoch date, 1970-01-01, as does PHP. However, TIMESTAMP resets its value every time you update a row, because of this, you most likely should capture date and time information in MySQL with the DATETIME format. DATETIME is formatted as a string in MySQL.

There are many advantages to storing dates in MySQL. There are a multitude of date functions within MySQL, and you can output the date, in any format, to the front of the page. What else do you need, MySQL takes care of everything.

Unfortunately, there are times when you want to do some date calculation in your PHP code, and then use the result of the calculation in a conditional statement based on a date. If you do, you need to do a MySQL to PHP date conversion. How do you do it?

PHP dates are stored as a 64-bit number that range from 292 Billion years in the past to the 292 Billion years in the future, and dates are different depending in what time zone you set in your php.ini file. Like in MySQL, there are multitude of functions and classes you can use to handle PHP dates within PHP.

What are our options for handling this Object-relational impedance mismatch with dates?

First, we could do everything in MySQL, store the DATETIME, do all the calculations, and formatting. This works a lot of the time, except of course, when you need to do some special date calculation in PHP.

We could use MySQL's help with the conversion with two MySQL commands: "UNIX_TIMESTAMP" and "FROM_UNIXTIME".

Use UNIX_TIMESTAMP to convert MySQL dates to PHP dates, like so:

    $SQLquery = "SELECT UNIX_TIMESTAMP(MySQL datetime)...";

FROM_UNIXTIME would be used in the opposite direction for database UPDATES.

    $SQLreturnQuery = UPDATE xtable SET
    datecol = FROM_UNIXTIME($PhpDate) WHERE...

Second, we could store the date in the database as a PHP integer, and output the date directly from the database to a PHP variable or array. Unfortunately, you give up all the MySQL date calculations and formatting. You also have problems if your crossing time zones. This is not a good idea.

The last option is to do the conversions when you need to, and this is probably the way most folks do it. Let's walk through it.

We'll use two PHP functions to get the correct date.

If we get a DATETIME formatted date from the database, and assign it to a variable, say $SqlDate, when we echo it out, we'll get a string that looks like this: "2011-05-23 09:29:20," which is how it is stored in the database.

We need to convert this string value to a time integer. PHP can do this with a "strtotime" function, that's used like this:

	$PhpDate = strtotime($Sql_Date);

Strtotime is a PHP function that expects a string as a parameter with an English date format. It will try to parse this string into a Unix timestamp, taking into account the current timezone.

If we echo out $PhpDate, we get an integer like this: "1306157360"

We now need to format this integer into a date we can understand. We'll use the PHP date function.

	$FormattedPhpDate = date('M d, Y', $PhpDate );

The purpose of the date function is to format the output of a date integer into our desired date format. If we echo this out we get: "May 23, 2011"

In summary, once we get the date out of the database, we're talking about two lines of code.

	$PhpDate = strtotime($Sql_Date);
	$FormattedPhpDate = date('M d, Y', $PhpDate );

Not that difficult, after all.

1. Exact phrase
2. All keywords
3. Any keywords

For example, let's assume we have a database table with available shirt sizes and colors. In that table we have the following data:

In too many cases, searching for "black small" returns zero results. This is a less than optimal example, because if you were generally looking for a "black small" shirt, you may not care about the Medium Black or Small in various colors, but this same technique also applies to full text searches for articles or whatever you might be searching.

Following the example, an Exact Phrase search for "black small" returns no results. Not once, in either column, does the phrase "black small" exist. An All Keywords search for "black small" would also return no results, because no single record includes both "black" and "small" (An All Keywords search for "black medium" would yield one result - for the "Medium Black" record). An Any Keywords search for "black small" would return four results; "Medium Black", "Small Red", "Small Green", and "Small Blue". In most cases (IMO), users want either All Keyword or Any Keyword searches.

The usual (broken) SQL search query looks like this (the '%' means ignore anything else in that direction):
SELECT * FROM table t
WHERE t.some_column LIKE '%my_search_phrase%'
OR t.some_other_column LIKE '%my_search_phrase%';

Let's say your search phrase is again "black small". The Exact Phrase query is:
SELECT * FROM shirts s
WHERE s.color LIKE '%black small%'
OR s.size LIKE '%black small%';

That is the query for an Exact Phrase search; and if you want to ensure an exact match of the terms you input, you're finished. As I mentioned, I don't think this is the generally intended search from a user. More often, they want an All Keywords search. That query looks like this:
SELECT * FROM table t
WHERE (t.some_column LIKE '%my%' OR t.some_other_column LIKE '%my%')
AND (t.some_column LIKE '%search%' OR t.some_other_column LIKE '%search%')
AND (t.some_column LIKE '%phrase%' OR t.some_other_column LIKE '%phrase%');

And for the "black small" search phrase, the All Keywords search is:
SELECT * FROM shirts s
WHERE (s.size LIKE '%black%' OR s.color LIKE '%black%')
AND (s.size LIKE '%small%' OR s.color LIKE '%small%');

This query searches each appropriate field to see if any record in the database somehow includes all of the keywords provided (but in any order, and from any column - thus distinct from the exact search).

Finally, the Any Keywords search - the functionality that I think we most often desire when searching. The Any Keywords search looks like:
SELECT * FROM table t
WHERE (t.some_column LIKE '%my%' OR t.some_other_column LIKE '%my%')
OR (t.some_column LIKE '%search%' OR t.some_other_column LIKE '%search%')
OR (t.some_column LIKE '%phrase%' OR t.some_other_column LIKE '%phrase%');

And for the "black small" search phrase, the Any Keywords search is:
SELECT * FROM shirts s
WHERE (s.size LIKE '%black%' OR s.color LIKE '%black%')
OR (s.size LIKE '%small%' OR s.color LIKE '%small%');

This search returns any record in the database that includes any of your search keywords in any of that records columns. I think this is generally the search query you want to implement. A careful eye notices that the WHERE clause parantheses in the Any Keywords search are unnecessary. This is true, but I left them there because it makes your scripting loops a little easier, because the only difference between Any and All searches is the "OR" vs. "AND" presence.

Now go fix your search box functionality.

However, MySQL started with a slightly different licensing format than what we're use to as Open Source.  MySQL AB, the creator of MySQL, in 1995, came out with a license they termed, "Second Generation" Open Source. They did this with "dual licensing." The software is made available as Open Source,  but the licensing is retained by the company, and is used to sell licenses to companies that want support. To increase revenue, MySQL AP introduced a multi-tiered support, and enterprise licenses.

MySQL AB was sold in 2008 for $1 Billion to Sun Microsystems. Sun continued development, and dual licensing. MySQL continued to grow and become the world's largest web based, open source, database. Developers used it for small to medium size, non-enterprise, companies web sites. As the PHP language grew to be the premier web development language, it became more and more synonymous with MySQL. So much so, that the next release will, supposedly, be even more tightly coupled with it. MySql became number three overall, behind Microsoft SQL Server, and Oracle.

In 2009, Oracle, the second largest software company, found its revenues declining and it's market saturated, while MySQL installed licenses were rising. They were under heavy competition from Microsoft's SQL Server.

Their solution was to offer to buy Sun in April of 2009. The deal was not completed until the U.S. government agreed in August, 2009, and the European Commission agreed in January 2010, after a petition by over 50,000 developers against the sale. As part of European Agreement, Oracle will maintain MySQL dual licensing until 2015. That's only four years from now.

From is past history, it seems obvious, that Oracle is on a mission, to become the world's largest software company. Oracle sells its database in several versions, an Enterprise edition, a Standard Edition, Standard Edition One, and a Personal Edition. These licenses can be sold by: user, processor, or cluster. They have additional pricing for database utility tools. Support is usually about 25% of the license price.

The prices they have released for MySQL will morph into Oracle's pricing structure. The new prices show a Standard, Enterprise and Cluster version. We see Oracle continuing to raise prices. Bear in mind, Oracle raised its prices 20% in 2008 and 40% in 2009 to boost their revenues.

Sun offered a reduced price Basic and Silver support. Oracle is dropping that. Users will need to upgrade to Gold Support. If previous users want to keep their old support, Oracle will sell it to them only if they sign up for a three year contract.

MySQL Workbench, which replaced MySQL Admin and the Query Builder tool, all were free from Sun, not anymore. You have to buy a license to get them. Oracle also striped out some of the capabilities from the MySQL Open Source version, like the NDB storage engine, for example, and now charges for this.

You have the lay of the land, this leads us to question the fate of Sun open source software that Oracle now owns: besides MySQL, there's OpenOffice, Java, and along with Java, Glassfish. We'll stick with MySQL for this article. Here's our prediction of Oracle's future direction, given their past history, and the way they've previously marketed their products.

Look for Oracle not to drop it's Open Source version after 2015. It will keep a stripped down version available to entice new users to their revenue stream when they need to upgrade, and to claim they still support the Open Source community. The prices for MySQL will steadily climb. This will kill MySQL as the database of choice for web development. Look for MySQL to decline in use.

The decline will not be immediate, it will take some time, notably Apache distributions like XAMPP and WAMP will have to offer users alternatives to MySQL, as most developers use these packages, instead of installing products independently.

All is not lost, the Open Source community has plenty of options. There are several good database choices, all open source and free. When the Sun sale was announced, there were several forks taken of MySQL: Drizzle, MariaDB, Percona Server, and OurDelta. Each has a slightly different goal moving forward. There are two well established alternatives to MySQL:  PostgreSQL and Firebird. Both have large established communities, and support of major corporations. One of these will become the next MySQL, we're not sure which one yet, with a slight nod toward PostgreSQL, and then Firebird.

This reminds me of the old quote, first uttered in 1422 at the coronation of French King Charles VII, after the death of his father, Charles VI, "The King is dead. Long live the King." Just maybe we're a bit premature, but we see it coming.

Not, that I had any inside knowledge, I just knew from reviewing the Release Candidate that most of the bugs were gone, and the release could not be far away.

Sure enough, in just 3 days, July 1st, the release became official. My review of June 27th stands, this post is for those who decided to wait for the official release. Well, it's here.

On the release, the developers stated, "We hope you will make MySQL Workbench your preferred tool for Design, Development, and Administration of your MySQL database."   We agree.

Download MySQL Workbench here. Any one working with MySQL will quickly find the tool has many enhancements from the older MySQL Administrator and its companion MySQL Query Builder, which are now retired.   MySQL Workbench should become a much used tool in your toolbox.

The older MySQL Administrator and the accompanying MySQL Query Browser were tools that were much beloved, that you kept going back to, and using over and over again,  like a nice fitting driving gloves, comfortable, useful, and empowering.  Since I started working with MySQL, I can't remember not having them on my desktop, ready at a moments notice.

Because of that, I have looked upon MySQL Workbench with much suspicion and doubt. And indeed before this release, I would say the MySQL Workbench could not replace the previous Administrator and Query Browser. Now, I'm not too sure. With this release that has changed. Workbench includes the integration of MySQL Administrator, and MySQL Query Browser into an integrated environment, with much potential for growth through plug-ins, much like Eclipse, although don't get me started on the integration of Eclipse plug-ins, another topic.

Workbench is like the French three-pronged fleur-de-lis, three separate tool areas open from a central core, Workbench Central.

Workbench Central

Workbench makes heavy use of "breadcrumb" like menus without tabs. Menus run horizontally across different windows in the Workbench, and clicking on the name brings you to the next screen. It took a second to get use to, but once I did, I liked the layout and the way workbench integrated.

You go back to Workbench Central by clicking "Home" in the upper left. If you click on any of your db connections, or menus across the top,  you enter into one of the three program areas: SQL Development with Query Browser, Data Modeling, and Server Administrator. It is obvious that each of these three sections is its own program, as they each take awhile to open at first.

Before MySQL Workbench folks were using DBDesigner to model their databases and do their EER diagrams. The Data Modeling section probably needs a little clean up and streamlining, as it opens rather "clunkily," but once open works well.

Workbench Data Modeling

The administrator works well, but needs a little configuring as it checks your connections, and let's you know if your missing an ini file or config setting.     You can configure multiple database connections to multiple servers, and reach each database with a click of the mouse.  The Administrator includes a series of graphs along the top of the window, which look nice, but I'm not sure are that useful.   The Administrator is laid out horizontally in keeping with the overall layout template of the Workbench, but I think I like the original Administrators vertical menus a little better.

Workbench Administrator

You can tell the Development Team has put some time into the Query Browser, and it shows.  You'll find that the Query Browser is an improvement over the previous independent version. A red error x pops up as you type a query if you have the syntax wrong, this is immediate, instead of waiting until after you execute the query, very nice.  Query's form a horizontal s menu along the top of the window as you make them, yes, the older version had this, but this is more automatic. Errors are reported when you execute the query, the same as the old version, with an obtuse error number.  My only gripe, which has nothing to do with the current Workbench, as the same was true of the previous version, is I wish the error messages were a tad more verbose.

Workbench Query Browser

MySQL Workbench is coming into its own and is starting to show the promise in its developer's eyes.  The Developers Tools Team should be applauded for their dedication and persistence to get it right, and the outcome of this dedication is that MySQL Workbench is getting better and better.   I would look for the official release to follow closely after this RC 3 release.  I recommend you not wait for the official release,  go ahead, and get this release now, and start using it.  There is much to discover as you integrate Workbench into your databases, and begin working with it.  Enjoy.

Oracle's revenue comes from it's pervasive Oracle database. Depending on how you look at it revenue, or installs. Oracle is in the top 2 with Microsoft and IBM's DB2 a close third. Let's not forget, MySql is the most popular Open Source, i.e free, database in the world. What is surprising is when you look at installs and the number of developers developing with a database, MySql comes in a close 3rd to Oracle and Microsoft, with DB2 fourth, and MySql shows the greatest growth rate of all database development.

Oracle's acquisition of the MySql product may be a problem for the Open Source community. Sun owned MySQL, which now belongs to Oracle. If you remember, Oracle purchased PeopleSoft in Dec. 2004 for $10.3 billion. In Oct, 2005 they acquired Innobase which is an integral part of MySql for transaction processing and foreign keys. What will Oracle do with MySql has caused a huge concern with the Open Source Community, so much so, that their already has been several forks of MySql, Drizzle, and MariaDB, just in case Oracle starts charging for MySql. For now, Oracle pledges to leave MySql independent, but this is to be expected in the initial stages of an acquisition, things usually change in six months or so.

My thought is they will continue to support an Open Source MySql and build on top of MySql additional tools, extensions, and integrations with other Oracle products with, of course, a clear upgrade path to Oracle's flagship products for which the enterprise users will pay dearly.

And the same for OpenOffice.org, a legitimate contender, now, of Microsoft Office. Oracle has never had an Office Suite and has wanted one. Oracle is built with Java, as is OpenOffice.org. Again, tools, extensions, and integrations with Oracle products seems like a nice way to get users to start paying for more and more functionality from a previously non-existent Oracle Office Products.

Oracle keeping the Open Source products they have acquired free, and enhancing them, at first, to gain market share seems like good business sense, but as these applications gain more and more market share, I believe Oracle will take a page from Microsoft's play book, and start charging for their enhancements to the products. What this means for Open Source, is a freezing of the Open Source components to a minimal feature level, and if you want more, pay for it.

I have great faith in Open Source software, the forking of MySql is evidence that independent Open Source Developers will continue to create other applications with the missing functionality, that Oracle will ask customers to purchase. As MySql has emerged as the premier Open Source database, so other products can, and will, emerge to take its place, if Oracle begins to get as "bean counterish" as Microsoft is currently, with it prideful boasting about "Microsoft Genuine Advantage," and its publicly crowing about the number of companies they have sued, look for any closing down, of previously Open Source Oracle products to be a catalyst to breed a new generation of improved Open Source products.

We have downloaded it on both a Unix and Windows system.   Once you get it up and running you'll feel very much in control of your databases whether at your localhost or to a remote server.

There is one problem you will run into when you initially launch the tool on both Unix and Windows.  This problem appears to be independent of the operating system or server, i.e Wamp or Xampp on your local machine.  There is an initial login error which pops up a message:  "Either the server service or the configuration file could not be found. Startup variables and service section are therefore disabled."  This is documented in the MySQL forums.

You can still click ok and the tool will launch, you'll see your databases under "catalogs," but your service controls will be grayed out, and you will not be logged in as a user.  The problem is the Administrator tool can not find your MySQL "my.ini" file.  And since your not logged in, you can not change your path in "Service Control->Configure Service," it seems like a catch-22, and has left us, and judging from the forum, many others frustrated.  We spent about an hour on it.

Here's the solution.  On Windows,  start up MySQL Administrator, push down your "control" key, and click "cancel" in the login window.  This will bring up your "Service Control" window.  Go to "Configure Service->Configuration Filename:"  and put in the path to your MySQL my.ini file, including the my.ini at the end of the path.  Click Apply Changes, and click the "Start/Stop service tab, and then stop and restart your service.  Close the window, and relaunch the administrator tool.  Your error message should be gone, and everything should start properly.

My setup on Linux is a lampp install on Fedora 10.  The MySQL tools are completely separate from the lampp application suite,  so you need to tell the MySQL Administration tool where to find the database.  The Administrator tool looks for "/etc/my.cnf " ,  which must be some kind of default location.  I could not find a way to change this.  The work around is to remove the stock "/etc/my.cnf " file, and to replace it with a soft link to the lampp configuration file.

ln -s /opt/lampp/etc/my.cnf /etc/my.cnf

Now, the MySQL Administration tool will read the lampp configuration file, and everything should work properly.