While the MySQL 5.1 feature list looks quite tasty to me, the MySQL 5 feature list has not really won me over. Aside from the fact that most new MYSQL 5 features have been quite bug plagued (though this is now mostly resolved side from the performance issues with VIEW's and INFORMATION_SCHEMA). So Arjen is doing some courses on MySQL 5 features, which got me thinking which are the features I regularly use? Uhm .. I think there is only one, which are VIEW's. Actually I always end up using them for the same thing: Computing a status field that changes given the CURRENT_DATE. I tend to try and avoid cron jobs for these tasks whenever I can. Of course it would be more performant to update the status once, but replying on the status update cron job to actually work right at the expected time is …

Within the present MySQL ecosystem, there are limited options for dedicated MySQL Consulting in the US. Outside of the official Sun/MySQL Consulting, Percona and Proven Scaling both based in Silicon valley are the only options generally known and accepted by the MySQL Community.

There is now an east coast option based in New York, and that is Ronald Bradford. Providing expert MySQL Consulting in Architecture, Performance, Scalability, Migration and Knowledge Transfer.

With two decades working in the IT industry, Ronald is well qualified in MySQL having previously provided consulting services for MySQL Inc combining 9 years experience with the product. His consulting experience is not limited to MySQL, having …

I will be speaking on July 29th in New York at an Entrepreneurs Forum on A Free Panel on Cloud Computing. With a number of experts including Hank Williams of KloudShare, Mike Nolet of AppNexus, and Hans Zaunere of New York PHP fame is should be a great event.

The focus of my presentation will be on “Extending existing applications to leverage the cloud” where I will be discussing both the advantages of the cloud, and the complexities and issues that you will encounter such as data management, data consistency, loss of control, security and latency for example.

Using traditional MySQL based applications I’ll be providing an approach that can lead to your application gaining greater power of cloud computing.

About the Author

Ronald Bradford provides …

I have seen on many engagements the column data type is defined as INT(1).

People have the misconception that this numeric integer data type is of the length of one digit, or one byte. (One digit is 0-9 an one byte is 0-255)

This is incorrect.

Integer

For integer numeric data types in MySQL, that is TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT the (n) has no bearing on the size of data stored within the specific data type. The (n) is simply for display formatting.

In the MySQL Manual 10.2. Numeric Types you read This optional display width is used to display integer values having a width less than the width specified for the column by left-padding them with spaces. The display width does not constrain the range of values that can be stored in the column, nor the number of digits that are displayed for values …

Recently I was asked to provide guidelines for testing fail over of a MySQL configuration that was provided by a hosting provider.

The first observation was the client didn’t have any technical details from the hosting provider of what the moving parts were, and also didn’t have any confirmation other then I think a verbal confirmation that it had been testing.

The first rule in using hosting, never assume. Too many times I’ve seen details from a client stating for example H/W configuration, only to audit and find out otherwise. RAID is a big one, and is generally far more complex to determine. Even for companies with internal systems I’ve seen the most simple question go unanswered. Q: How do you know your RAID is fully operational? A: Somebody will tell us? It’s really amazing to investigate on site with the client to find that RAID system is running in a degraded mode due to a disk failure and nobody knew.

It …

The answer is yes.

In this face off we have two numeric MySQL data types, both Integer. In fact MySQL has 9 different numeric data types for integer, fixed precision and floating point numbers, however we are just going to focus on two, BIGINT and INT. This design consideration is part of my recent presentation Top 20 Design Tips for Data Architects.

What is the difference?
We turn to the MySQL Reference Manual first, in 10.1.1. Overview of Numeric Types we see the following.

INT[(M)] [UNSIGNED] [ZEROFILL]

A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.

BIGINT[(M)] [UNSIGNED] [ZEROFILL]

A large integer. The signed range is …

I am very thrilled to hear that SUN is evaluating joining the SQL standard process. I feel that Peter would be the perfect candidate for this job too, given that he knows the standard inside out. My hope would be that this way the OSDB consortium (yes, I still believe) will get a liason to the SQL standards body. Also this way the much more down to earth real world approach of OSS databases to finding new syntax to add to SQL now has a chance to find its way into newer versions of the standard. It seems things are too late to ensure that SQL2008 will follow the popular LIMIT syntax, but in a way its already a huge leap forward that SQL2008 defines a way …

So I took my concerns over prepared statements to the #postgresql IRC channel on freenode. I pointed out that I think there should be a way to get server side handling of placeholders in statements but without the additional overhead of a second round trip or the drawbacks of overly generic query plans due to not being able to use the parameters in the planning stage. Some people have noted that this feature is available in MSSQL. It also seems to be available in PostgreSQL in the form of PQexecParams and its even exposed in ext/pgsql, though it's only used for sequence reading in PDO_PGSQL. It would be really cool if it could be used when emulating prepared statements (probably with a PostgreSQL PDO …

This is not related directly to MySQL, but alas I must rant. In this day and age I’m not sure why an application would require IE7 and ActiveX controls to run a ticketing system. If we’re in the technical world, as sysadmins or DBAs, which run Linux/Solaris/Unix on any good server in order to get work done, it only makes sense to use a unix based OS (osx,linux,solaris) as a workstation.

It’s easier to interface with servers, there are better terminal options (in which we live our daily lives), free options to just about everything that exists in Windows, and YET there are ticketing systems (RNT) that require IE7 and ActiveX controls - which require you to run WindowsXP. It doesn’t work on windows server 2003, it doesn’t work on Windows 2000 Pro.

So what are we left with? An impossible situation that requires an employee to run two OSes in order to get work done. Ridiculous! It’s a waste of time and resources. Not to …

So I took Roland's comment and tried to get it integrated into my code. For the tab management it worked well, but for portlet management it was a lot harder. Actually I only have a partial implementation finished. What's missing is the necessary logic to be able to move a portlet in the same tab from one column to another (there are 3 columns a portlet can be in for each tab). The thing that was most important to me was cleaning up the pruning operation. This took some trickery (aka hackery). I think its a better implementation but it does make me a bit nervous. Of course its all still very MySQL only.

Anyways so here goes the final query for moving a tab:

UPDATE user_tabs ut
    JOIN user_tabs ut2
        ON (ut.user_id = ut2.user_id
            AND ut2.id = :id
            AND ut2.pos != :pos
            AND ut.pos >= LEAST(ut2.pos, :pos)
            AND ut.pos …