Должен ли я использовать обратные ссылки или нет при экранировании ключевых слов в MySQL?

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Или, если вы хотите, чтобы код был совместим с обоими, вы можете выполнить замену внутри нескольких функций, которые обрабатывают / подготавливают 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 \'s 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_»), это скучно, но в основном безопасно и переносимо.