Преимущества использования условного обозначения позиции SQL? - программирование

Преимущества использования условного обозначения позиции SQL?

Фоновая информация

Обозначение ординальной позиции, порядковые номера AKA, - это сокращение столбцов на основе порядка столбцов в списке столбцов в предложении SELECT вместо имени столбца или псевдонима столбца. Обычно поддерживаемая в предложении ORDER BY, некоторые базы данных (MySQL 3.23+, PostgreSQL 8.0+) поддерживают синтаксис для предложения GROUP BY.

Вот пример использования Ordinals:

GROUP BY 1, 2
ORDER BY 1, 2

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

Вопрос

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

Раскрытие информации

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

4b9b3361

Ответ 1

Я бы использовал его:

  • Если вам нравится поиск и устранение неисправностей
  • Создание adhoc запросов без intellisense

Нет восходящего движения.

SQL Server поддерживает только ORDER BY. В любом другом месте это выражение должно быть оценено.

Ответ 2

Часто, когда я запрашиваю таблицу с большим количеством столбцов (в ad-hoc-land только для исследования данных... Я бы никогда не кодировал это для среды PROD) Я делаю что-то вроде этого, чтобы получить поля Я забочусь о близких отношениях:

select top 1000
  Col_1, Col_18, Col_50, Col_117, *
from
  TableWithTonsOfCols
order by
  1, 4 desc, 3

Если бы я сказал order by Col_1, Col_117 desc, Col_50, мой запрос был бы barf, потому что оператор не знал, какие столбцы я хотел бы заказать из-за удвоения "*". Не очень распространенная, но все же полезная функция.

Ответ 3

Два варианта использования для меня:

  • Я спешу и не хочу печатать, поэтому я использую порядковый номер. Я бы всегда конвертировал это в имя столбца для любого невременного использования
  • колонка, которую я заказываю, представляет собой длинный оператор CASE; вместо того, чтобы перепечатывать оператор CASE для предложения ORDER BY, я использую порядковый номер, который сохраняет его DRY. Есть способы обойти это, например, используя CTE, подзапросы или представления, но я часто считаю, что порядковый номер является самым простым решением.

Ответ 4

Я обычно использую встроенные представления:

select col_a, count(*) from
  (select case ...... end col_a from ...)
group by col_a
order by col_a;

Но в те дни, когда они были действительным синтаксисом, это помогло перепечатать полный текст столбца. С помощью сложных функций у вас была возможность расхождений между значением в SELECT и ORDER BY, например

select ltrim(col_name,'0123456789')
from table
order by ltrim(col_name,'123456789')

"0" в SELECT означает, что вы не заказываете по выбранному вами.

Ответ 5

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

Ответ 6

У меня есть алгоритм генерации запросов - SQL генерируется автоматически. Использование ординала означает, что я могу ссылаться на сгенерированное поле без необходимости снова вводить имя поля. Пользователь может ссылаться на имя поля в таблице, выбирая его из списка на экране. Пока я делаю список в соответствии с sql, мне никогда не понадобится знать имена полей, если элементы SELECT тоже были ординалы.

Память говорит, что это было в стандарте SQL в конце 1970-х годов