Использование обратных ссылок вокруг имен полей

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

То есть:

SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...

Ответ 1

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

SELECT `id`, `my name`, `another field` , `field,with,comma` 

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

Если вы просто лаконичны, я не вижу в этом проблемы, вы заметите, что вы запускаете свой запрос как таковой

EXPLAIN EXTENDED Select foo,bar,baz 

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

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

Ответ 2

Единственная проблема с backticks заключается в том, что они не совместимы с ANSI-SQL, например. они не работают в SQL Server.

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

Ответ 3

Для меня имеет смысл использовать их всегда при работе с именами полей.

  • Во-первых, как только вы попадаете в привычку, вам не больно просто ударить по ключу backtick.
  • Во-вторых, для меня это упрощает просмотр того, какие именно поля в вашем запросе, и каковы ключевые слова или методы.
  • Наконец, он позволяет вам использовать любое имя поля, которое вы хотите при разработке своей таблицы. Иногда имеет смысл называть поле "ключ", "порядок" или "значения"... все из которых требуют обратных ссылок при обращении к ним.

Ответ 4

Backticks не являются частью стандартного ANSI SQL. Из руководство mysql:

Если режим ANSI_QUOTES SQL разрешено также указывать идентификаторы в двойных кавычках

Итак, если вы используете backticks, а затем решите отойти от MySQL, у вас возникнет проблема (хотя у вас, вероятно, также есть намного больше проблем)

Ответ 5

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

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

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;

Ответ 6

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

Преимущества:

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

Недостатки:

  • Они не являются стандартными и обычно не переносимы. Однако, если вы не используете обратную линию как часть идентификатора (что является наихудшей практикой, которую я могу себе представить), вы можете переносить свой запрос, автоматически удаляя обратные ссылки.
  • Если некоторые из ваших запросов поступают из Access, они могут указывать имена таблиц с помощью "(и, возможно, вы не можете удалить все" слепо "). Однако допускаются смеси обратных выступов и двойных кавычек.
  • Некоторые глупые программы или функции фильтруют ваши запросы и имеют проблемы с обратными вызовами. Однако они являются частью ASCII, поэтому это означает, что ваше программное обеспечение/функция очень плохая.

Ответ 7

Намного проще искать свою кодовую базу для чего-то в backticks. Скажем, у вас есть таблица с именем event. grep -r "event" * может вернуть сотни результатов. grep -r "\`event\`" * вернет что-нибудь, возможно, ссылаясь на вашу базу данных.

Ответ 8

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

Ответ 9

Простая вещь о backtick `` используется для обозначения идентификатора типа database_name, table_name и одинарной кавычки '', двойная кавычка " > для строковых литералов, тогда как" "использовать для значения печати как есть" и" распечатать переменную переменной значения или в другом случае распечатать текст, который у него есть.

i.e 1.-> use `model`;   
    here `model` is database name not conflict with reserve keyword 'model'
2- $age = 27;
insert into `tbl_people`(`name`,`age`,`address`) values ('Ashoka','$age',"Delhi");

here i used both quote for all type of requirement. If anything not clear let me know..

Ответ 10

если вы используете некоторые имена полей в качестве значений mysql или mssql по умолчанию, например, "status", вам нужно использовать обратные выходы ( "select status from table_name" или "select id from table_name, где status= 1" ), потому что mysql возвращает ошибки или не выполняет запрос.

Ответ 11

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

Например

SELECT CONCAT(Name, ' in ', city, ', ', statecode) AS 'Publisher and Location',
    COUNT(ISBN) AS "# Books",
    MAX(LENGTH(title)) AS "Longest Title",
    MIN(LENGTH(title)) AS "Shortest Title"
FROM Publisher JOIN Book
ON Publisher.PublisherID = Book.PublisherID WHERE INSTR(name, 'read')>0
GROUP BY 'Publisher and Location'
HAVING COUNT(ISBN) > 1;

В приведенном выше утверждении вы видите, как Publisher and Location снова используется в предложении GROUP BY.

Вместо того, чтобы использовать

GROUP BY Наименование, город, код штата

Я просто использовал

GROUP BY Publisher and Location

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