Должен ли я использовать backticks или нет, когда избегаю ключевых слов в MySQL?

Должны ли все имена таблиц в MySQL быть заключены в backticks (`) для предотвращения коллизий с зарезервированными ключевыми словами? Причина, по которой я спрашиваю, заключается в том, что их использование делает SQL менее переносимым, поскольку не все базы данных позволяют использовать обратные ссылки.

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

Есть ли лучшая практика в этом отношении?

Ответ 1

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

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

Избегание зарезервированных ключевых слов всегда является лучшим решением.

Ответ 2

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

Ответ 3

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

Короче говоря, да. И мало что можно сделать в отношении будущих ключевых слов, за исключением исключения очевидных кандидатов, например. with, window, over и т.д.

Ответ 4

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

Ответ 5

Не избегать и ручно избегать конфликтов с зарезервированными именами с ключевыми словами может быть довольно утомительным делом, поскольку зарезервированные имена сильно различаются в разных базах данных. Например, вы можете использовать User в MySQL, но не на MSSQL.

Это также сводится к тому, на что нацелены SQL-запросы: являются ли они запросами создания таблицы? инициализационные запросы? "обычные" запросы? Это важно, так как есть другие факторы, которые будут зависеть от базы данных SQL (например, использование AUTO_INCREMENT при создании таблицы).

Это также зависит от того, являются ли это рукописными файлами SQL, которые вы загружаете и запускаете непосредственно в базу данных или программно сконструированные/заполненные. В последнем случае я бы использовал доступные средства или написал микро-драйвер, который инкапсулирует специфику диалектов базы данных. Мы здесь не говорим ORM, просто что-то, что поможет закрыть эту проблему.

Мне ответ "попытаться избежать их" - это путь решения наименьшего сопротивления, который может или не может укусить вас в какой-то момент в зависимости от роли ваших запросов. Может быть, ваш вопрос слишком широк?

Ответ 6

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

Стандартный SQL не используется для обратных ссылок. Таким образом, нельзя ли обратные ссылки в DDL просто заменить глобально двойными кавычками SQL-стандарта? Если это так, это всего лишь однострочный файл в файле make.

Ответ 7

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

Ваш SQL может быть немного менее портативным, но на самом деле.. замена обратной ссылки двойной кавычкой - это вопрос одного поиска/замены в файле (если вы не используете также оператор выполнения backtick PHP в том же файле), Вы не можете сделать это в обратном порядке: замените двойные кавычки на обратные такты, поскольку другие строки также могут быть изменены (все для оператора "execute" PHP, ugh!)!

Или, если вы хотите, чтобы код был совместим с вами, вы можете сделать замену внутри нескольких функций, которые обрабатывают/готовят SQL:

function myExecute($sql,$params) {
     if(NOT_MYSQL) $sql=str_replace('`','"',$sql);
     return execute($sql,$params);
}

Что вам нужно НИКОГДА делать, это использовать двойные кавычки, чтобы заключать строковые значения в SQL. Это разрешено MySQL, но очень плохо для переносимости. Возможно, вам придется заменить все свои строки вручную.

<?php
// Don't. Use ' for strings instead
$sql='SELECT "col1" FROM "tab" WHERE "col2"="very bad"';

// Better
$sql="SELECT `col1` FROM `tab` WHERE `col2`='not that bad'";

// May crash later if tab becomes a keyword (or col1, or col2,..)
$sql="SELECT col1 FROM tab WHERE col2='not that bad'";

// Standard. But harder to replace ""s to ``s later, and annoying \ in code
$sql='SELECT "col1" FROM "tab" WHERE "col2"=\'not that bad\'';

// Safe. Annoying.
$sql="SELECT my_unique_col1 FROM my_unique_tab WHERE my_unique_col2='not that bad'";

?>

Как вы видите в последнем примере, вы можете назвать свои таблицы и поля способом, который, вероятно, уникален (добавьте префикс для всех, в данном случае "my_unique_" ), это скучно, но в основном безопасно и переносимо.