2010-04-15 5 views
1

У меня есть база данных, которая использует коды. Каждый код может быть от двух символов до десяти символов.SQL Лучшая производительность: char (10) и trim или varchar (10)

В MS SQL Server лучше использовать для использования char(10) для этих кодов и RTRIM им по мере их поступления, или я должен использовать varchar(10) и не беспокоиться об обрезке лишних пробелов? Мне нужно избавиться от пробелов, потому что тогда коды будут использоваться в логике приложений для сравнения, а что нет.

Что касается средней длины кода, трудно точно сказать. Предположим, что все коды имеют случайную длину от одного до десяти. Редактировать: Грубая оценка составляет около 4.7 символов для средней длины кода.

+1

Попробуйте запустить: 'SELECT AVG (LEN (CODE) * 1.0) FROM YourTable' –

+0

Хорошая идея. Коды распространяются во многих таблицах кодов, но результат из самой популярной таблицы кодов равен 4.74 – macca1

ответ

6

Я бы проголосовал за варчар.

Я говорю varchar, чтобы избежать TRIM, который приведет к недействительности использования индекса (если вы не используете вычисленный столбец и т. Д., Который побеждает цель, нет?).

В противном случае при длине 10, было бы 50/50, но TRIM склоняет баланс в сторону VARCHAR и побеждает в пользу фиксированной длины

+0

, почему нужно использовать TRIM? –

+1

Потому что парень говорит об использовании char вместо varchar. –

+0

@KM: сравнение столбца char с литералом varchar преобразует столбец в varchar (приоритет типа данных). Тогда вам понадобится TRIM. Или CAST буквальный символ. Как бы то ни было, проще просто использовать varchar для упрощения кода – gbn

0

В одной старой книге я прочитал, что в общем гольца является лучшим выбором, когда для в большинстве записей реальная длина строки составляет не менее 60% от максимальной; в вашем примере - если более половины всех записей имеют длину 6 или больше. В противном случае используйте varchar.

+0

Я бы предположил, что подобные заявления просто потому, что они делают предположения о платформе. этот материал можно было бы оптимизировать или измениться в результате незначительных изменений. Например, в Oracle раньше было делать COUNT (1), чем COUNT ([star]). Сколько времени потребуется Oracle, чтобы сделать COUNT ([star]) так же быстро, как COUNT (1)? Две строки кода? Так что подобные вещи должны быть подозрительными в долгосрочной перспективе. –

+0

Извините, в комментарии выше Я не знаю, как избежать символа звездочки –

1

Ваши требования - это определение учебника для кого-то, кто должен использовать varchar.

Если вы хотите беспокоиться о производительности, подумайте о дизайне БД и написании хорошего SQL. Char vs VarChar внутренне хорошо оптимизированы поставщиками БД.

2

Я уверен, что вы не сможете определить разницу в скорости между двумя.

+0

О да, вы будете. 10 байт против 6.7 avg length (4.7 + lenght) над 1M строками дает 3.3 Мб меньше потребляемой памяти, 3,3 Мб меньше данных для чтения и записи, меньше 3,3 Мб для записи, резервное копирование меньше с 3,3 МБ и т. Д. –

+0

Я предпочитаю формальный (TimeToComparePerformanceCosts * HourlyRateOfPerson)> = (PerformanceSavings% * HourlyRateOfHardwareCosts) – Nat

3

Как правило, всегда предпочитайте меньшую память за дополнительный процессор. Поскольку движущим фактором производительности базы данных всегда является IO, а более мелкие записи данных - больше записей на странице, а это, в свою очередь, означает меньшее количество запросов ввода-вывода. Дополнительный процессор, занимающийся обработкой переменной длины, не будет фактором. Исторически, в темные века 80-х и даже в 90-е годы, возможно, это был измеримый фактор, но сегодня это всего лишь шум. Поскольку процессор и доступ к памяти значительно увеличились, но скорость ввода-вывода оставалась практически постоянной. Вот почему совет «старых книг» сегодня не применяется. Если у вас нет постоянного поля типа char (2) или подобного, просто используйте varchar.