diff --git a/2011-08-08-database-best-practices-for-future-scalability.html b/2011-08-08-database-best-practices-for-future-scalability.html index 132c959..840aeed 100644 --- a/2011-08-08-database-best-practices-for-future-scalability.html +++ b/2011-08-08-database-best-practices-for-future-scalability.html @@ -27,8 +27,7 @@
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.
Stop using AUTO_INCREMENT. Instead, keep a table IdSequences, and do something like:
-
-BEGIN;
+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’);
diff --git a/2011-11-29-safer-data-changes.html b/2011-11-29-safer-data-changes.html
index c289910..2416d47 100644
--- a/2011-11-29-safer-data-changes.html
+++ b/2011-11-29-safer-data-changes.html
@@ -10,8 +10,7 @@
-UPDATE Products SET Price=0.99 WHERE ProductId=2762 AND Price=1.00;
+UPDATE Products SET Price=0.99 WHERE ProductId=2762 AND Price=1.00;
This ensures that if something else changes Price just before you run your change, you don't destroy that update.