Im_MaxЗдравствуйте. Помогите разобраться по некоторым вопросам.
1) Есть параметр, который может принимать 2 положения. Например ТОП товар. Товар может быть ТОПом или нет. Для этого напрашивается тип данных Bit. Можно также использовать TinyInt. Первое весит 1 бит, второе 1 байт. Над вторым можно совершать арифметические операции, над первым нет. Второе можно расширить, если например введут признак например ПремиуиТОП и нужно будет что бы столбец принимал одно из трех значений. Вопрос: Сильно ли будет заметно различие по скорости работы базы данных использование Bit или TinyInt в таких случаях если в базе таблицы с товарами по 10-30 млн данных?
2) Есть товары. Для ключа использую тип данных Int. Вес ячейки 4 байта. Как повлияет на производительность БД если вместо Int будет использоваться Char, Varchar, Nchar, Nvarchar? 1 символ в Char весит 1 байт. Соответственно если тип данных я укажу Char(4) то каждое значение будет весить по 4 байта? Даже если введу единицу? Если ввести в Varchar(4) единицу, она будет весить 4 байта или 1? Как повлияет на скорость работы БД использование Int или Varchar, если тип данных используется для обозначения шестизначного кода? Получается идет сравнение Int и Varchar(6). Как повлияет на скорость работы БД использование Int или Varchar, если тип данных используется для обозначения трехзначного кода? Получается идет сравнение Int и Varchar(3).
1. Индекс по полю типа бит вещь очень неизбирательная, поэтому при выборке сканировать придется всю таблицу. Возможно, более удачный вариант завести отдельную таблицу что-то вроде Top(GoodsID int PK), в которую складывать идентификаторы топовых товаров, если их не очень много, зависит от нескольких причин. С потолка можно сказать про не более 30%, зависит от количества операций чтения данных.
2. Символьные данные при сравнении в операциях поиска и фильтрации обычно используют правила сортировки, что в целом эти операции замедляет. Кроме того, строки, как правило, разной длины, что тоже сказывается на сравнении из-за способа хранения, так как фиксированое поле и переменное хранятся по-разному, обычно это описывается в документации к серверу. Лучше хранить в фиксированом, но тогда может быть неоптимальный объём хранения таковых данных. Поэтому, если уж решили использовать, то при многих оперциях полезно указывать опцией, что при сравнение использовать бинарную сортировку. А вообще правильно сказали выше, тип поля должен зависеть не от того, что меньше, а от того, каким он должен быть. Если в качестве кода использутся только цифры, то разумно использовать целочисленный тип, если же могут быть любые другие символы, то символьный, а если ещё и диапазон символов превышает ASCII, то от Unicode никуда не денешься. В общем, нюансов много. В любом случае, типы должны совпадать, чтобы серверу не приходилось "на лету" выполнять конвертацию данных, это, как правило, катастрофически сказывается на производительности.
Есть очень
неплохая книга для практиков, рекомендуется к прочтению. Авторы сделали много разных интересных экспериментов на ряде самых известных RDBMS.
