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

Question

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

То есть:

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

Answer 1

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

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

Который, конечно, генерирует плохо именованные таблицы.

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

EXPLAIN EXTENDED Select foo,bar,baz 

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

Обратные галочки не являются частью стандартного ANSI SQL. Из руководства по MySQL:

Если включен режим SQL ANSI_QUOTES, то также допустимо заключать в кавычки идентификаторы

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

Answer 5

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

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

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;

Answer 6

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

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

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

Недостатки:

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

Answer 7

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

Answer 8

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

Answer 9

Простая вещь о обратном кавычке `` используется для обозначения идентификатора, такого как 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..

Answer 10

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

Answer 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 Название, город, код штата

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

ГРУППА ПО Publisher and Location

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