Я с этим сталкивался. (Правда это не мой проект был, я там приходящий консультант
). Там просто сделали дополнительное поле (типа CombinedDim), которое при любой вставке заполняют комбинацией вида Dim1+'#'+dim2+'#'+dim3. И именно это поле засунуто в индекс вместо трех обычных полей. Правда это привело к некоторым (не критичным) проблемам производительности. Во первых - они там побоялись заменить в inventDim::findDim() старые поля на новое (то есть - в индексе комбинированное поле, а в select where - три некомбинированых). Из за этого чуток (думаю - процентов на 10) падает производительность поиска по таблице (на самом деле оставшихся 13 полей вполне хватает для нужной селективности), и заметно падает производительность кэширования (поскольку из кэша AOS вынимает данные только если в select where стоит комбинация всех полей из уникального индекса). Соответственно - любой вызов findOrCreate гарантировано ведет в передаче select к серверу базы данных. Я клиенту предлогал метод подправить, но они мне сказали что производительности пока хватает, сервер мощный, и от добра добра не ищут...
P.S. Но было бы лучше, если бы вы больно попинали группу MS SQL, чтобы в следующей версии они довели бы число поддерживаемых полей в индексе до 32