This one popped up in my feed today: Things You Should Know About Databases. My favourite quote was this one:
The SQL standard defines 4 standard isolation levels these can and should be configured globally (insidious things can happen if we can’t reliably reason about isolation levels).
It’s so important to know what isolation level is applicable to your connection/transaction.
In his book The Database Relational Model on page 25 Date says:
Here I would just comment–here comes the hindsight once again–that if as suggested earlier the database is to be regarded as a (correct!) logical system, it must never be allowed to contain any inconsistencies, at least from the user’s point of view. In other words, “remedying inconsistencies” needs to be done on an individual statement-by-statement basis (not even on a transaction-by-transaction basis). See reference  for further elaboration on this point.
Reference  is then:
C. J. Date and Hugh Darwen: Foundation for Object/Relational Databases: The Third Manifesto. Reading, Mass.: Addison-Wesley (1998). A second edition of this book, under the revised title Foundation for Future Database Systems: The Third Manifesto, is due to appear concurrently with the present book.
I think Date did a lot of harm with this comment. The classic example of a transaction is taking $100 from my account and depositing it in your account. So there’s one statement to take the money out, and another statement to put the money in, and after the first statement but before the second statement the database will always go through an invalid state. If RDBMS integrity facilities were on a transaction-by-transaction basis we could actually use them, as they’re not we suffer. Either we need to do more work than necessary or we have to under specify our constraints, or some awkward combination of both.
In Database Design 25 – Surrogate Key and Natural Key the presenter Caleb Curry agrees with my view that if you expose your surrogate keys they become natural keys. See around t=5:00.
Today I discovered the UN Codes for Trade. It includes info about countries and locations, currency, etc.
This popped up on HN today, looks handy: The Connection Strings Reference. Well, I thought it might be handy, but it doesn’t seem to support PHP PDO.
I had this problem which is explained in greater depth over here.
Here’s some good documentation on PHP prepared statements and stored procedures including how to call stored procedures with output parameters.
The answer is no, so long as you’re not preparing to execute the statement again. I figured this out by looking at the code for PDOStatement::closeCursor and the MySQL implementation. Seems to me that all the freeing necessary is done in the destructor so if you’re not planning to use the statement again it seems to me that you can safely omit the call to PDOStatement::closeCursor(). On the other hand if you are going to reuse the statement calling closeCursor seems like it’s a pretty important thing to do. It would be nice if PDOStatement::fetchAll() called closeCursor() for us, but I don’t think it does.