For many people, MySQL vs PgSQL is more of a religious question than a technical one, and there is definitely something to be said for sticking to what is already familiar to you. There are also some very good technical considerations in choosing which one is more appropriate for your application. First and foremost, both MySQL and PG are excellent relational database management systems (RDBMS), and in almost every case, either one will work great, and there is no wrong answer when asking which one you should use.

Probably the biggest and most frequently discussed differences between MySQL and PG are in features and complexity. PostgreSQL has more of both. There are many features of SQL that PG has supported for years, that are just recently becoming available in MySQL. Some mentioned in the discussion are subselects, transactions, stored procedures, contstraints, triggers, and a few other advanced SQL features. Most or all of those features are (or will be) supported in MySQL 4.0, 4.1, or 5.0, and some, like transactions, were available in the MySQL 3.23.xx releases with certain table types, like InnoDB.

Because of the complexity added to PGSQL to support those features, MySQL in its default configuration (i.e. with MyISAM tables) is generally regarded as faster than PGSQL. Because of MySQL’s different table types (which use different database engines), you can effectively “turn on” and “turn off” features like transactions on a per-table basis, which provides a significant performance improvement. Many say that when using the advanced features of MySQL (i.e. when using InnoDB tables), performance is very comparable between the two databases.

There are virtues to having a less complex feature set: Simple is easier, Simple is faster, Simple is more stable. MySQL requires less system administration to configure and maintain, and for most people, it “just works” without any real tweaking or customization. Especially when being used with PHP, this is a big advantage. Most applications written in PHP simply do not require most of the advanced features that SQL has to offer, and PG would be overkill, and that overkill comes at a price.

Many people think that they would be better off with PGSQL because someday they might need a feature that PGSQL has that MySQL doesn’t have. As with most other things, if you don’t have something specific and reasonably likely in mind already, you most likely won’t ever use those features. Another important consideration is that there are very few cases where those advanced features are truly required. Granted, sometimes a subselect may make a simpler query, but it can almost always be rewritten as a join, which usually executes faster and is about as readable as the query using subselects. Especially in conjunction with PHP, it is very difficult to contrive a situation where the lack of a particular feature makes something impossible or very difficult with MySQL where it would be much easier with PostgreSQL.

Another aspect to consider is support. MySQL has a larger user base, and is supported by more applications. In cases where there isn’t support for both of them, an application is more likely to have MySQL support than PgSQL support. When both are supported, the MySQL support is generally better tested than the PgSQL support.

If you’re trying to help a client or customer or manager decide what database should be used, marketing and branding apply. If your client has heard of individual database engines, the most likely ones they’ll know about are Oracle, Microsoft SQL Server, and MySQL. Selling them on PostgreSQL can be an uphill battle if they haven’t heard of it before, though billing it as practically “an open-source Oracle” may do the trick, and is probably relatively accurate. PgSQL is the closest free and open-source equivalent to Oracle.

For others, licensing is an important consideration. PostgreSQL is released under a BSD-style license, which allows it to be used in almost unlimited ways, including embedding in closed-source applications. MySQL is released under the GPL and under a commercial licensing policy, which requires certain applications to pay for a license if their use doesn’t comply with the GPL. The main time this matters is if it will be embedded in a proprietary application.

Administrative overhead can be one of the biggest ongoing costs of your application, so careful consideration should be used before choosing something that will require more administration. MySQL is generally considered to require less administration than PostgreSQL.

If you’re already experienced with a complex database like Oracle, and like it, Postgre will be more similar to Oracle than MySQL will. If you haven’t used Oracle, or didn’t like using it, you’ll be more comfortable with MySQL in most cases.

Many people see performance (speed) and capacity (both volume of data and volume of queries) as key factors in choosing their database. In the vast majority of cases, any performance or capacity issues you might run into will not be solvable by changing database engines between MySQL and Postgres. It is probably 100x to 1000x easier to max out your database server by running poorly optimized queries, by having a poorly laid outdatabase schema, or by having a poorly written interaction between your application and your database, than to max out your database server by actually requiring an extremely high volume of data to go in or out. By the time you reach that point, you’re more likely to be running into problems like memory bandwidth, disk bandwidth, and seek times more than problems due to (or solvable by) your database engine.

Both MySQL and PostgreSQL will eventually “hit a wall” in their performance when you get enough queries. In general, a simpler, leaner engine, like MySQL, will hit that wall later than a more complex engine. Things like replication can help with performance and query capacity issues, but once you reach a high enough rate of inserts, deletes, and updates (”write” operations) in your database, replication won’t really help much. A “read” can occur at any database replica, but a “write” has to occur at all of them. If your performance problem is due to writes rather than reads, you’re better off getting a beefier server (within reason) than using replication.

If you’re not familiar with either of the two databases, or unfamiliar with SQL altogether, learning MySQL will probably be easier for you than learning PostgreSQL. If you already know Oracle, Postgres will be more familiar than MySQL. If your development team is more experienced with one or the other, that experience will probably provide more benefit than choosing a different engine. Retraining and working in something you aren’t familiar with can be somewhat costly, and usually should be avoided where possible.

There are a lot of considerations, but here’s the bottom line: Both MySQL and PostgreSQL are extremely good and capable database servers. There are a few differences that may sway you one way or the other, and there really isn’t a wrong choice. There are times when PostgreSQL is a clearly better choice for one reason or another, and in that case, don’t hesitate to use it. Keep in mind, however, that the times when PgSQL is necessary or is worth the extra complexity are far, far, fewer than the cases where MySQL is sufficient and more appropriate.

We at UPHPU hope that this article was useful to you, and we welcome your feedback. The content in this article is due to contributions by many people, and we would most notably like to thank Ray “bigdog” Hunter, Josh “dataw0lf” Simpson, Grant Shipley, Jon Jensen, Mike Trionfo, Tyler Gee, Jeffrey Moss, and Lonnie Olsen, and Scott Hill, who started the discussion.

Most classes are single day, 9am-5pm courses that cost $189. The PHP classes are each two full days, and cost $495 per class. Details on PHP Level 1 and on PHP Level 2 are available online. The dates are June 14 and 16 (Tuesday & Thursday) for Level 1, and July 5 and 7 (Tuesday & Thursday) for Level 2. The instructor is Nikolai Langlois, who we should probably get involved in UPHPU. (These links seem to be a bit tempermental, but the continuing ed. one seems stable.)

This highlights the demand that exists for training in PHP in our area. It also indicates the value that is placed on it - $1,000 for 32 hours of training puts it at $30/hour. Take off the University overhead, and $20-25/hour of training isn’t unreasonable.

Another thing that catches my eye is the fact that they offer only Level 1 and Level 2 classes, with Level 2 stopping with connecting to a database and using PHP sessions and cookies. This is just the tip of the iceberg in being a good PHP programmer, and I doubt there are many people or organizations in a better position than UPHPU to provide advanced training.

The plan is moving forward, and we’re working out the logistical details of getting the course off the ground.There are a couple of important discussion threads on the mailing list, and a poll to plan days of the week, measure interest and estimate attendance. We are in urgent need of some feedback from people, whether they’re interested in training, the group project, or both.

If you’re interested in participating in the training courses:

1. We need to you to take the poll, so we can decide on a day. For now, don’t worry about cost, location, or anything like that, and just assume we’ll be able to work things out with you.

2. “Pre-register” with Wade or myself, the sooner the better. We need to get together a list of interested people so we can email the smaller group and expect to get answers back in a timely fashion. Without being able to contact everyone, it will be really hard to make this work.

If you’re not interested in training, but would like to participate in the group project:

1. Some of the group project meetings will coincide with training meetings. For example, the first half of a training meeting may be discussion and planning for the group project, while the second half would be training related to the plans that were made.

2. Take the poll, and select your day(s) of choice. The team working on the project has to have time to get together, and we need to know when you can make it.

3. Tell Wade or myself that you’re interested in the project but not training classes. If you’d like to also specify what level or kind of involvement you’d like to have, that might help too. We’ll probably set up a developer mailing list for the project along with CVS or subversion accounts and access to a MySQL database for all the team members.

We really want to know what people want to do, and where UPHPU should be focusing to provide the most benefits to its members and our community. Without some participation from other people, it will end up being based on the ideas of just a few of us, and probably won’t be as good.

Thanks to everyone for your participation in UPHPU!

- Mac

A recent discussion on the mailing list (subject: “RE: Javascript form validation [was Re: Posting a form]”) prompted me to post an article about JavaScript, and how to use it appropriately. I’m not a JavaScript expert, and I don’t play one on TV. But I am versed in it and have seen a lot of good and bad things done with it. My main goal in sharing my thoughts on the subject is to help people know when and how JavaScript is the right answer, and make the world a better place. If talking about things like this can open a dialogue, that would be great, and we can get the word out to help stop people from falling into the trap. Newbies especially can benefit by finding out about the problems before they get into bad habits.

One of my biggest issues with the way people use Javascript is when they use it for validating form input. It is one aspect of the problem of using client side programming for things that can only effectively be done on the server side.

Because Javascript is run on the clientside, it is not guaranteed in any way to be run. It is insecure. It can be faked, skipped, avoided, disabled, and any number of other undesirable things. Search engines don’t run any of it either, though that doesn’t have much to do with form validation in particular. People can even make a form like yours, but without the javascript, and submit that instead of your form.

Before I go further, let me say that client side validation (and other client-side functionality) has its place. In many cases, it can make the user experience better by providing faster response than submitting the form to the server, and it can do things that the programmer thinks are helpful, like updating other fields as values are selected or entered. (Another pitfall is the programmer doing things that they think are helpful, without any consideration for the users that find the same thing very unhelpful, and weren’t given a way to disable the behavior, but that’s an article for another day)

However, because it can be easily bypassed, it is of absolutely no use for guaranteeing that the form submission meets certain criteria. The only place that can be done is on the server side, where the programmer has complete control over the data and the validation performed on it.

I’ve seen horrific things in this regard. One in particular that makes me cringe is when I saw a site that used Javascript to calculate the amount a credit card would be charged, and the server side blindly accepted whatever the javascript told it, and billed the card that amount, and considered the bill paid in full. Another javascript abuse I saw used a form that did not have a valid action, so the form didn’t have anywhere to submit to, and by means of javascript, validated things and proceeded to (incorrectly) fashion a GET string, then set the page’s location to that string. I’ve seen others that do a pretty good job in the javascript of validating things, but when the page was submitted, did absolutely no validation on the server side. To make matters worse, I saw all three things on the same site, one that I did not write, but which I was hired to debug, repair, and complete. I’ve seen most of those things in plenty of other places too, at least the client side mistakes.

Another thing to keep in mind is that if your site will not work with javascript disabled, you are closing out a significant portion of your potential users. And I’m not just talking about the wierdos (I say that affectionately) who use Lynx for normal browsing. In the worst case, you’re locking Google, Yahoo, MSN, and the other search engines out of your site. (If that doesn’t matter to you, it probably should.)

Every site should be functional and usable (at least) without javascript. If it has more bells and whistles with javascript, fine. But it should still work without it.

A statistic I found recently stated that a significant number (I heard about 10%, but others dispute that, saying that it is 5% or less) of users have javascript completely or partially disabled in their webbrowsers. And no, that isn’t one of the 93.61% of statistics that get made up on the spot.

I hope this isn’t perceived as a rant, diatribe, or flame.I’m just trying to help people not to make the same mistake that so many people have already made (and in many cases, are still making).

As my final plea, please don’t depend on javascript for validation. Use it if you like, but back it up with all the same (or better) validation on the server side. It will make you much happier.

– Mac Newbold

First, it checks it with a regular expression, to verify that it uses valid characters for the various parts of the address, and there is an @ and at least one period, and they’re in the right places. Second, it turns to DNS to verify that the domain exists. (DNS calls will probably need tweaking to work on Windows servers.) Best case is that it has an MX record for the domain. Second best is to verify that the domain simply exists and has an address. If it can pass the regular expression test and the DNS test, then it is most likely a valid address. The things we can’t easily check are user-related, like user doesn’t exist, has exceeded quota, etc.

In places where I’ve done comparisons with and without this checking in place, I’ve found very significant reductions (probably around 80%) in the number of bounced messages. While this can be used just before sending, it’s often best to use it when accepting the email address from the user, to prevent bad addresses from getting into the system in the first place, and catch typographical errors. In cases where a long time has passed since the email was known to work, it may be helpful to check before sending the message as well.

function ValidateEmail($e,$v=-1)
{
	global $verbose;

	/*	Return codes:
   	0: appears to be a valid email
   	1: didn't match pattern of a valid email
   	2: looks valid by the pattern, but no DNS records found

  		Try several things to make sure it is most likely valid:
   	1. preg_match it to make sure it looks valid
   	2a. If that passes, check for an MX entry for the domain
   	2b. If no MX, check for any DNS entry for the domain
		*/

	if ($v==-1)
	{
		$v=$verbose;
	}

	if (!preg_match("/^[a-z0-9.+-_]+@([a-z0-9-]+(.[a-z0-9-]+)+)$/i",
		$e, $grab))
	{
		return 1;
	}

	# $grab[0] is the whole address
	# $grab[1] is the domain

	$domain = $grab[1];
	$cmds = array("host -t MX $domain 2>&1 ","host $domain 2>&1 ");

	foreach ($cmds as $cmd)
	{
		$dns = trim(`$cmd`);

		if ($v)
		{
			print "n";
		}

		if (strpos($dns,"$domain mail is handled ")!==false ||
			strpos($dns,"$domain has address ")!==false ||
			strpos($dns,"$domain is an alias ")!==false)
		{
			# It is valid
			return 0;
		}
	}

	# If it didn't return yet, it's invalid, even
	# though it passed the preg.

	return 2;
}

Questions, comments, and suggestions are welcome.

- Mac