foreign key

Subtle SQL differences: Constraint names

The various SQL product vendors implement subtle differences in the way they interpret SQL. In this case, I’ve been examining the reuse of constraint names within a schema / database (which is yet another story: what’s a schema, what’s a database?). Here’s the summary:

Constraint names are unique within a schema

  • Derby
  • H2
  • HSQLDB
  • Ingres
  • MySQL
  • Oracle
  • SQL Server

Constraint names are unique within a table

  • DB2
  • SQLite
  • Sybase SQL Anywhere

The “weird ones”

  • Postgres: Foreign Key names can be reused. Unique / Primary Key names cannot
  • Sybase ASE: Unique / Primary Key names can be reused. Foreign Key names cannot

For most compatibility across databases, it is never a good idea to re-use names. Keep your constraint names unique across a schema.

How schema meta data impacts Oracle query transformations

I was recently wondering about some issue I had encountered between two tables. If tables undergo a lot of INSERT / UPDATE / DELETE statements, it may appear to be better to remove some constraints, at least temporarily for the loading of data. In this particular case, the foreign key relationship was permanently absent and I found the join between the two tables to be a potential source of bad query execution plans in greater contexts. So my intuition told me that this could be optimised by adding the constraint again, as Oracle would then be able to formally use that information for query transformations. I asked the question on Stack Overflow and it seems I was right:

http://stackoverflow.com/questions/8153674/do-foreign-key-constraints-influence-query-transformations-in-oracle

But what does that mean? It’s simple. If you have two tables A and B, and you join them on A.ID = B.A_ID, having a foreign key constraint on B.A_ID may make all the difference. Let’s say, you execute this:

select B.* from B
join A on A.ID = B.A_ID

Without a foreign key on B.A_ID

When B.A_ID is set (i.e. is not null), there is still no guarantee that there actually exists a corresponding A.ID. A is not part of the projection. Intuitively, it is thus not needed, but it cannot be optimised away, because the query will actually have to check for existing A.ID per B.A_ID.

With a foreign key constraint

When B.A_ID is set, then there must be a corresponding, unique A.ID. Hence, the JOIN can be ignored in this case. This has powerful implications on all sorts of transformation operations.

For more details, have a look at Tom Kyte’s presentation “Meta Data Matters”