Click through for a larger version. The text:

It helps ensure data consistency and integrity. This may not seem important at first. But it becomes critical when you want to query or sort that data.

For example, we have three books by Toni Morrison in the database. if we stored author information in the same table, every time someone wanted to add a Toni Morrison book, they would have to type “Toni Morrison” in the author field.

That’s fine, as long as this person types well. But letters often get transposed, and some names are easy to misspell. If a user enters “Toni Morisson,” that book title won’t appear in a “Toni Morrison” search. We can help ensure data consistency with a separate authors table.

For D.

For this tutorial, you will need:

• A Zen Cart-based shopping cart
• A Google Analytics account and the tracking code for both conversions and page views.
• Experience with PHP and MySQL programming

Also check out Google’s support article How do I track e-commerce transactions? and become BFFs with the Zen Cart wiki.

Creating a custom functions file

Create a file to house your custom functions. Name it whatever you’d like (with a PHP extension, of course). Put it in your includes/functions/extra_functions/ directory.

A word of caution: I created these functions with my own SQL, outside of the Zen Cart framework. There may be a better way to do it.

In the file you created above, add the following code:

# get the product ID out of session key
function custom_get_prodId($productkey){
	$pid = explode(':',$productkey);
	return $pid[0];
}

#get the product data
function custom_get_product($prodID,$return='all'){
	global $db;
	reset($data);
	$q = sprintf("SELECT
			pd.products_name,
			pd.products_description,
			cd.categories_name, p.products_price
			FROM categories_description AS cd, products AS p, products_description AS pd
	 		WHERE  p.products_id = 183
   				AND p.master_categories_id = cd.categories_id
   				AND p.products_id = pd.products_id",$prodID);
	$res = $db->Execute($q);
	return $res->fields;
}
# get the current user's data
function custom_get_userinfo($custID){
	global $db;
	reset($data);
	$q = sprintf("SELECT
			ab.entry_street_address,
			ab.entry_postcode,
			ab.entry_city,
			ab.entry_state,
			c.countries_name,
			c.countries_iso_code_2
			FROM address_book AS ab, countries AS c
			WHERE customers_id=%d
			   AND ab.entry_country_id = c.countries_id
				  ",(int)$custID);
	$res = $db->Execute($q);
	return $res->fields;
}

Adjust the names of the tables if you have added a custom table prefix during your Zen Cart configuration. We’ll use these functions to get us the user data and product data we need.

Edit the checkout success and global footer files

Add the conversion tracking code — provided by Google Analytics — to the checkout success page template. It’s located in your templates directory, includes/templates/YOUR_TEMPLATE_DIR/templates/tpl_checkout_success_default.php.

Also add the regular Google Analytics tracking code to your footer file (found in includes/templates/YOUR_TEMPLATE_DIR/common/tpl_footer.php).

Below your Google Analytics code, but also in your footer file, add the code below.

<?php
# do this on the checkout success page only.
if($_GET['main_page'] == 'checkout_success'): 

$userdata = $_SESSION['cart'];
$moreud = custom_get_userinfo($_SESSION['customer_id']);
?>
<script type="text/javascript">
pageTracker._addTrans(
    "<?=$userdata->cartID; ?>",
    "www.YOURDOMAINNAME.com",
    "<?=$userdata->total; ?>",
    "",
    "<?=$_SESSION['shipping']['cost']; ?>",
    "<?=$moreud['entry_city'];?>",
    "<?=$moreud['entry_state'];?>",
    "<?=$moreud['countries_name'];?>"
  );
<?
# for each product ID key in the userdata session
foreach($userdata->contents as $k=>$v):
	/*
	the product id gets stored as an array key as xxx:funkymd5key
	ex: 183:fw920e8ktw327uio67xew9mn. custom_get_prodId extracts
	the product id part of that key.
	*/
	$pid = custom_get_prodId($k);
	$data = custom_get_product($pid,'all');
?>

 pageTracker._addItem(
    "<?=$userdata->cartID; ?>",
    "<?=getProdId($k); ?>",
    "<?=strip_tags($data['products_name']);?>",
    "<?=$data['categories_name'];?>",
    "<?=number_format($data['products_price'],2);?>",
    "<?=$v['qty']; ?>"
  );
<? endforeach; ?>
pageTracker._trackTrans();
</script>

<?php endif;
} // flag_disable_footer
?>

PHP supports more than a dozen database setups, including the SQLite library bundled with PHP 5. That’s a lot of databases, and each one has its own connection syntax and server-specific functions.

So what happens when you want to be able to swap one database for another? You turn to an abstraction library, such as PDO.

In Learning PHP Data Objects, Dennis Popel takes you through the process of building an application using PDO with MySQL and SQLite.

Aimed squarely at PHP developers who are new to PDO, Popel covers how to make connections, handle errors, and use prepared statements with PDO. He also discusses transactions, MVC development, and the appropriateness of using PDO versus other abstraction libraries.

Where Learning PHP Data Objects shines, however is in its code examples. They are easy to follow, and Popel smartly alerts readers to potential gotchas in developing the sample application.

The book assumes an understanding of OOPHP — necessary because PDO is entirely object-oriented. To get the most out of it, you should be familiar with object-oriented principles and syntax. While Appendix A does give readers a quick overview of OOPHP, for a more thorough treatment, you’ll need to look elsewhere.

It’s a solid, though not quite perfect book. For example, Popel only sort-of mentions a potentially huge gotcha: when you may need to specify a unix_socket parameter in the connection string. It’s a problem I think would be common enough and confusing enough to discuss and demonstrate. I also think Popel could have been a bit clearer about when and why to use PDOStatement->closeCursor().

Those are minor quibbles however, easily solved by consulting the documentation or doing a Google search. Overall, this book is nice introduction to the whys and hows of using PDO to develop database driven applications.

It’s counterintuitive to a degree, but it’s actually expected behavior. The good news is that the fix is easy. Simply include the unix socket path in your connection string.

$connection = new PDO("mysql:host=localhost;dbname=test;unix_socket=/path/to/socket/found_in_php.ini_or_my.cnf",'username','password');

Related: Notes from “Introduction to PDO,” a talk by Ilia Alshanetsky at NYPHPCon 2006.

We’re using Google Analytics for high-level analysis such as referrals and search engine traffic. But we wanted to do more robust analysis. You see our conundrum, right? How do you track “pages” and visited “links” within a single Flash movie embedded in a single HTML page?

Simple: you build your own tracking system.

For this project, I used Flash’s LoadVars() object to talk to a PHP middle layer that writes and retrieves data to and from a MySQL database.

LoadVars() allows you to send (and receive) variables from a Flash movie to (or from) a server. You need a server-side script to process that information. Variables and values are sent to the server using either GET or POST. It’s just like submitting and processing a form — and should be treated like any other user-submitted data.

When you pass data from the server back to the movie, you send it as a query string, or an encoded URL (example: ‘car1=honda%20accord&car2=chevrolet%20tahoe’). Once the variable-value pairs are loaded into the movie, you can use ActionScript to determine how the movie handles that data.

The PHP scripts and the database

There are two PHP scripts at work here. One collects the data from the movie, escapes it, and writes it to the database. The other retrieves data from the database, encodes, and returns it to the movie. We’re also using three separate database tables.

Table one contains the questions and answers contained in the movie. Each question and answer corresponds to a key. The next table tracks section visits in the aggregate. One column contains the keys from the questions and answers table. The other column keeps track of the count. I set an initial value of zero for each question-and-answer key in that column. Every time a section is visited, we update the count for that section by one. If we were using MySQL version 4.1 or later, we could have used the ON DUPLICATE KEY clause for INSERT. Instead, we’re using UPDATE syntax and adding one to the value of the count column.

The third table is where we store per-user data. We’re using server-based sessions to track visits by user. With each click, we capture the section being visited, the current session identifier, the user’s IP address and the time of the click. Collecting this user data allows us to do a few things:

• Determine where our visitors are coming from.
• Determine roughly how long people are staying on the site.
• Determine which section(s) the user has visited (and their answers).

That last portion is probably the coolest. At the end of each section of the movie, we return the user to a main menu. When that screen is loaded, a script queries the database to find which sections have been visited in that session.

Once MySQL returns those section keys, we build our query string. In my PHP code, I set each section variable equal to 1 (i.e. ‘section1=1&section22=1′). We pull this query string into our Flash movie by once again using LoadVars().

After these variables are loaded, we can use ActionScript to make the movie take a particular action. In this case, I tested to see whether the variable exists (example: if(section1){scroll_mc.gotoAndPlay(23);}). If it does, the movie goes to the scroll movie clip and plays from frame 23. If it doesn’t, the scroll movie clip plays from frame one.

All of this means we have some solid data to analyze both in terms of traffic and — because we’re tracking answers — how well our messaging is being received.

You can see the new tracking system in effect by visiting the site.

• Set zend.ze1_compatibility_mode = Off. You’ll need access to your php.ini file to do this. If you’re receiving a cloning error (“Trying to clone an uncloneable object of class mysqli”) when trying to create an instance of mysqli, try this.
• Check your MySQL configuration file (mysql.cnf, my.cnf, or the like) and use the socket specified there. By default, mysqli will attempt to connect through /tmp/mysql.sock. If your socket path is not /tmp/mysql.sock, the connection will fail.

What I’ve done in the past is make the id field a PRIMARY key and didn’t bother with a unique key. Now I’m wondering if making the ID a unique key makes more sense because I’ll be using it as a key in another table.

Thoughts? Help?

These are my notes from a presentation by Ilia Alshanetsky. This post may contain inaccuracies, typos, boo-boos, etc.

PDO stands for “PHP Data Objects Layer”: A data-access abstraction layer.

• Common interface for any number of database systems
• PHP extension
• Designed to simplify features.
• Only available to PHP 5 or 5.1; requires a level of OOPHP that’s only available to PHP 5

Why PDO?

• Consistency of development across databases; code is the same for MySQL, PostgreSQL, Oracle, etc.
• Current APIs don’t take full advantage of new PHP’s features
• Current APIs don’t take full advantage of all of the features available in the database

Installation

• Need to install PDO, made up of the core and the drivers.
• Can install using PECL.
• Can install by recompiling PHP

Using PDO

• Create an instance of the object.
• PDO uses a single connection string as the lone parameter.
  • Connection failure handling: Instantiation failure causes an exception error. Use inside of a try…catch block to retrieve and log the error number.
  • Functions available to report errors

Persistent Connections

• Persistent connections help speed up web apps, particularly with Oracle and PostgreSQL databases
• Create persistent connections using a class constant ATTR_PERSISTENT
• Will need to figure out how many connections you will have at one time (MySQL makes quick connections. Don’t really need to make a persistent one, but likely won’t hurt)

Direct Query Execution using PDO

• Queries that modify information use the exec() method.
• Return value is the number of rows affected by the operation. Returns boolean FALSE on error (INSERT, UPDATE, DELETE).
• Queries that select information use the query() method.

Problems with direct queries

• Query needs to be interpreted on each execution. Can be a waste for frequently repeated queries.
• Security issues with un-escaped user input can lead to SQL injection.
• Escaping: quote() method. Handles special characters in PDO. Quote automatically adds single quotes to wrap the query: "SELECT * FROM USERS WHERE".quote($variable)." LIMIT 0,1"

Prepared statements

• Compile once and execute many times
• Separation between structure and input to prevents SQL injections
• Often faster than query()/exec() even for single runs.
• Uses wildcards/tokens to hold variables; those variables are handled as a parameter, making injection attacks much less likely (bound parameters)

Retrieving information using PDO

• Array (Numeric or associative)
• String (for single column result sets; ex: selecting an id from a user login table)
• Fetch into a class
• Objects
  • Ability to retrieve data into an object
  • Ability to retrieve data into an exisiting object
• Callback Function
• Lazy fetching
• Iterators

Result Iteration – Fastest way of retrieving data through PDO

$res=$db->query("select * from users",PDO::FETCH_ASSOC);
foreach($res as $row){
   // returns an associated array
}

Lazy fetches

• Lazy fetches results in a form object, but holds the populating properties until they are actually used.
• Prevents PHP from fetching the data until you use it.

Related links

• PDO Functions
• Prepared Statements and Bound Parameters (from an article about using ext/mysqli)

This is part three of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Benchmarking and Profiling tips

• Give yourself a target
• Record everything
• Isolate the problem (Shut down other programs. Stop network traffic to machine.)
• Get familiar with EXPLAIN as a means to optimize queries
• Optimize within reason. Makes more sense to speed up the 30 second query than the 1 second query.

Benchmarking Toolbox

• SysBench
• mysqlslap (MySQL version 5.1+)
• Apache bench
• Supersmack
• MyBench

Profiling: Diagnosing a running system to identify performance bottlenecks

Possible areas for bottlenecks:

• Identify performance bottlenecks
• SQL Coding and Index Usage
• Memory
• CPU
• I/O (Disk)

Profiling toolbox

• SHOW commands (SHOW PROCESSLIST, etc…)
• EXPLAIN and the Slow Query Log
• MyTop
• List of Linux Power tools (gprof/oprofile and vmstat.ps/top/mpstat/procinfo)
• apd for PHP developers

Jay Pipes is the Community Relations Manager, North America for MySQL, Inc. This was a three-hour tutorial about ways to fine-tune your MySQL queries.

This is part two of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Developing a database schema

• Use the smallest data type necessary
• Normalize your data; Denormalize only in extreme cases
• “Vertical partitioning”: Send to a different database based on the range of a key.
• Use ‘counter tables’ to mitigate query cache issues in InnoDB tables
• “Horizontal partitioning”: Split data into smaller tables. Put less-frequently accessed, less-frequently updated data in a separate table. Example: have separate tables for user logins and user addresses or interests.

Use indexes wisely

• Should have good selectivity (relative uniqueness of the index values to each other; there’s a way to calculate this)
• Look for ‘covering index’ opportunities
• On multi-column indexes, order is important
• As database grows, examine your index. Do you need to modify it?
• Remove redundant indexes for faster write performance. Don’t need more than one index on a field.

Coding tips

• Don’t think in a procedural programming style. Think about ‘sets’: you have two sets of data from which you need to retrieve data. How do you do this?
• Break queries into smaller units
• Use stored procedures (only available in MySQL 5.x)
• Learn to use JOINS effectively. Can often use a join instead of a subquery.
• When you use a function on an indexed function, the index will be ignored
• Use the ON DUPLICATE KEY UPDATE clause of the insert statement. No need to check first if the record exists then update or delete (Related: INSERT ON DUPLICATE KEY UPDATE and summary counters)
• TRUNCATE TABLE is typically faster than deleting records

Bulk loading performance

• Always use multi-record INSERT for mass bulk uploading
• Use ALTER TABLE … DISABLE KEYS syntax. It disables all indexes except for unique ones
• Use load data infile, or CSV storage engine (version 5.x only), then ALTER TABLE
• If loading into an InnoDB table, insert into a MyISAM table, then select from there into an InnoDB table
• To add or drop multiple indexes, use ALTER TABLE rather than multiple CREATE or DROP INDEX statements

Jay Pipes is the Community Relations Manager, North America for MySQL, Inc. This was a three-hour tutorial about ways to fine-tune your MySQL queries.

This is part one of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Indexes

• Gives you a sorted order that allows you to find things quickly.
• Indexes speed up select or read statements.
• Indexes slow down writing to the database because MySQL not only has to write the record, but also has to write the index.

The kind of indexes available and their efficiency depends on the type of storage engine you choose. Keep your indexes slim on write-intensive applications.

Types of storage engines

Choose your table’s storage engine type based on the type of information it holds, and the function for which you will use the table. Can mix table types in the same database.

MyISAM

• Unclustered data storage
• Good insert performance and good with concurrent inserts
• Small foot print
• B-tree, r-tree and FULLTEXT indexing; Can use for spatial calculations, such as ZIP codes
• Poor concurrent update and delete performance
• No foreign key support; You can use a foreign key, but relational integrity is not guaranteed. (Forthcoming in version 5.2)
• No transactions available

Good for warehousing data, logging data and auditing data.

InnoDB

Good for when you need a lot of concurrent updates and will be looking data up by ID. Good for online transaction processing.

• NO FULLTEXT indexing or spacial data (r-tree indexes).
• Large memory usage and a large data footprint.
• Full transactional support
• Support for foreign keys
• Be sure to set a primary key, and use the smallest possible key (INT not BIGINT). If you don’t InnoDB will create it’s own super-integer index. Because of the way InnoDB handles indexes, this is not desirable.

Archive

Good for archiving, audit logging, and distributable media (for example, applications that you don’t want the user to be able to modify).

• Quick inserts and table scans
• Read-only
• Zlib compression
• No indexes allowed
• No foreign key support

Memory / HEAP

Great for temporary tables, session data, calculation tables, or information that will be requested frequently.

• Very, very fast selects because it’s all stored in memory
• Supports hash or b-tree indexes
• Data is gone on reboot, but you can get around this with init_file or my.cnf/my.ini.
• Limited by amount of memory available on the server

Can combine engine types within the database to take advantage of each storage engine’s strengths.

SELECT field_name, COUNT(*) AS total
FROM table_name WHERE id > 3
GROUP BY field_name ORDER BY total ASC;

The ‘AS total’ bit is a big deal because now COUNT(*) will become a key named ‘total’ in the array. So instead of $result['COUNT(*)'], you’d use $result['total'];

Type in your search terms and hit Enter. The page you come to will be the first Google result — same as if you hit the “I’m Feeling Lucky” button on the Google homepage.

Wow … Gmail has Atom feeds!

I just realized this today. Which is kind of funny since I use Gmail on Firefox daily. Not real observant am I? Or maybe it’s a new thing for my particular account. Anyway, you can now have an XML feed of your email messages stored in your Firefox live bookmarks (or what have you).

Now, if you still don’t have a Gmail account, I’ve got an a**-load of invites to share. Me thinks Gmail will be out beta by summer. … um, maybe fall.

MySQL’s COUNT(*) …

… function is my new best friend. It makes it easier to sort and count how many of each item exists in the database. The syntax is simple:

SELECT field_name, COUNT(*)
FROM table_name
GROUP BY field_name;

The above query will sort each record based on its result. So if, for example, you a database of dogs, and you have a field name called “breed,” the above query would count how many German shepherds, Labrador retrievers, shi-tzus and pulis are in the database.

Now the cool part is that you can add criteria to the COUNT(*) query, just as you would with a regular SQL statement. For example:

SELECT field_name, COUNT(*)
FROM table_name WHERE id > 3
GROUP BY field_name;

And you can even sort the results by COUNT(*) like so:

SELECT field_name, COUNT(*)
FROM table_name WHERE id > 3
GROUP BY field_name ORDER BY 'COUNT(*)' ASC;

Note that in the ‘order by’ clause, COUNT(*) needs to be enclosed in quotes so that MySQL handles it as a field name, rather than a second invocation of the function.

When using MySQL with PHP, COUNT(*), ‘COUNT(*)’ becomes a key in the the array returned from a select statement.

To illustrate the point:

$query="SELECT breed, COUNT(*) FROM dogs GROUP BY breed";
$doQuery=mysql_query($query);
$result=mysql_fetch_array($doQuery)

The above code returns an array called $result. To use the keys and values in that array, you’d use the same syntax that you would for any other array. In this case, that’s $result['COUNT(*)'].

I wanted users to be able to search whole names (such as “Tiffany Brown”). But I couldn’t figure out how.

Here’s a query similar to the original:

SELECT * FROM membership WHERE firstName OR lastName LIKE '%$searchTerm%';

Those % signs are wild card symbols in SQL.

But the above query would only allow users to search for a member’s first name or last name.

CONCAT() to the rescue.

The CONCAT() function of MySQL server allows you to concatenate or put strings together [get a definition for 'string']. And here’s the handy part: when used in a query, CONCAT() will substitute the values in record for the names of the database fields.

That means you could use the CONCAT() function to do the following:


SELECT * FROM membership WHERE CONCAT(firstName,' ',lastName) LIKE '%$searchTerm%';


The above query would compare the value of $searchTerm to the concatenated string formed by the values for firstName lastName.

Here’s an example: let’s say you’re trying to find a member named Tina Jenkins. Running the above query would grab the string “Tina Jenkins” from the database, then compare it to the search term using the LIKE operator.

That means if you searched using “Tina”, “Jenkins”, “Tina Jenkins” or “Tina Jen”, you would find results for the member Tina Jenkins.

Thanks and shout-outs to Griff and kajakske over at SitePoint Forums for asking and answering a similar question.