|
|
12.10.2011, 10:15
|
#1 |
|
Moderator
|
Я с этим сталкивался. (Правда это не мой проект был, я там приходящий консультант
 ). Там просто сделали дополнительное поле (типа CombinedDim), которое при любой вставке заполняют комбинацией вида Dim1+'#'+dim2+'#'+dim3. И именно это поле засунуто в индекс вместо трех обычных полей. Правда это привело к некоторым (не критичным) проблемам производительности. Во первых - они там побоялись заменить в inventDim::findDim() старые поля на новое (то есть - в индексе комбинированное поле, а в select where - три некомбинированых). Из за этого чуток (думаю - процентов на 10) падает производительность поиска по таблице (на самом деле оставшихся 13 полей вполне хватает для нужной селективности), и заметно падает производительность кэширования (поскольку из кэша AOS вынимает данные только если в select where стоит комбинация всех полей из уникального индекса). Соответственно - любой вызов findOrCreate гарантировано ведет в передаче select к серверу базы данных. Я клиенту предлогал метод подправить, но они мне сказали что производительности пока хватает, сервер мощный, и от добра добра не ищут...P.S. Но было бы лучше, если бы вы больно попинали группу MS SQL, чтобы в следующей версии они довели бы число поддерживаемых полей в индексе до 32
Последний раз редактировалось fed; 12.10.2011 в 10:24. |
|
|
|
12.10.2011, 11:03
|
#2 |
|
Участник
|
Цитата:
Сообщение от fed
P.S. Но было бы лучше, если бы вы больно попинали группу MS SQL, чтобы в следующей версии они довели бы число поддерживаемых полей в индексе до 32
|
|
|
|
12.10.2011, 12:57
|
#3 |
|
Модератор
|
Цитата:
Сообщение от Alexius
И до кучи еще расширили ограничение в 900 байт, а то в юникоде в него легко можно упереться
 P.S. А с пожеланиями по SQL Server лучше сюда
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
|
12.10.2011, 13:12
|
#4 |
|
Участник
|
Цитата:
Сообщение от Vadik
Что-то вы люди не то индексируете по-моему
|
|
|
Комбинированный вид
