В чем причина не использовать select *?

Question

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

Если я все равно собираюсь использовать все столбцы, почему бы мне не использовать SELECT *?

Даже с учетом вопроса * SQL-запрос - выберите * в представлении или выберите col1, col2, ... colN в представлении *, я не думаю, что это точный дубликат при приближении к проблеме с немного другой точки зрения.

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

Тем не менее, есть ли основная проблема не использовать SELECT *?

Answer 1

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

Answer 2

Чтобы ответить на ваш вопрос напрямую: не используйте «SELECT *», когда он делает ваш код более уязвимым к изменениям в базовых таблицах. Ваш код должен ломаться только тогда, когда в таблицу вносятся изменения, которые напрямую влияют на требования вашей программы.

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

Answer 3

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

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

Answer 4

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

Answer 5

Я не использую SELECT * просто потому, что приятно видеть и знать, какие поля я получаю.

Answer 6

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

Так что в основном это вопрос ремонтопригодности! Если вы не используете селектор *, вам не придется беспокоиться о своих запросах.

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

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