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

Откуда: СПб
Сообщений: 382
С детства знаю, что писать select * плохо, но обосновать своему коллеге почему - не могу. Кто может дать пруфов или рассказать почему все же плохо или без разницы...
21 сен 12, 10:51    [13200354]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
зомби зомби зомби
Member

Откуда: из Жужеля!
Сообщений: 7437
нафига лишние поля тянуть на клиент?
21 сен 12, 10:56    [13200407]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31994
Shultze
С детства знаю, что писать select * плохо, но обосновать своему коллеге почему - не могу. Кто может дать пруфов или рассказать почему все же плохо или без разницы...
Потому что список полей и порядок их вывода будут неконтролируемы.

Соответственно, выбираем select * или select список_полей в зависимости от того, хорошро это или плохо.

Как правило неконтролируемость это плохо.
21 сен 12, 10:56    [13200408]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Shultze
Member

Откуда: СПб
Сообщений: 382
alexeyvg
Shultze
С детства знаю, что писать select * плохо, но обосновать своему коллеге почему - не могу. Кто может дать пруфов или рассказать почему все же плохо или без разницы...
Потому что список полей и порядок их вывода будут неконтролируемы.

Соответственно, выбираем select * или select список_полей в зависимости от того, хорошро это или плохо.

Как правило неконтролируемость это плохо.


Да ладно, MS SQL выведет поля в том порядке, как они определены в таблице. не будет никакой неопределенности
21 сен 12, 11:05    [13200452]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
ROLpogo
Member

Откуда: Реутов
Сообщений: 219
Если есть покрывающий индекс на заданные в запросе поля, то такой запрос будет работать быстрее, чем выбор всех полей по звездочке.
21 сен 12, 11:10    [13200484]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
petsa
Member

Откуда:
Сообщений: 1708
Ну вот где-то есть код
INSERT INTO Table1 (C1, C2, C3 и.т.д) SELECT * FROM Table2
.
А в процессе эксплуатации в Table2 поле удалили или добавили наоборот. Во время исполнения возникнет ошибка, которая никогда-бы не возникла при явном сопоставлении полей (ну если,конечно, перечисленное не удалили)
21 сен 12, 11:13    [13200504]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Shultze
Да ладно, MS SQL выведет поля в том порядке, как они определены в таблице. не будет никакой неопределенности

Ага, а завтра сервис пак выйдет и выведет в другом. Зачем полагаться на эти вещи, когда можно явно перечислить список полей?
Кроме того, если вы со временем переопределите таблицу (допустим, добавите какое-нибудь служебное поле), где гарантия, что все пользователи запроса учитывают это добавление?
21 сен 12, 11:14    [13200505]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
смотрю_тут
Member

Откуда:
Сообщений: 1368
+
неправильное использование индексов
для разработки проблема и привязка
21 сен 12, 12:28    [13201159]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Однако в EXISTS(SELECT * FROM ...) очень даже неплохо!
Даже очень хорошо!
21 сен 12, 12:40    [13201270]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Читатель мимопроходящий
Guest
SomewhereSomehow
Ага, а завтра сервис пак выйдет и выведет в другом. Зачем полагаться на эти вещи, когда можно явно перечислить список полей?
а вероятность этого точно есть??
К примеру кучу кода етсь, когда создается временная таблица - два три поля и * обычно для вставки в другую используется... да мало ли где ещё
21 сен 12, 12:54    [13201388]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Shultze
Да ладно, MS SQL выведет поля в том порядке, как они определены в таблице. не будет никакой неопределенности
Вот пишешь код, многа кода, тоннами. Везде родная (*) звязда.
А тут бац, нужно добавить одно поле в таблицу, или поменять что-то. Или кому-то придёт идиотская мысля поменять порядок.
И А-а-а-а-а-а, переписывать это всё.

Код должен быть максимально независим - модульность, порядок и набор полей в одном месте кода не должен зависеть от порядка и набора в другом.

Иногда это можно и полезно, если специфика кода - прозрачно передать всё как есть. Но этого почти нет и оно в скуле не работает - не сделали и делать не собираются. Т.к. после выставления представлений колонки замораживаются, и нужно снова делать Re-Alter.
CREATE VIEW <ObjectValid> AS
SELECT	*
FROM	<Object>
WHERE	Valid = 1
GO
Вот если бы скуль обновлял зависимые, где стоит чисто звязда(*).
Но на самом деле это не проблема, можно и самому обновить (изменить набор колонок).
21 сен 12, 13:02    [13201467]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
daw
Member

Откуда: Муром -> Москва
Сообщений: 7381

> а вероятность этого точно есть??

ну, про сервис-пак - это перебор, пожалуй.
в документации про порядок совершенно определенно сказано:
*

Specifies that all columns from all tables and views in the FROM clause should be returned. The columns are returned by
table or view, as specified in the FROM clause, and in the order in which they exist in the table or view.


да и в стандарте порядку вывода столбцов при использовании * место уделяется (толком не вчитывался, правда, признаюсь).

Posted via ActualForum NNTP Server 1.5

21 сен 12, 13:07    [13201531]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Mnior
Shultze
Да ладно, MS SQL выведет поля в том порядке, как они определены в таблице. не будет никакой неопределенности
Вот пишешь код, многа кода, тоннами. Везде родная (*) звязда.
А тут бац, нужно добавить одно поле в таблицу, или поменять что-то. Или кому-то придёт идиотская мысля поменять порядок.
И А-а-а-а-а-а, переписывать это всё.

Код должен быть максимально независим - модульность, порядок и набор полей в одном месте кода не должен зависеть от порядка и набора в другом.

Иногда это можно и полезно, если специфика кода - прозрачно передать всё как есть. Но этого почти нет и оно в скуле не работает - не сделали и делать не собираются. Т.к. после выставления представлений колонки замораживаются, и нужно снова делать Re-Alter.
CREATE VIEW <ObjectValid> AS
SELECT	*
FROM	<Object>
WHERE	Valid = 1
GO
Вот если бы скуль обновлял зависимые, где стоит чисто звязда(*).
Но на самом деле это не проблема, можно и самому обновить (изменить набор колонок).
Как бы на этот случай есть
sp_recompile
sp_refreshview
?
21 сен 12, 13:12    [13201606]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Shultze
Member

Откуда: СПб
Сообщений: 382
iap,

Суть не в этом, чем же все таки плоха *. Может выборка не оптимально идет или индексы не задействуются правильно или блокировки какие то не те накладываются?
21 сен 12, 13:28    [13201877]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Glory
Member

Откуда:
Сообщений: 104751
Shultze
Суть не в этом, чем же все таки плоха *. Может выборка не оптимально идет или индексы не задействуются правильно или блокировки какие то не те накладываются?

Конечно, при выборе всех полей и только нужных сервер может выбрать разные планы выполнения
Например, вместо сканирования таблицы - выборку из покрывающего индекса
21 сен 12, 13:31    [13201918]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Читатель мимопроходящий
SomewhereSomehow
Ага, а завтра сервис пак выйдет и выведет в другом. Зачем полагаться на эти вещи, когда можно явно перечислить список полей?
а вероятность этого точно есть??
К примеру кучу кода етсь, когда создается временная таблица - два три поля и * обычно для вставки в другую используется... да мало ли где ещё

Вот что гласит документация:
автор
*

Specifies that all columns from all tables and views in the FROM clause should be returned. The columns are returned by table or view, as specified in the FROM clause, and in the order in which they exist in the table or view.

Что такое в порядке в котором они существуют не сказано. Можно домыслить что в том, в котором создавались. Не думаю, что есть какой-то резон что-то в этом менять, но все же. Кроме того, есть и другие причины не использовать *.
Я лично использую * в exists, иногда во внутреннем запросе с cte, или иногда чтобы быстро что-то посмотреть. Равно как и стараюсь указывать поля в insert, даже если это временная таблица или табличная переменная.
21 сен 12, 13:31    [13201928]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
зомби зомби зомби
Member

Откуда: из Жужеля!
Сообщений: 7437
iap
Однако в EXISTS(SELECT * FROM ...) очень даже неплохо!
Даже очень хорошо!
какая разница что выбирать в exists??? Можно хоть единичку поставить
21 сен 12, 13:59    [13202221]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
зомби зомби зомби
iap
Однако в EXISTS(SELECT * FROM ...) очень даже неплохо!
Даже очень хорошо!
какая разница что выбирать в exists??? Можно хоть единичку поставить
* общепринята на всех SQL серверах. Ну, это как мода :))
21 сен 12, 14:05    [13202277]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31994
Shultze
alexeyvg
пропущено...
Потому что список полей и порядок их вывода будут неконтролируемы.

Соответственно, выбираем select * или select список_полей в зависимости от того, хорошро это или плохо.

Как правило неконтролируемость это плохо.


Да ладно, MS SQL выведет поля в том порядке, как они определены в таблице. не будет никакой неопределенности
Я о том, что порядок полей может быть важен где то снаружи запроса. А хоть в выводе полей и нету неопределённости, но этот порядок может меняться от действий людей, и в этом случае меняющий должен контролировать/менять все остальные компоненты стстемы.
Тогда мелкое изменение превратится в головную боль.
21 сен 12, 14:27    [13202524]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31994
iap
Однако в EXISTS(SELECT * FROM ...) очень даже неплохо!
Даже очень хорошо!
Да? Так для * нужно иметь права на все поля!

Учитывая, что SELECT 1 пишется с такими же трудозатратами, что и SELECT *, не вижу смысла вообще задумываться, прежде чем написать SELECT 1
21 сен 12, 14:30    [13202562]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Диклевич Александр
Member

Откуда:
Сообщений: 612
А есть разница между
EXISTS(SELECT * FROM Table)

и
EXISTS(SELECT t.* FROM Table t)
?
21 сен 12, 15:40    [13203186]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
alexeyvg
iap
Однако в EXISTS(SELECT * FROM ...) очень даже неплохо!
Даже очень хорошо!
Да? Так для * нужно иметь права на все поля!

Учитывая, что SELECT 1 пишется с такими же трудозатратами, что и SELECT *, не вижу смысла вообще задумываться, прежде чем написать SELECT 1
Да не нужно иметь права на все поля.
21 сен 12, 16:05    [13203432]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
iap
Да не нужно иметь права на все поля.
use tempdb;
go

create user TestUser without login;
go

create table dbo.TestTable (i int, v int);
go

grant select on object::dbo.TestTable to TestUser;
deny select on object::dbo.TestTable(v) to TestUser;
go

execute as user = 'TestUser';
go

select 1 where exists(select * from dbo.TestTable);

revert;
go

drop table dbo.TestTable;
drop user TestUser;
go
21 сен 12, 16:09    [13203458]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
invm
Member

Откуда: Москва
Сообщений: 9845
Ну и exists(select 1 from ...) тоже обломается, если нет прав на какой-либо столбец.
21 сен 12, 16:13    [13203512]     Ответить | Цитировать Сообщить модератору
 Re: чем плоха Select *  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
invm
Ну и exists(select 1 from ...) тоже обломается, если нет прав на какой-либо столбец.

Зато (select i from ...) не обломается.
21 сен 12, 16:16    [13203541]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить