= Сообщение: 5254 из 8303 ========================================= RU.LINUX =
От : Andrew Kant 2:469/83.1 17 Oct 18 11:06:57
Кому : Vladislav Vetrov 17 Oct 18 11:06:57
Тема : Чем чревато хранить цифры в char-полях mysql?
FGHI : area://RU.LINUX?msgid=2:469/83.1+5bc70ea4
На : area://RU.LINUX?msgid=2:5020/2140.152@Fidonet.org+5bc6dd67
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hello Vladislav!
Wednesday October 17 2018 09:47, Vladislav Vetrov wrote to Andrew Kant:
VV>>> В общем - сабж. Какие аргументы? Почему цифры лучше хранить, как
VV>>> цифры, а не как текст? Hевозможно провести индексацию?
VV>>> Потеря производительности на преобразование типов? Что ещё?
AK>>
AK>> Основная проблема - корректность сравнения, и, как следствие,
AK>> порядок сортировки. Сравнение идёт символьное, а не цифровое.
AK>> Опять-же, неоднозначность представления. '5' как соотносится с '5 '
AK>> и с ' 5' ? Как ты думаешь, будут ли равны эти значения?
AK>>
AK>> Hу и по мелочи - обычно цифровой формат компактнее, то есть
AK>> занимает меньше места при прочих равных, так как на одну десятичную
AK>> цифру нужно не один байт, а примерно 4 бита.
VV> Благодарю за ответ. Сортировку цифр, записанных текстом, оказывается
VV> можно решить следующим хаком: к тексту добавляем любую цифру, например
VV> 0.0, затем сортируем.
VV> Пример:
VV> Пробуем сортировать по последнему столбцу salary:
mysql>> SELECT name, salary FROM worker ORDER BY salary;
VV> Пробуем сортировать, добавив к текстовому столбцу 0.0:
mysql>> SELECT name, salary FROM worker ORDER BY salary+0.0;
В первом случае ты используешь лексикографическую сортировку (символьный тип), во втором у тебя итоговое выражение цифрового типа (неявное преобразование в намерик). Hо зачем делать неявное преобразование, причем по каждой строке (а может и не раз), когда можно изначально сохранить в таблице значение цифрового типа?
VV> Hо индексы в таком столбце (salary) работать не будут, т.к. индекс - это
VV> сортировка, плюс механизм быстрого доступа (поиска) нужного значения. В
VV> столбце salary сортировка будет в алфавитном порядке и хак с добавлением
VV> 0.0 уже не прокатит.
Hе помню, есть-ли в mysql функциональные индексы, но в других БД точно есть. И там можно делать индекс не по столбцу (salary), а по выражению (salary+0.0). Если в клаузе WHERE используется такое выражение, то возможно использовать соответствующий индекс. Hо, опять-же, зачем? Очень много зависит от правильного проектирования структуры данных, и разные типы придуманы как раз для того, чтоб выбрать именно тот, который лучше подходит в каждом конкретном случае. Hо можно все делать и через ж, и при этом даже оно может быть будет хорошо работать на начальном этапе (как обычно говорят разработчики - а у меня все работает, на 5 записях :)
VV> В связи с чем вопрос - на сколько нужны индексы в БД? Слышал, что если
VV> идёт выборка в MySQL через условие больше или меньше, то дальше индексы
VV> уже не работают. Вот этот момент мне не очень понятен. Почему
VV> индексы дальше уже не работают после первой операции сравнения?
Вопрос почему используется или не используется тот или иной индекс, причем в каждой конкретной версии каждой конкретной БД - это тот самый misterious magic, и разбираться в нём - искусство :) Поэтому, используй KISS-прицнип, чем проще - тем лучше и объяснимее.
VV> Также интересно, на сколько отказ от индексов замедлит работу БД?
Всё зависит от конкретного набора данных и от самого приложения, их использующего.
Опять-же, надо помнить, что индексы _могут_ ускорить только выборку - если ты знаешь теорию, то должен знать, что полный перебор имеет сложность порядка N [где N-число записей в таблице], а поиск по индексу - сложность порядка log(N), при малых значениях N полный перебор может быть быстрее поиска по индексу, но при увеличении всегда найдётся такое конечное значение N, после которого индексный поиск будет эффективнее, и эта эффективность будет увеличиваться с возрастанием N; при выборке из двух таблиц всё ещё сложнее, в зависимости от типа связки, при полном переборе по двум таблицам сложность соизмерима с N*M, что обычно существенно хуже, чем N*log(M) при использовании индекса. А вот что лучше, N*log(M) или log(N)*M (то есть по какой таблице перебераем, а в какой ищем по индексу) - зависит от конкретных данных. Hо есть ещё и разные merge и hashjoin, которые могут ускорять процесс, а могут и тормозить :) Так что всё сложно.
Hо при этом индексы _всегда_ тормозят любые обновления данных, от которых зависят (так как требуется поддержка индексов в актуальном состоянии).
Так что "думайте сами, решайте сами..."
Good bye!
Andrew
--- GoldED+/W32 1.1.4.7
* Origin: * KAA * (2:469/83.1)
|
