Category Archives: Database

Keyspace on the back of an envelope

Posted on by
Reply

One question that always plagues me: should I use 32-bit or 64-bit keys. I can never make a firm decision on this point. But I’ve just done some back of the envelope calculations in thinking about it.

If you issued one identity per second, every second of every day, it would take 136 years to exhaust the keyspace.

If you issued one thousand identities per second, it would take 50 days to exhaust the keyspace.

Things You Should Know About Databases

Posted on by
1

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.

The Database Relational Fuckup

Posted on by
Reply

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 [52] for further elaboration on this point.

Reference [52] 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.