Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Какой Select будет быстрее?  [new]
iseekyouu
Member

Откуда:
Сообщений: 27
База данных msssql. Есть таблица, справочник типов, хочу добавить в нее уникально поле для связки. Не могу определиться какого типа, строчного или целочисленного?
какой select будет работать быстрее:
select * from test_table where Code = 1
или
select * from test_table where Code = 'one' ?
На сколько существенна будет разница на больших объемах ?
1 фев 17, 10:07    [20168569]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iseekyouu,

прям радостно утром... уточню, а во втором варианте будет текест "seventy-five million eight hundred and fifty-six thousand three hundred and forty-five" ?
1 фев 17, 10:10    [20168580]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iseekyouu
Member

Откуда:
Сообщений: 27
TaPaK,

нет, одно слово
1 фев 17, 10:11    [20168585]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iseekyouu
TaPaK,

нет, одно слово
а как будет одно слово для 75856345
1 фев 17, 10:12    [20168589]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iseekyouu
Member

Откуда:
Сообщений: 27
TaPaK,

например 'two', слово не связано с числами никак, вопрос в другом.
1 фев 17, 10:15    [20168597]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iseekyouu
TaPaK,

например 'two', слово не связано с числами никак, вопрос в другом.

если вы добавляете суррогатный ключ для FC то обычная практика это int,bigint, ну или uniqueidentifier. Скорость определяет индекс/статистика разница
1 фев 17, 10:20    [20168614]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iseekyouu
Member

Откуда:
Сообщений: 27
TaPaK,
А хотя давайте предположим, что во втором варианте будет текст типа "seventy-five million eight hundred and fifty-six thousand three hundred and forty-five", что тогда ?)
1 фев 17, 10:20    [20168615]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iseekyouu
TaPaK,
А хотя давайте предположим, что во втором варианте будет текст типа "seventy-five million eight hundred and fifty-six thousand three hundred and forty-five", что тогда ?)

тогда вас перестанут считать здоровым
1 фев 17, 10:20    [20168617]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iseekyouu
Member

Откуда:
Сообщений: 27
TaPaK
iseekyouu
TaPaK,

например 'two', слово не связано с числами никак, вопрос в другом.

если вы добавляете суррогатный ключ для FC то обычная практика это int,bigint, ну или uniqueidentifier. Скорость определяет индекс/статистика разница


Для чтения SQl инструкции было бы удобнее символьный код например :
select * from test_table where Code = 'MyFavourite', нежели чем select * from test_table where Code = '12832762362'

Правильно понимаю, что особой разницы нет ?
1 фев 17, 10:24    [20168626]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iseekyouu
TaPaK
пропущено...

если вы добавляете суррогатный ключ для FC то обычная практика это int,bigint, ну или uniqueidentifier. Скорость определяет индекс/статистика разница


Для чтения SQl инструкции было бы удобнее символьный код например :
select * from test_table where Code = 'MyFavourite', нежели чем select * from test_table where Code = '12832762362'

Правильно понимаю, что особой разницы нет ?

между двумя текстовыми полями? нет, кроме COLLATION
автор
Для чтения SQl инструкции
вы их в слух друг другу читаете или детям ?
1 фев 17, 10:28    [20168634]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iseekyouu
Member

Откуда:
Сообщений: 27
[quot TaPaK]
iseekyouu
пропущено...
между двумя текстовыми полями?

между строковым и int, кавычки во втором варианте: where Code = '12832762362' лишние
1 фев 17, 10:30    [20168644]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
[quot iseekyouu]
TaPaK
пропущено...

между строковым и int, кавычки во втором варианте: where Code = '12832762362' лишние

если вам нужен интуитивно понятный код - пишите его. Если как вы же и пишете вам нужно "добавить в нее уникально поле для связки" то суррогатный ключ более удобен, чем тащить во всех связанных таблицах ваше 'MyFavourite'
1 фев 17, 10:37    [20168676]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
buven
Member

Откуда:
Сообщений: 792
iseekyouu,

Дайте уже TaPaK ddl таблицы, на которой вы хотите потренироваться:)
Он вам расскажет что конкретно в вашем случае будет быстрее.
А иначе это обсуждение сферического коня в вакууме.
Надеюсь вы понимаете, что поиск по индексу быстрее? А что индекс по строковому полю и integer имеют разную "эргономику"? А что объемы могут быть большими как в ширь так в рост?
1 фев 17, 10:40    [20168687]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
buven
что индекс по строковому полю и integer имеют разную "эргономику"

эргономика индекса... век живи век учись. разницы не будет в seek на текстовое или int поле. Разница в размере индекса может быть, и то не всегда, вопрос что же будет в тексте.

автор
А что объемы могут быть большими как в ширь так в рост?
1 фев 17, 10:45    [20168709]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
автор
А что объемы могут быть большими как в ширь так в рост?

а крокодил больше зелёный или длинный? это вообще о чём?
1 фев 17, 10:46    [20168720]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
[quot iseekyouu]
TaPaK
пропущено...

между строковым и int, кавычки во втором варианте: where Code = '12832762362' лишние

у меня нет чистого примера для такого вопроса, а генерировать лень :)
но при общей ситуации уникальный код carchar(30) и суррогатный кластерный int на 1кк записей даёт

+
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

(1 row(s) affected)
Table 'a'. Scan count 1, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

(1 row(s) affected)
Table 'a'. Scan count 0, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

Scan count 1 там из за того что индекс шире чем просто код...
1 фев 17, 11:02    [20168780]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
Шыфл
Member

Откуда: Прага
Сообщений: 776
iseekyouu
База данных msssql. Есть таблица, справочник типов, хочу добавить в нее уникально поле для связки. Не могу определиться какого типа, строчного или целочисленного?
какой select будет работать быстрее:
select * from test_table where Code = 1
или
select * from test_table where Code = 'one' ?
На сколько существенна будет разница на больших объемах ?


По-моему для этого существует понятие нормализации.
Когда у вас для test_table существует справочник Code
CREATE TABLE Code(
	Code_ID int NOT NULL,
	Code_Name [nvarchar](500) NOT NULL,
 CONSTRAINT [PK_code] PRIMARY KEY CLUSTERED 
(
	Code_ID ASC
)) ON [PRIMARY]


В ID у вас 1, в Name соответственно 'One', а в таблице test_table - то, что в ID.

Потому как 1 занимает банально меньше места, чем 'One', прекрасно join'ится и индексируется, что не совсем так для текстового поля.
1 фев 17, 11:31    [20168871]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Шыфл,
лжец

автор
SELECT DATALENGTH('One'),DATALENGTH(1)


автор
прекрасно join'ится и индексируется, что не совсем так для текстового поля.

это ваши личные фантазии? "прекрасно join'ится " ))))
1 фев 17, 11:36    [20168890]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
Шыфл
Member

Откуда: Прага
Сообщений: 776
TaPaK, популист! :Ъ


SELECT DATALENGTH('One'),DATALENGTH(1)

А если
SELECT DATALENGTH(N'One'),DATALENGTH(1)

или даже
SELECT DATALENGTH('seventy-five million eight hundred and fifty-six thousand three hundred and forty-five'), DATALENGTH(75856345)


В ваших базах нет справочников? У строк есть прекрасные свойства, например скрытые непечатные символы аля табулятор или перевод каретки, разное колличество пробелов в начале/конце/середине, строчные-прописные символы, пустая строка в конце концов. Это всё, конечно, вносит разнообразие в трудовую деятельность, но не уверен что автор к этому стремится
1 фев 17, 11:55    [20168967]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Шыфл
TaPaK, популист! :Ъ


SELECT DATALENGTH('One'),DATALENGTH(1)

А если
SELECT DATALENGTH(N'One'),DATALENGTH(1)

или даже
SELECT DATALENGTH('seventy-five million eight hundred and fifty-six thousand three hundred and forty-five'), DATALENGTH(75856345)


В ваших базах нет справочников? У строк есть прекрасные свойства, например скрытые непечатные символы аля табулятор или перевод каретки, разное колличество пробелов в начале/конце/середине, строчные-прописные символы, пустая строка в конце концов. Это всё, конечно, вносит разнообразие в трудовую деятельность, но не уверен что автор к этому стремится

1. уникально поле для связки.
2. Размер поля влияет только на размер индекса, а не на скорость выборки в уникальном индексе, если мы конечно не берём запредельные варианты с MAX
3. Потому как 1 занимает банально меньше места, чем 'One' => SELECT DATALENGTH('One'),DATALENGTH(1) => лжец, без если
1 фев 17, 12:00    [20168988]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Шыфл,

хотя складывается впечатление, что для вас индекс это дерево символов... o->on->one
1 фев 17, 12:02    [20168997]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iljy
Member

Откуда:
Сообщений: 8711
TaPaK
3. Потому как 1 занимает банально меньше места, чем 'One' => SELECT DATALENGTH('One'),DATALENGTH(1) => лжец, без если


DATALENGTH - это всего лишь длина строки или бинарного поля, а не занимаемое место. Учитывая, что у нас varchar, при хранении как минимум нужно место под длину.
1 фев 17, 12:12    [20169024]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
iljy,

автор
varchar, при хранении как минимум нужно место под длину

фактически да :) +1 байт если не ошибаюсь
1 фев 17, 12:15    [20169033]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
iljy
Member

Откуда:
Сообщений: 8711
TaPaK
iljy,

автор
varchar, при хранении как минимум нужно место под длину

фактически да :) +1 байт если не ошибаюсь


На самом деле минимум 2. Если такое поле единственное - то плюс еще 2. Ну и связанные с этим всем накладные расходы тоже никуда не деваются (помимо собственно накладных расходов по работе с полем переменной длины, еще и накладные расходы по сравнению символьных полей в соответствии с COLATION).
1 фев 17, 13:06    [20169304]     Ответить | Цитировать Сообщить модератору
 Re: Какой Select будет быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8828
iseekyouu,

если память не изменяет, сравнение целых чисел производится за дин такт современных процессоров. Строка требует значительно больше накладных расходов. После замены символьных ключей на целочисленные производительность заметно выросла. Кроме того, длина ключа также имеет значение.
1 фев 17, 14:13    [20169657]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить