1) triggers - mysql
2) views - mysql (http://hudzilla.org/phpwiki/index.php?title=Using_views)
3) referential integrity - mysql (http://hudzilla.org/phpwiki/index.php?title=Enforcing_referential_integrity)
4) subselects - mysql (http://hudzilla.org/phpwiki/index.php?title=Using_subselects)
5) LOW_PRIORITY HIGH_PRIORITY - mysql (http://hudzilla.org/phpwiki/index.php?title=Adjusting_the_priority_queue)
6) Table Joins - mysql (http://hudzilla.org/phpwiki/index.php?title=Table_joins)
7) Do this: echo "Foo", somefunc(), " bar ", anotherfunc(); not: echo "Foo".somefunc()." bar ".anotherfunc();
8) pre-incrementing is faster ++$var
9) Cache pages

10) How to solve session fixation? There are several ways:

    * When a real session is created, set a value in there such as IS_SAFE.
    * Change session IDs on privilege elevation
    * Store user-specific data in sessions that can be checked 

The first option sounds like it might work, but ends up being no better. Yes, it does stop hackers plucking session IDs such as abc123 out of thin air, but it doesn't stop them going to your site, getting a real session ID, and using that. Essentially they create the session themselves, and use the valid session ID given back to them by your site to ensnare others.

The second option requires a little explanation. "Privilege elevation" is where users change from being an Internet visitor indistinguishable from anyone else to being someone with some sort of rights. The most common example of this is when people log-in to your website: they now have privileges, and so should have their session changed. Changing session ID isn't hard; in fact, it's just one call to session_regenerate_id(). Note that session_regenerate_id() takes no parameters and returns no meaningful value, it simply changes the session ID to a new, random one. In order to do this, it must send a cookie back to the client: this means you must use the function before any HTML content is sent, or enable output buffering.

Regenerating the session ID on privilege elevation works just fine: PHP automatically copies all the data from the old session to the new session, and leaves the old one intact too. This means that the legitimate, privilege-elevated user, gets to access all their data safely, while the cracker is looking at the stale file. Changing the session ID with session_regenerate_id() is very fast; I don't see any reason why you couldn't call it every page if you were really paranoid.

Moving on, storing user-specific data in the sessions so that you can see quite easily whether the current session user is the same as the user that created it is actually quite easy to do. It turns out the only data you can be sure to get from clients is a user agent (the browser name), but this is actually enough. Sure, 90%+ of people use Internet Explorer, but there are quite a few major versions of IE out there and many, many sub-versions. The IE installed on my Windows box gives the user agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)", and yours probably gives something very different. So, we can store this in our session as a known identifier of our user. If someone comes along with the same session ID, we can check their user agent against our stored value, and take immediate action if they differ. 

11) http://www.php.net/assert and http://www.php.net/assert_options
12) Tidy : http://hudzilla.org/phpwiki/index.php?title=Output_style
13) SQLite: http://hudzilla.org/phpwiki/index.php?title=Introducing_SQLite
14) Output Buffering: http://hudzilla.org/phpwiki/index.php?title=Output_buffering
15) PEAR::DB : http://hudzilla.org/phpwiki/index.php?title=Introducing_PEAR::DB

http://oss.backendmedia.com/MDB2/ExampleS
http://phplens.com/lens/adodb/docs-adodb.htm#connect_ex