Questions about database indexes

Question

1. When a database index is created for a unique constraint on a field or multiple indexes are created for a multiple field unique constraint, are those same indexes able to be used for efficiency gains when querying for objects, much in the same way any other database index is used? My guess is that the indexes created for unique constraints are the same as ones created for efficiency gains, and the unique constraint itself is something additional, but I'm not well versed in databases.
2. Is it ever possible to break a unique constraint, including a multiple field constraint (e.g. field_a and field_b are unique together) in any way through long transactions and high concurrency, etc? Or, does a unique constraint offer 100% protection.

Answer 1

As to question 1:

YES - these are indexes as any other indexes you define and are used in query plans for example for performance gains... you can define unique indexes without defining a "unique contraint" btw.

As to question 2:

YES - it is a 100% protection as long as the DB engine is is ACID compliant and reliable (i.e. no bugs in this regard) and as long as you don't temporarily disable the constraint.

Answer 2

1. Yes. A unique constraint is an index (in SQL Server) and will (can) be used in query plans

2. This is impossible. Regardless of transaction times or concurrency issues, you cannot store data in a table that violates a constraint (at least in SQL Server). BTW, if your transactions are so long that you're worried about this, you NEED to rethink what you're doing in the context of this transaction. Even though you won't violate database constraints with long transaction operations, YOU WILL run into other problems.

Answer 3

The problem with your question is, that it is very general and not tailored to a specific implementation. Therefore any answer will be quite generic to.

In this mind:

1. Whenever a database thinks, that access via an index might speed up things, it will do so - uniqueness is not concern here. If many indizes exists on one table a decent database will try to use the "best" one - with different views about what "best" means actually. BUT many databases will only use one index to get a row. Therefore as a rule of thumb DBs usually try to use indizes where lookups result in as few rows as possible. A unique index is quite good at this. :-)

2. Actually this is not one point but two different points:

   • A decent DB will not corrupt your index even for long running transactions or high concurrency. At least not on purpose. And if it does it is either a bug in the DB software which has to be fixed very quickly - otherwise the DB vendor might suffer reputation loss in a very drastic way. The other possibility is, that it is not a decent DB but a mere persistent hashmap or something like that. If the data really matters, then high concurrency and longrunning transactions are no excuse.

   • Multivalued unique indices are a beast: DB implementations are silghty different, what they consider "unique" when one or more of the key columns contain NULL. For example you can look at the PostgreSQL documentation regarding this point: http://www.postgresql.org/docs/9.1/interactive/indexes-unique.html

Hope this makes some things clear.