it-swarm-ru.tech

Что быстрее / лучше? SELECT * или SELECT column1, colum2, column3 и т. Д.

Я слышал, что SELECT *, как правило, является плохой практикой при написании команд SQL, поскольку он более эффективен для столбцов SELECT, которые вам особенно нужны.

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

SELECT * FROM TABLE

или же

SELECT column1, colum2, column3, etc. FROM TABLE

Эффективность действительно имеет значение в этом случае? Я думаю, что SELECT * был бы более оптимальным для внутренних целей, если вам действительно нужны все данные, но я говорю это без реального понимания базы данных.

Мне любопытно узнать, какова лучшая практика в этом случае.

ОБНОВЛЕНИЕ: Я, вероятно, должен указать, что единственная ситуация, когда я действительно хочу сделать SELECT *, это когда я выбираю данные из одной таблицы, где я знаю, что все столбцы всегда нужно будет извлекать, даже когда добавляются новые столбцы.

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

152
Dan Herbert

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

Вот сообщение, которое я написал об этом: Реальная причина, почему запросы на выбор - плохое покрытие индекса

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

156
Jon Galloway

Учитывая вашу спецификацию, что вы являетесь выбираете все столбцы, разница между ними на данный момент. Поймите, однако, что схемы базы данных меняются. Если вы используете SELECT *, вы добавите в таблицу новые столбцы, хотя, по всей вероятности, ваш код не готов использовать или представлять эти новые данные. Это означает, что вы подвергаете свою систему неожиданным изменениям производительности и функциональности.

Возможно, вы захотите отклонить это как незначительные расходы, но поймите, что столбцы, которые вам не нужны, по-прежнему должны быть:

  1. Читать из базы данных
  2. Отправлено через сеть
  3. Маршалл в ваш процесс
  4. (для технологий типа ADO) Сохранено в таблице данных в памяти
  5. Игнорируется и выбрасывается/сборка мусора

Элемент № 1 имеет много скрытых затрат, включая устранение некоторого потенциального индекса покрытия, вызывающих загрузку страниц данных (и перегрузку кэша сервера), вызывающих блокировки строк/страниц/таблиц, которых в противном случае можно было бы избежать.

Соотнесите это с потенциальной экономией, связанной с указанием столбцов, с *, и единственная потенциальная экономия:

  1. Программисту не нужно пересматривать SQL для добавления столбцов
  2. Сетевой транспорт SQL меньше/быстрее
  3. Время разбора/проверки запроса SQL Server
  4. Кэш плана запросов SQL Server

Для пункта 1 реальность такова, что вы собираетесь добавить/изменить код, чтобы использовать любой новый столбец, который вы можете добавить в любом случае, так что это мойка.

Для пункта 2 различие достаточно редко, чтобы подтолкнуть вас к другому размеру пакета или количеству сетевых пакетов. Если вы дойдете до того момента, когда доминирующим вопросом будет время передачи операторов SQL, вам, вероятно, сначала нужно уменьшить скорость операторов.

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

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

Таким образом, все это сводится к тому, как вы задали вопрос, к отказоустойчивости перед лицом возможных изменений схемы. Если вы записываете эту схему в ROM (это происходит), тогда * вполне приемлемо.

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

Мой совет, что вы должны ВСЕГДА ВЫБРАТЬ конкретные столбцы. Помните, что вы хорошо разбираетесь в том, что вы делаете снова и снова, поэтому просто привыкните делать это правильно.

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

57
IDisposable

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

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

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

33
Giorgi

Есть четыре причины, по которым select * - это плохо:

  1. Наиболее значимая практическая причина заключается в том, что он заставляет пользователя волшебным образом знать порядок, в котором будут возвращаться столбцы. Лучше быть явным, что также защищает вас от смены таблицы, которая хорошо переходит в ...

  2. Если имя столбца, которое вы используете, изменяется, лучше перехватить его раньше (в момент вызова SQL), а не когда вы пытаетесь использовать столбец, который больше не существует (или его имя изменилось и т.д.) )

  3. Перечисление имен столбцов делает ваш код намного более самодокументированным и, вероятно, более читабельным.

  4. Если вы передаете по сети (или даже если нет), столбцы, которые вам не нужны, просто напрасны.

30
pkh

Указание списка столбцов является обычно лучшим вариантом, потому что ваше приложение не будет затронуто, если кто-то добавит/вставит столбец в таблицу.

9
ilitirit

Указывать имена столбцов определенно быстрее - для сервера. Но если

  1. производительность не является большой проблемой (например, это база данных контента веб-сайта с сотнями, может быть, тысячами - но не миллионами - строк в каждой таблице); А ТАКЖЕ
  2. ваша задача - создать много небольших похожих приложений (например, общедоступные веб-сайты, управляемые контентом), используя общую структуру, а не создавать сложное одноразовое приложение; А ТАКЖЕ
  3. важна гибкость (много настроек схемы БД для каждого сайта);

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

Я знаю, что гуру БД возненавидят меня за это - продолжайте, проголосуйте за меня - но в моем мире времени разработчиков мало, а циклов ЦП много, поэтому я соответствующим образом корректирую то, что я сохраняю и что я трачу.

6
Herb Caudill

SELECT * - плохая практика, даже если запрос не передается по сети.

  1. Выбор большего количества данных, чем нужно, делает запрос менее эффективным - сервер должен считывать и передавать дополнительные данные, что требует времени и создает ненужную нагрузку на систему (не только сеть, как упоминалось другими, но также диск, процессор и т.д.). ). Кроме того, сервер не может оптимизировать запрос так же, как он может (например, использовать индекс запроса для запроса).
  2. Через некоторое время структура вашей таблицы может измениться, поэтому SELECT * вернет другой набор столбцов. Таким образом, ваше приложение может получить набор данных неожиданной структуры и сломаться где-то вниз по течению. Явное указание столбцов гарантирует, что вы либо получите набор данных известной структуры, либо получите явную ошибку на уровне базы данных (например, "столбец не найден").

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

6
VladV

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

4
Yann Ramin

Пока здесь есть много веских причин, вот еще одна, о которой не упоминалось.

Явное присвоение имен столбцам поможет вам в обслуживании в будущем. В какой-то момент вы собираетесь внести изменения или устранить неполадки, и вы задаетесь вопросом: "Где, черт возьми, этот столбец используется".

Если у вас есть имена, перечисленные в явном виде, то найти каждую ссылку на этот столбец - через все ваши хранимые процедуры, представления и т.д. - просто. Просто дамп сценария CREATE для вашей схемы БД и текстовый поиск по нему.

4
Chris Wuestefeld

Вы действительно должны выбрать только те поля, которые вам нужны, и только необходимое количество, т.е.

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

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

4
Matthew Abbott

Проблема с "select *" заключается в возможности получения данных, которые вам не нужны. Во время фактического запроса к базе данных выбранные столбцы не добавляются к вычислениям. Что действительно "тяжело", так это передача данных обратно вашему клиенту, и любой столбец, который вам на самом деле не нужен, просто тратит пропускную способность сети и увеличивает время ожидания запроса на возврат.

Даже если вы используете все столбцы, извлеченные из "select * ...", это только сейчас. Если в будущем вы измените макет таблицы/представления и добавите больше столбцов, вы начнете вносить их в выбранные элементы, даже если они вам не нужны.

Еще один момент, в котором утверждение "select *" является неправильным, - это создание представления. Если вы создаете представление с помощью "select *", а затем добавляете столбцы в таблицу, определение представления и возвращаемые данные не будут совпадать, и вам нужно будет перекомпилировать ваши представления, чтобы они снова заработали.

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

3
Alexandre Brasil

Хотя явное перечисление столбцов хорошо для производительности, не сходите с ума.

Поэтому, если вы используете все данные, попробуйте SELECT * для простоты (представьте, что у вас много столбцов и выполнение запроса JOIN ... может оказаться ужасным). Тогда - мера. Сравните с запросом с явно указанными именами столбцов.

Не рассуждайте о производительности, измерить!

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

3
Paweł Hajdan

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

3
Nick Berardi

Всегда лучше указывать нужные столбцы, если вы думаете об этом один раз, SQL не должен думать "wtf is *" каждый раз, когда вы запрашиваете. Кроме того, кто-то позже может добавить столбцы в таблицу, которые вам на самом деле не нужны в вашем запросе, и вам будет лучше в этом случае, указав все ваши столбцы.

3
BrewinBombers

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

Разница в памяти, а не в скорости. При выборе нескольких столбцов SQL Server должен выделять пространство памяти для обслуживания запроса, включая все данные для всех запрошенных столбцов, даже если вы используете только один из них.

Что важно с точки зрения производительности, так это план исключений, который, в свою очередь, сильно зависит от вашего предложения WHERE и количества JOIN, OUTER JOIN и т.д.

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

2
Jorge Córdoba

Результат слишком велик. Медленно генерировать и отправлять результат из механизма SQL клиенту.

Клиентская сторона, являясь общей средой программирования, не предназначена и не должна быть предназначена для фильтрации и обработки результатов (например, предложение WHERE, предложение ORDER), поскольку число строк может быть огромным (например, десятки миллионов строк).

2
kennytm

Наименование каждого столбца, который вы ожидаете получить в своем приложении, также гарантирует, что ваше приложение не сломается, если кто-то изменит таблицу, пока ваши столбцы все еще присутствуют (в любом порядке).

2
Don

НЕТ быстрее использовать явные имена полей по сравнению с *, если и только если вам нужно получить данные для всех полей.

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

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

Другой недостаток использования явных имен полей состоит в том, что если их много и они длинные, это затрудняет чтение кода и/или журнала запросов.

Таким образом, правило должно быть таким: если вам нужны все поля, используйте *, если вам нужно только подмножество, назовите их явно.

2
user9385

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

1
Keith

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

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

Что касается того, что быстрее, я буду полагаться на других за их опыт.

1
dpollock

И помните, что если у вас есть внутреннее соединение по определению, вам не нужны все столбцы, поскольку данные в столбцах соединения повторяются.

Это не значит, что перечисление столбцов на сервере SQl сложно или даже отнимает много времени. Вы просто перетаскиваете их из браузера объектов (вы можете получить все за один раз, перетаскивая из столбцов Word). Постоянное снижение производительности вашей системы (поскольку это может сократить использование индексов и, как следствие, отсылка ненужных данных по сети, является дорогостоящим), и повысить вероятность возникновения непредвиденных проблем при изменении базы данных (иногда добавляются столбцы, которые вы не хотите, чтобы пользователь видел, например) просто сэкономить меньше минуты времени на разработку - недальновидно и непрофессионально.

1
HLGEM

Что все выше сказанное, плюс:

Если вы стремитесь к читаемому сопровождаемому коду, сделайте что-то вроде:

SELECT foo, панель ОТ виджетов;

мгновенно читается и показывает намерение. Если вы сделаете этот звонок, вы знаете, что вы получаете обратно. Если у виджетов есть только столбцы foo и bar, то выбор * означает, что вам все равно нужно подумать о том, что вы получаете, подтвердить правильность отображения порядка и т.д. Однако, если виджеты имеют больше столбцов, но вас интересует только foo и бар, тогда ваш код становится грязным, когда вы запрашиваете шаблон, а затем используете только часть из того, что было возвращено.

1
Faisal

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

1
Mark Etable

В дополнение к тому, что сказали все остальные, если все выбранные вами столбцы включены в индекс, ваш набор результатов будет извлечен из индекса вместо поиска дополнительных данных из SQL.

1
Mike

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

Это также зависит от объема данных, которые вы хотите передать с сервера. Если один из столбцов определен как памятка, графика, блоб и т.д., И вам не нужен этот столбец, лучше не использовать "Выбрать *", либо вы получите целую кучу данных, которые вам не нужны хочу, и ваша производительность может пострадать.

1
Mark

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

С увеличением наборов данных и более быстрыми темпами роста данных преимущество в производительности становится все более и более важным.

Чтобы наглядно увидеть, есть ли какая-либо разница, я бы предложил использовать анализатор запросов, чтобы увидеть план выполнения запроса для SELECT * и эквивалентный SELECT col1, col2 и т.д. Это должно сказать вам, какой из двух запросов более эффективен. Вы также можете сгенерировать некоторые тестовые данные разного объема, чтобы увидеть, каковы сроки.

0
Scott Lawrence

Конечно, меня это задело, но я делаю выбор *, потому что почти все мои данные извлекаются из представлений SQL Server, которые предварительно объединяют необходимые значения из нескольких таблиц в одно легкодоступное представление.

Затем я хочу, чтобы все столбцы из представления не изменялись при добавлении новых полей в базовые таблицы. Это дает мне дополнительное преимущество, позволяя мне менять источник данных. Поле А в представлении может быть рассчитано за один раз, а затем я могу изменить его на статическое. В любом случае View предоставляет мне FieldA.

Прелесть этого в том, что он позволяет моему уровню данных получать наборы данных. Затем он передает их моему BL, который затем может создавать объекты из них. Мое главное приложение знает и взаимодействует только с объектами. Я даже позволяю своим объектам создавать себя при прохождении datarow.

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

0
klkitchens

Абсолютно определите столбцы, которые вы хотите выбрать каждый раз. Нет причин не делать этого, и улучшение производительности того стоит.

Им никогда не следовало выбирать "ВЫБРАТЬ *"

0
cazlab

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

Я бы проигнорировал комментарии о том, как * нужно получить список - шансы разбора и проверки именованных столбцов равны времени обработки, если не больше. Не преждевременно оптимизировать ;-)

0
DamienG

Основное различие между ними заключается в количестве данных, передаваемых туда и обратно. Любые рассуждения о разнице во времени в корне ошибочны в том, что "select *" и "select col1, ..., colN" приводят к одинаковому объему относительной работы, выполняемой механизмом БД. Однако передача 15 столбцов в строке против 5 столбцов в строке - это разница в 10 столбцов.

0
Jeff Hubbard

С точки зрения эффективности исполнения я не знаю какой-либо существенной разницы. Но для эффективности программистов я бы написал названия полей, потому что

  • Вы знаете порядок, если вам нужно индексировать по номеру, или если ваш драйвер ведет себя смешно с BLOB-значениями, и вам нужен определенный порядок
  • Вы читаете только те поля, которые вам нужны, если вам нужно добавить больше полей
  • Вы получаете ошибку sql, если вы неправильно написали или переименовали поле, а не пустое значение из набора записей/строки
  • Вы можете лучше прочитать, что происходит.
0
Erik

Я вижу, что некоторые люди думают, что для определения столбцов требуется гораздо больше времени. Поскольку вы можете перетащить список столбцов из обозревателя объектов, может потребоваться дополнительная минута, чтобы указать столбцы (то есть, если у вас много столбцов и вам нужно потратить некоторое время на их размещение в отдельных строках) в запросе. Почему люди думают, что это так много времени?

0
HLGEM

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

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

0
mxsscott

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

Когда вы используете (select *) в запросе и если кто-то изменяет таблицу и добавляет новые поля, которые не нужны для предыдущего запроса, это приводит к ненужным накладным расходам. А что, если вновь добавленное поле является блобом или полем изображения ??? тогда ваше время ответа на запрос будет очень медленным.

С другой стороны, если вы используете (выберите col1, col2, ..) и если таблица изменена и добавлены новые поля, и если эти поля необходимы в наборе результатов, вам всегда нужно редактировать запрос на выбор после изменения таблицы.

Но я предлагаю всегда использовать select col1, col2, ... в ваших запросах и изменять запрос, если таблица будет изменена позже ...

0
Lahiru Cooray

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

Другая проблема, которая возникает при использовании select *, заключается в том, что есть идиоты, которые выбирают добавлять новые поля в середину таблицы (всегда плохая практика), если вы используете select * в качестве основы для вставки, то внезапно ваш порядок столбцов может быть неправильно, и вы можете попытаться вставить номер социального страхования в гонорар (сумма денег, которую спикер может заплатить, чтобы выбрать неслучайный пример), что может быть очень плохо для целостности данных. Даже если выбор не является вставкой, он выглядит плохо для клиента, когда данные внезапно оказываются в рабочем порядке в отчете или на веб-странице.

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

0
HLGEM

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

в конечном счете, лучший план - выбрать конкретные столбцы.

0
siculars

Также имейте в виду изменения. Сегодня Select * только выбирает нужные вам столбцы, но завтра он может также выбрать тот столбец varbinary (MAX), который я только что добавил, не сообщая вам, и теперь вы также получаете все 3,18 гигабайта двоичных данных, которые не были вчера в таблице.

0
Michael Stum

Давайте думать о том, что быстрее. Если вы можете выбрать только те данные, которые вам нужны, то это быстрее. Однако при тестировании вы можете извлечь все данные, чтобы определить, какие данные можно отфильтровать в зависимости от потребностей бизнеса.

0
mikedopp

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

Это особые случаи, такие как представления или хранимые процедуры, где вы хотите, чтобы изменения в базовых таблицах распространялись без необходимости переходить и изменять каждое представление и хранимый процесс, использующий таблицу. Даже тогда это само по себе может вызвать проблемы, как в случае, когда у вас есть два вида, которые объединены. Одна базовая таблица изменяется, и теперь представление является неоднозначным, поскольку обе таблицы имеют столбец с одинаковым именем. (Обратите внимание, что это может произойти в любое время, когда вы не квалифицируете все свои столбцы с префиксами таблиц). Даже с префиксами, если у вас есть такая конструкция:

ВЫБЕРИТЕ A ., B. - у вас могут быть проблемы, когда клиенту сейчас трудно выбрать правильное поле.

В общем, я не использую SELECT *, если я не принимаю осознанное дизайнерское решение и не рассчитываю на низкий риск.

0
Cade Roux

SELECT *может будет в порядке, если вам действительно нужны все столбцы, но вы все равно должны перечислить их все по отдельности. Вы, конечно, не должны выбирать все строки из таблицы - даже если приложение и БД находятся на одном сервере или в сети. Передача всех строк займет время, особенно с ростом числа строк. У вас должно быть хотя бы предложение where, фильтрующее результаты, и/или страницы результатов, чтобы выбрать только подмножество строк, которые должны отображаться. Существует несколько инструментов ORM, в зависимости от языка приложения, который вы используете, чтобы помочь в запросе и разбивке на подмножество нужных вам данных. Например, в .NET Linq to SQL, Entity Framework и nHibernate все помогут вам в этом.

0
bkaid

Используйте конкретные имена полей, поэтому, если кто-то изменит таблицу на вас, вы не получите неожиданных результатов. По теме: ВСЕГДА указывайте имена полей при выполнении вставки, поэтому, если вам нужно добавить столбец позже, вам не нужно возвращаться и исправлять свою программу и одновременно изменять базу данных в производственном выпуске.

0
stu

Если вы беспокоитесь о скорости, убедитесь, что вы используете подготовленные заявления. Иначе я с ilitirit, что изменения - это то, от чего ты защищаешь себя.

/ Allan

0
Allan Wind

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

0
Sam Cogan

Это старый пост, но все еще действующий. Для справки у меня есть очень сложный запрос, состоящий из:

  • 12 столов
  • 6 левых присоединений
  • 9 внутренних соединений
  • Всего 108 столбцов на всех 12 таблицах
  • Мне нужно только 54 колонки
  • 4 столбца Order By

Когда я выполняю запрос, используя Select *, он занимает в среднем 2869 мс. Когда я выполняю запрос с помощью Select, он занимает в среднем 1513 мс.

Всего возвращено строк 13,949.

Нет сомнений, что выбор имени столбца означает более высокую производительность по сравнению с Select *

0

Для непосредственного обращения к БД (например, по приглашению sqlplus или через инструмент администрирования БД) выберите *, как правило, хорошо - это избавляет вас от необходимости записывать все столбцы.

С другой стороны, в коде приложения лучше всего перечислять столбцы. Это имеет несколько преимуществ:

  • Код понятнее
  • Вы будете знать порядок, в котором возвращаются результаты (это может или не может быть важно для вас)
0
Morikal

Ну, это действительно зависит от ваших показателей и цели:

  1. Если у вас 250 столбцов и вы хотите (действительно) выделить их все, используйте select *, если вы хотите вернуться домой в тот же день :)
  2. Если вашему кодированию нужна гибкость и нужная таблица мала, снова выберите *, чтобы ускорить код и упростить его обслуживание.
  3. Если вы хотите надежную конструкцию и производительность:
    • напишите названия столбцов, если их всего несколько, или
    • написать инструмент, который позволяет вам легко выбирать/генерировать имена столбцов

Как правило, когда мне нужно выбрать все столбцы, я бы использовал "select *", если у меня нет особой причины поступать иначе (плюс, я думаю, это быстрее для таблиц с большим количеством столбцов)

И последнее, но не менее важное: как вы хотите, чтобы добавление или удаление столбца в таблице влияло на ваш код или его обслуживание?

0
Notitze