>> Вы совершенно бессовестно в своем ответе порезали начало его ответа, где он
>> вел речь о разреженных данных. И именно в этом контексте говорил,
>> что возможно лучше от индекса в таком случае вообще отказаться.
> Фух, это, наверное, магнитные бури какие-то.наверное...
> Нет в мускле никаких "разреженных данных". Нетути.
это общее понятие для ВСЕХ реляционных БД. Вы мускул к ним не относите?
>Есть понятие кардинальности ключа -
> отношение числа уникальных значений ключа к размеру таблицы К є ]0,1].
> Чем выше кардинальность ключа, тем меньше строк соответствует запросу, тем меньше
> временные таблицы, тем меньше накладные расходы, тем выше скорость выполнения. Скорость
> выполнения зависит не от "разреженности таблиц", а от объемов промежуточных вычислений.
> Оптимайзер мускля автоматически и довольно эффективно выстраивает подзапросы в порядке
> убывания кардинальности, чтобы минимизировать размеры временных таблиц. На "разреженность
> данных" ему начхать, он про такое ни сном, ни духом.
угу - все умные читать и цитировать, а понимать что читали не хотят:
1) отношение уникальных значений ключа к размеру талицы (цитирую Вас)
2) если в ключе возможно присутствие NULL-значений (читай - разреженные данные) и число записей в таблице велико, то прикиньте для себя "кардинальность" такого ключа. стоит его создавать?
> Если девелупер в таблицу вставляет поле {0,1,NULL}, и строит по нему индекс,
> да еще потом по этому полю начинает искать, то это не
> "разреженные данные" - это разжиженные мозги. В таком случае не _отказываться_
> следует от индекса, а не строить его изначально. Следует проектировать базу
> таким образом, чтобы поле с низкой кардинальностью не использовалось соло, а
> только в качестве финального аккорда в рефайне выборки по более подходящим
> полям. Потому что в противном случае боттлнек случится даже не по
> времени выполнения запроса, а по ОЗУ, в котором тупо не поместится
> временная таблица.
1)
индекс по значениям поля {0,1,NULL} Вы делать не станете (тут все очевидно - не зависимо от разреженности данных делать ключ с ограниченным количеством уникальных значений смысла не имеет), а по значениям {0-1000000,NULL}? Вот тут учитывать разреженность данных при создании индекса имеет смысл.
2)
про разжиженные мозги себе почаще напоминайте, ибо именно после девелоперов остаются БД, которые сопровождать должны другие люди (и структуру БД сильно уже не поменяешь из-за привязки к софту). эти "крутые" девелоперы кладут даже на нормальзацию БД, дабы побыстрей денег срубить или клиента на подсос суппорта посадить. пояснить Вам связь отсутствия нормализации БД, разреженности данных и принятия решения о построении индекса по этим данным?
> Как-то так, примерно. В любом случае вот это:
> "..на больших наборах сильно разряженных данных стоит вобще отказаться от индекса, так
> как бд сначала бежит по индексу а затем по данным и
> то и то занимает одинаковое время.."
> к нашей вселенной отношения не имеет.
Разве, что Вы в другой вселенной живете или понятие "разреженные данные" (что скорей всего) Вам просто не знакомо...
PS
1) считаю, что querty абсолютно прав
2) нахальные высказывания (без всякого повода) в отношении других участников форума, считаю сволочизмом
3) поскольку разговор уже не в заданную тему - закрываю ее для себя
Вариант для распечатки
on 04-Июл-12, 23:02 
