Бла-бла о IN CLAUSE

[h1dd3n]

Сообщение от moka

Скорость работы IN, в зависимости от запроса может умножать сложность запроса кратной элементов в IN.
Так что если делаешь запрос на IN 10 ID например, то это скорее всего приведет к 10 кратному усложнению запроса, следственно в 10 дольше будет генерировать ответ. И это в хорошем случае когда индексы используются.

SELECT * FROM some_table
будет в 10 раз быстрее чем
SELECT * FROM some_table WHERE id IN [1, 5, 7]
??
херню понаписал как всегда.

Без индексов все может быть похуже, если первым используется другое поле, и затем из профильтрованных значений нужно делать проверку. То либо будет создаваться мелкий временный индекс по меньшему списку проверямых данных, и еще одна итерация по полям для сравнения, либо вообще O(a*b), что я надеюсь в дб движке избежали используя временный индекс.
Если используется временный индекс, то это использует RAM, индексы обычно легкие.

Во-первых, вот это - либо вообще O(a*b) объясни своими словами,
Во-вторых, какие еще временные индексы ? По твоему мнению по каким данным база должна построить "временный индекс" ?? Приведи пример запроса (с IN, разумеется) в котором использование этого самого "временного индекса" даст преимущество.

Не смотря на все это, использование IN с очень большими списками не рекомендуется.
Порой можно избежать подобного и структурировать данные более удобно для таких целей.

IN на 1000 или на 2000 вообще не проблема.

[moka]

Сообщение от h1dd3n

SELECT * FROM some_table
будет в 10 раз быстрее чем
SELECT * FROM some_table WHERE id IN [1, 5, 7]
??
херню понаписал как всегда.

Че? Два разных запроса полностью..

Я сравниваю:
SELECT * FROM some_table WHERE id IN [1, 5, 7]
И
SELECT * FROM some_table WHERE id = 1

В данном запросе, тут прямой hit по индексу.
А если поле не проиндексировано и не уникально, и у тебя 100 записей.

То будет O(a*b) либо O(a + b). В зависимости как реализован поиск, с или без временного индекса.

Сообщение от h1dd3n

Во-первых, вот это - либо вообще O(a*b) объясни своими словами,
Во-вторых, какие еще временные индексы ? По твоему мнению по каким данным база должна построить "временный индекс" ?? Приведи пример запроса (с IN, разумеется) в котором использование этого самого "временного индекса" даст преимущество.

IN на 1000 или на 2000 вообще не проблема.

Ты писал хоть раз простые функции поиска руками по своим данным?

Попробуй создай array и map данных, и напиши мелкий поиск по ним с IN функционалом на предпочитаемом языке. И посмотри на проблемы и скорости.

[h1dd3n]

Так что если делаешь запрос на IN 10 ID например, то это скорее всего приведет к 10 кратному усложнению запроса, следственно в 10 дольше будет генерировать ответ. И это в хорошем случае когда индексы используются.

В "хорошем случае с индексом":
SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10]
- 10 поисков по индексу
SELECT * FROM some_table WHERE id = 1
- 1 поиск по индексу
объем работы в первом случае в 10 раз больше, что, кстати, нихрена не означает что время выполнения запроса в целом будет в 10 раз больше.
В "плохом случае без индексов":
SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10]
- 10 раз full_scan
SELECT * FROM some_table WHERE id = 1
- 1 раз full_scan
объем работы снова в 10 раз больше.
Но ведь ты написал что в 10 раз больше когда "И это в хорошем случае когда индексы используются", в плохом соответственно время должно быть более чем 10 раз больше. Как же так ? (правильный ответ: мока балабол)

------------------

Ты писал хоть раз простые функции поиска руками по своим данным?

Попробуй создай array и map данных, и напиши мелкий поиск по ним с IN функционалом на предпочитаемом языке. И посмотри на проблемы и скорости.

Как же все-таки ты любишь уходить от ответа на вопрос...

Есть таблица, с колонкой name (индекса нету). В таблице 100000 записей. Я делаю следующий запрос:
SELECT * FROM some_table WHERE name IN [...],
где в in "закидываю" 250 имен. Какой "индекс" по твоему должен построить БД, и по каким данным ?
Даже ослу понятно что когда анализатор запроса видит in, то он парсит его не в массив, а в hashset, по которому поиск быстрый (ведь данные то отсортированы). Но никакого "индекса" он для этого не делает.
Никаких

Если используется временный индекс, то это использует RAM, индексы обычно легкие.

"легковесных индексов" там нету, более того если на вход пришло [5,2,3,2], то hashset который создасть mysql будет [2,3,5], то есть памяти даже меньше чем было бы если бы mysql не делал hashset. И ни при каких обстоятельствах там не будет больше потреблено памяти из-за "временных индексов", просто набор данных принятых в in будет отсортирован (объем памяти останется тот же).
----------------
Ну и наконец, то что ты как всегда проигнорировал:
Что же такое O(a*b) и O(a+b) ?? Это вычислительная сложность / big o notation?

[moka]

Сообщение от h1dd3n

В "хорошем случае с индексом":
SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10]
- 10 поисков по индексу
SELECT * FROM some_table WHERE id = 1
- 1 поиск по индексу
объем работы в первом случае в 10 раз больше, что, кстати, нихрена не означает что время выполнения запроса в целом будет в 10 раз больше.

Это же очевидно что не будет общее время в 10 раз больше.
Где было сказано что время работы будет в 10 раз больше? Там есть overhead на сам запрос по себе.

Сообщение от h1dd3n

В "плохом случае без индексов":
SELECT * FROM some_table WHERE id in [1,2,3,4,5,6,7,8,9,10]
- 10 раз full_scan

Твое заключение говорит что ты нихера не читаешь что я пишу. Не будет 10 раз full_scan в хорошем случае. Потому что можно сделать временный индекс по массиву данных переданных в запросе (IN), и один full_scan с проверкой по временному индексу. И я третий раз повторюсь: это при хорошей реализации дб движка.

Сообщение от h1dd3n

SELECT * FROM some_table WHERE id = 1
- 1 раз full_scan
объем работы снова в 10 раз больше.
Но ведь ты написал что в 10 раз больше когда "И это в хорошем случае когда индексы используются", в плохом соответственно время должно быть более чем 10 раз больше. Как же так ? (правильный ответ: мока балабол)

Когда индекс юзается, то бъет прямо по индексу, когда не юзается, может быть 10 full_scan'ов O(a*b), а может быть один с мелким индексом O(a + b).

Но ты любишь спорить, продолжай.

Сообщение от h1dd3n

Есть таблица, с колонкой name (индекса нету). В таблице 100000 записей. Я делаю следующий запрос:
SELECT * FROM some_table WHERE name IN [...],
где в in "закидываю" 250 имен. Какой "индекс" по твоему должен построить БД, и по каким данным ?
Даже ослу понятно что когда анализатор запроса видит in, то он парсит его не в массив, а в hashset, по которому поиск быстрый (ведь данные то отсортированы). Но никакого "индекса" он для этого не делает.
Никаких

"легковесных индексов" там нету, более того если на вход пришло [5,2,3,2], то hashset который создасть mysql будет [2,3,5], то есть памяти даже меньше чем было бы если бы mysql не делал hashset. И ни при каких обстоятельствах там не будет больше потреблено памяти из-за "временных индексов", просто набор данных принятых в in будет отсортирован (объем памяти останется тот же).

Лол.

Временный индекс === hashset === dict...
Терминология "индексация" (основываюсь на общении с англо-говорящими разработчиками) - значит создать hashset, dict, object, назови-свой, любой метод создания ассоциативных массивов (хэш таблиц).
У тебя пукан взрывается лишь по причине что ты термин не уточнил?

Сообщение от h1dd3n

Ну и наконец, то что ты как всегда проигнорировал:
Что же такое O(a*b) и O(a+b) ?? Это вычислительная сложность / big o notation?

Ты вроде же умного строишь из себя, а bit O notation в первый раз видишь?



Да и ты по теме чем помоги, а не офтопь..

[h1dd3n]

Лол.

Временный индекс === hashset === dict...
Терминология "индексация" (основываюсь на общении с англо-говорящими разработчиками) - значит создать hashset, dict, object, назови-свой, любой метод создания ассоциативных массивов (хэш таблиц).
У тебя пукан взрывается лишь по причине что ты термин не уточнил?

Во-первых, это не я уточнять термин должен, а ты сразу употреблять термин правильно. Это русскоязычный форум и термины ты должен употреблять принятые в русскоязычном сообществе.
Во-вторых, очевидно предыдущий пост ты прочитать не можешь (видимо слишком сложно), где я написал какую конкретно структуру "строит" mysql, и почему на самом деле там никаких структур не строится, а входной массив просто сортируется и все. Если при этом удаляются повторяющиеся элементы, то тогда это уже не массив, а сет (т.к. в сете нет повторений по определению).
Dictionary, Hashset и отсортированный массив 3 разные структуры и нигде между ними нельзя поставить === (надеюсь это для тебя понять будет не слишком сложно).

В этой твой англоязычной терминологии индексация - создание ассоциативного массива (как ты сам сказал), но ни 1 база (в т.ч. mysql) для быстрого поиска по данным в IN ассоциативный массив не строит. Нужно объяснять почему ? А стоп, я же уже объяснил в пред. посте, только вот ты просто не прочитал (или намеренно дурачка строишь).

Следственно ты просто сморозил херню.

Сообщение от moka

Твое заключение говорит что ты нихера не читаешь что я пишу. Не будет 10 раз full_scan в хорошем случае. Потому что можно сделать временный индекс по массиву данных переданных в запросе (IN), и один full_scan с проверкой по временному индексу. И я третий раз повторюсь: это при хорошей реализации дб движка.

Когда индекс юзается, то бъет прямо по индексу, когда не юзается, может быть 10 full_scan'ов O(a*b), а может быть один с мелким индексом O(a + b).

Мда...
Прямо в тексте который ты процитировал написано в плохом случае будет 10 фулсканов, а ты дальше пишешь мне что в хорошем случае 10 фулсканов не будет, а где собственно я писал что в хорошем случае будет 10 фулсканов (конкретную цитату приведи)?.

Ты вроде же умного строишь из себя, а bit O notation в первый раз видишь?

Опять же во-первых ты показываешь недюженные скилы в уходе от ответа на вопрос, ведь я лишь спросил имел ли ты под O(a*b) и O(a+b) big o notation, а ты мне на вопрос ответил другим вопросом.

Во-вторых O(a*b) и O(a+b) это не big o notation и абсолютно никакого отношения к нему не имеет.
Далее чтобы наконец убедится в твоем полном непонимании big o notation, ответь на 3 вопроса:

Какова "сложность" алгоритма который пробегает весь объем данных 2 раза (всегда)?
Какова "сложность" алгоритма который пробегает весь объем данных 10 раз (всегда)?
Равны ли "сложности" этих алгоритмов и если нет, то какой "сложнее" ?

[moka]

Слушай h1dd3n, тебе скучно и учить некого? Иди детей своих учить.
Что ты пишешь очевидные вещи, и мне просто в падлу расписывать детали. Это задача каждого разраба самому этим интересоваться.
Дали вопрос, я в общих чертах описал как и что, и описал корректно, т.к. твои все "правки" не противоречат моим убеждениям. Следственно я не понимаю чего ты распинаешься.

Сообщение от h1dd3n

Во-первых, это не я уточнять термин должен, а ты сразу употреблять термин правильно. Это русскоязычный форум и термины ты должен употреблять принятые в русскоязычном сообществе.

Никому и ничего не должен.
И если у тебя с англ. плохо, уж прости, но основной % всей культуры разработчиков - основана на англ. языке, deal with it.

Сообщение от h1dd3n

Во-вторых, очевидно предыдущий пост ты прочитать не можешь (видимо слишком сложно), где я написал какую конкретно структуру "строит" mysql, и почему на самом деле там никаких структур не строится, а входной массив просто сортируется и все. Если при этом удаляются повторяющиеся элементы, то тогда это уже не массив, а сет (т.к. в сете нет повторений по определению).
Dictionary, Hashset и отсортированный массив 3 разные структуры и нигде между ними нельзя поставить === (надеюсь это для тебя понять будет не слишком сложно).

А я и не ставлю ===, где ты видешь подобное?
И сортированный массив ты вообще от куда вытащил?
Dictionary и Hashset и Object (js) объеденяет одно - возможность доступа к элементу по key'ю. И на этой основе я их объеденил, т.к. для решения задачи построения временного индекса - нужно именно это свойство.

Сообщение от h1dd3n

В этой твой англоязычной терминологии индексация - создание ассоциативного массива (как ты сам сказал), но ни 1 база (в т.ч. mysql) для быстрого поиска по данным в IN ассоциативный массив не строит. Нужно объяснять почему ? А стоп, я же уже объяснил в пред. посте, только вот ты просто не прочитал (или намеренно дурачка строишь).

А это тогда что?

Даже ослу понятно что когда анализатор запроса видит in, то он парсит его не в массив, а в hashset, по которому поиск быстрый (ведь данные то отсортированы). Но никакого "индекса" он для этого не делает.

Да и ты тут сморозил тоже: "по которому поиск быстрый (ведь данные то отсортированы)", ну вообще-то hashset это не отсортированные данные, а используется hash репрезентация элемента как key для прямого доступа к элементу. Читай тут: http://stackoverflow.com/questions/4...t-is-a-hashset

Бля чувак, мне впадлу с тобой спорить.
Тратишь свое и мое время.

Обзывания в мой адрес - ок. Че ты доказываешь? Если хочешь поделиться инфой, кинь мне ссылочки на доки по теме, я почитаю.
В реальности, я пахаю и у меня много опыта, работая с кучей разных разрабов, и куча разного опыта. Никто так не залупился как ты, и со всеми нахожу общий метод общения, важно не придираться к словам, а доносить идею, и если что-то не ясно, то способствуешь друг-другу в уточнении данных.

Это называется общение, и обмен информацией. Если тебе хочется с кем-то спорить и чето там доказывать, иди к кому-то другому.
Ты давно показал степень невежества по разным темам на булке, я к тебе интереса не испытываю, и думаю тебе стоит "охладеть" ко мне тоже.

[h1dd3n]

Сообщение от moka

А я и не ставлю ===, где ты видешь подобное?
И сортированный массив ты вообще от куда вытащил?
Dictionary и Hashset и Object (js) объеденяет одно - возможность доступа к элементу по key'ю. И на этой основе я их объеденил, т.к. для решения задачи построения временного индекса - нужно именно это свойство.

Вот ты написал с ===:

Временный индекс === hashset === dict...

У hashseta (который в C#, ведь ссылка на so ты дал именно на вопрос про C#) нет доступа по ключу (key), ты пробалаболился в очередной раз.
Hashset в C# не хранит данные как ассоциативный массив.
Для решения задачи быстрого поиска по данным в IN не нужен ассоциативный массив, не нужен там доступ по ключу (выделю шрифтом побольше чтобы ты заметил)

Повторю еще раз - массив просто сортируется, и все.
Это не hashset.
Это не dictionary.
Это не object из js.
Это просто отсортированный массив.

Разница при этом большая - ведь объем памяти остается точно такой же как если бы массив и не сортировался бы (то есть разницы в объеме памяти между вариантом с "временным индексом (c) moka" и без него нету никакой).

В то время как ты сказал что "индексы обычно легковесные" (несколько постов назад). Тем самым ты дезинформировал всех кто прочитал твой пост, ведь объем памяти данных которые были в IN при так называемой "индексации (с) moka" не изменится (а возможно даже станет меньше, если есть повторения), что прямо противоречит тому что ты сказал про легковесные индексы.

Да и ты тут сморозил тоже: "по которому поиск быстрый (ведь данные то отсортированы)", ну вообще-то hashset это не отсортированные данные, а используется hash репрезентация элемента как key для прямого доступа к элементу. Читай тут: http://stackoverflow.com/questions/4...t-is-a-hashset

Я выше написал что такое hashset.
Нет никакого "прямого доступа".
Hashset просто хранит вместо отсортированных данных, отсортированные хэши этих данных
То есть не SORT (["apple", "google", "banana"]), а SORT ([ HASH("apple"), HASH("google"), HASH("banana) ]).
Зачем так ? Да для того чтобы быстрее искать. Если у тебя массив чисел ([1,5,3]) то hashset будет работать также быстро как и если бы ты искал по отсортированному массиву. Но вот если у тебя массив строк, то будет оптимальнее хранить хэши этих строк, ведь:
1. Меньше памяти на хранение
2. Сравнение 2 хэшей скорее всего быстрее, ведь например если хэш это число (int32) то сравнение 2 чисел это 3 процессорных инструкции (то есть быстро), а вот каждый раз строки сравнивать это медленно.

Понятно ? Или еще в каком то моменте подробнее объяснить надо ?

--------

В данной ситуации мы "общаемся" на форуме, и если ты прямо озвучил утверждение которое было ложным/не корректным, то я могу свободно указать тебе на это, приведя аргументы/доводы (что я и сделал).

Ну и наконец ты так и не ответил про Big o notation. Ты же очень умный и опыта у тебя дохера, так ответь же мне ничего не понимающему любящему поспорить человеку на 3 вопроса (для такого гуру как ты это не составит никакого труда):

Какова "сложность" алгоритма который пробегает весь объем данных 2 раза (всегда)?
Какова "сложность" алгоритма который пробегает весь объем данных 10 раз (всегда)?
Равны ли "сложности" этих алгоритмов и если нет, то какой "сложнее" ?