Выберите * из таблицы ИЛИ выберите id, field1, field2, field3 из таблицы - наилучшая практика?

Может ли кто-нибудь услышать, что лучше? для выбранных запросов следует вернуть все или требуемые идентификаторы, которые мне нужны?

Эффективность? Масштабируемость? и др.

спасибо

Env: SQL Server 2008, VS2008 (VB)

Ответ 2

Всегда явно перечислять столбцы. Никогда не выполняйте select * в любом производственном коде.

Даже ситуации, когда это может показаться разумным, могут иметь непреднамеренные последствия. Например, вы можете подумать сделать select *, когда у вас есть представление, которое должно отражать макет таблицы, но могут произойти странные вещи, если вы измените базовую таблицу без восстановления представления.

Держитесь подальше от select *, если вы не вводите запрос и не выполняете его тогда и там.

Ответ 3

Может ли кто-нибудь услышать, что лучше? для выбранных запросов следует вернуть все или требуемые идентификаторы, которые мне нужны?

Назовите свои столбцы.

Это не только лучшая практика, но и более высокая производительность.

Представьте себе два запроса:

SELECT  *
FROM    mytable
WHERE   column1 = @somevalue

и

SELECT  id, column1
FROM    mytable
WHERE   column1 = @somevalue

id является кластеризованным первичным ключом, и на column1 есть индекс.

Я предполагаю, что ваш код клиента обрабатывает переменное число столбцов правильно, т.е. е. изменение макета таблицы не нарушает код. Это очень сильное предположение, но пусть это сделает.

Теперь, если mytable состоит только из id и column1, запросы одинаковы.

Что произойдет, если вы добавите column2 в mytable?

Второй запрос (с именованными столбцами) по-прежнему использует индекс (поскольку в нем содержится все, что требуется запросу), но сначала нужно также выбрать column2 (SQL Server не знает, что вы его проигнорируете).

Это добавит Clustered Table Seek в план, а производительность вашего запроса ухудшится.

Ответ 4

Никогда не слушайте, чтобы кто-нибудь говорил вам всегда что-то делать в SQL - альтернативно, всегда будьте осторожны с тем, кто говорит вам никогда ничего не делать в SQL:)

В следующих примерах SELECT * не может нанести вреда и, возможно, имеет преимущество в отношении читаемости и обслуживания кода (DRY и все такое)


Пример 1

Когда атрибут commalist уже указан во внутренней области:

SELECT * 
  FROM (
        SELECT col1, col2, col3, col4, col5
          FROM T1 
       ) AS DT1;

Пример 2

При использовании конструктора значений таблиц в CTE, и один вынужден (например, в SQL Server!) обернуть предложение VALUES в табличное выражение (SELECT..FROM), например.

WITH T1
     AS
     (
      SELECT * 
        FROM (
              VALUES (1, 1, 1, 2, 1), 
                     (1, 1, 2, 1, 1), 
                     (1, 2, 1, 1, 1)
             ) AS T (col1, col2, col3, col4, col5)
     )
SELECT ...

ОК, так что этот последний немного соломен, но считайте, что использование коммивояров при каждой возможности вызвало ошибку и затрудняет отладку:

WITH T2 (author_name, book_title, ISBN) 
     AS
     (
      SELECT book_title, ISBN, author_name
        FROM (
              VALUES ('9780321189561', 'C. J. Date', 'An Introduction to Database Systems')
             ) AS T (ISBN, author_name, book_title)
     )
SELECT *
  FROM T2;

Ответ 6

Вы должны указывать столбцы в большинстве случаев, это лучше всего подходит для будущих изменений и обслуживания. Он также уменьшает количество данных, повышая производительность.

Ответ 7

Причины, по которым нужно явно указывать столбцы над SELECT * FROM our_table, это

  • Явное обозначение столбцов в проект выражает наше намерение больше ясно и так самодокументирующий код.
  • В будущем кто-то добавит или больше столбцов к таблице. Если мы используйте SELECT * эти столбцы будут автоматически перетаскивается, что может нарушить наш код или вызвать его выполняются плохо (особенно если LOB ).

Ответ 8

Если вы не ссылаетесь ни на одно из имен столбцов в клиентском коде, вы должны использовать именованные столбцы.

Ответ 9

Я не буду говорить вам " никогда никогда" или " всегда" использовать тот или иной. Советы, которые начинаются с этого, не должны восприниматься буквально.

Если вы работаете с небольшими наборами данных, не настаивайте на использовании глупых "оптимизаций", таких как замена * на список полей, особенно если вы укажете все полей.

Имея читаемый и простой в обслуживании SQL-код, часто стоит больше, чем несколько сохраненных циклов процессора или на несколько килобайт меньше использования памяти или сетевого трафика.