Generated versions of previous two commits

2011-08-08-database-best-practices-for-future-scalability.html

@@ -27,8 +27,7 @@
 <li><p>Don’t store event-based data as one row per event. If you record page views or clicks in the database, aggregate that data into one row per hour, or per day. You can keep logs of events outside of the database in case you need to change aggregation and re-generate historical data, but don’t keep every event in a hot table.</p></li>
 <li><p>Stop using AUTO_INCREMENT. Instead, keep a table <a href="http://www.reddit.com/r/mysql/comments/jcw8o/database_best_practices_for_future_scalability/c2b2o4v">IdSequences</a>, and do something like: </p>
 
-<p><code>
-BEGIN;
+<p><code>BEGIN;
 UPDATE IdSequences SET LastId=LAST_INSERT_ID(LastId+Increment)
  WHERE TableName='A' AND ColumnName='b';
 INSERT INTO A (b, c) VALUES (LAST_INSERT_ID(), ‘foo’);

2011-11-29-safer-data-changes.html

@@ -10,8 +10,7 @@
 <li>Check the SQL files into source control somewhere. Manual changes tend to breed more manual changes to fix the fixes, so you never know when you'll want a record of what you twiddled in the past.</li>
 <li>Include all fields from the primary key in the WHERE clause. This ensures that each statement only modifies one row. Even if this results in a huge list of changes, at least you know exactly what changed.</li>
 <li>Include as many additional gating clauses as possible, linked with AND. For example, if you have a table of products and you want to set the price to 0.99 for everything that is currently set to 1.00, do:
-<code>
-UPDATE Products SET Price=0.99 WHERE ProductId=2762 AND Price=1.00;
+<code>UPDATE Products SET Price=0.99 WHERE ProductId=2762 AND Price=1.00;
 </code>
 This ensures that if something else changes Price just before you run your change, you don't destroy that update.</li>
 <li>Record the number of rows affected by each statement, in case something unexpected happens.</li>