Do columns with a unique-constraint need to be indexed?

I am using Hibernate to add unique-constraints over certain columns in my table as follows uniqueConstraints = {@UniqueConstraint(columnNames = {"warehouseCode", "orderCode", "vendorId"})},. I need to add an index over these exact columns as well. My question is, do I need to explicitly create an index for these columns, or does the unique-constraint automatically do it for me?

Technically, a unique constraint does not actually guarantee that an index will be made, but I'm not aware of any DB engine that doesn't.

Note that a DB engine is nevertheless fully free to treat them differently, and many DBs do just that. However, there is such a thing as a unique index - and you'd need to compare one of those to a unique constraint to see meaningful differences. A unique index can be disabled, which in passing then disables the uniqueness checking (at least, on most DB engines). A unique constraint often cannot.

In DB land, the advice is to make a unique index if you actually intend to use it as an index, and to make a constraint if you just care about uniqueness. As I said, in practice, every DB engine I know implements a unique constraint by making an index, and every DB engine I know will use that index for general queries because it is there.

How does this all translate to hibernate? That's the problem with hibernate - you're just adding to the learning curve and simplify nothing, because often you need to know what's happening on the SQL side.

In this case, it translates quite badly, hibernate has a bit of an oversight and does not appear to understand that there is such a concept as a 'unique index'.

EDIT

Thinking about it some more, this really is nuts - there are good reasons to want an index, specifically. For example, let's say you want an index on a asc, b desc, c asc, which cannot be faked in any way with e.g. a asc, b asc, c asc. And you also want uniqueness over a/b/c in one go. Just about every DB engine can do this efficiently by way of making an index of a asc, b desc, c asc, and adding the UNIQUE keyword as you make it.

If hibernate cannot be cajoled into making such a thing, that sure sounds like hibernate is not fit for purpose.

I'm trying to find docs on how to make it, but I just can't find it. It's bizarre. Can hibernate really not do this?

Note that tools like JDBI and JOOQ exists, which let you actually do SQL things. If you're already familiar with DB engines and SQL and the like, and you're early enough in this project, you may want to look for how to make a unique index in hibernate, and if you cannot, consider switching.

END EDIT

So, you have three choices:

1. Make both an index and the unique constraint, doubling the DBs work, slowing everything down, and doubling the size of things. Pray that hibernate is smart enough not to actually make that index, but I doubt that's how it would work. Given that it's a 3-field index, it's a pricey one, this does not sound like a good idea.

2. Leave it as is, and rely on the fact that all DB engines will be implementing this with an index and will use that index for queries as well, even though it's not quite the right 'style' especially when connecting straight to the DB.

3. File a feature request with hibernate or look up how you can flag an index as 'requires uniqueness' within hibernate's @Index functionality.