Проверяете ли вы имена полей и таблиц по спискам зарезервированных слов?

Question

У меня иногда возникали проблемы с именами хранимых процедур для полей, таблиц, представлений. Пример:

   SELECT from, to, rate FROM Table1

Проблема в том, что из является зарезервированным словом в SQL-92. Вы можете поместить имя поля в двойные кавычки, чтобы это исправить, но что, если некоторые другие инструменты БД захотят прочитать вашу базу данных? Это ваша база данных, и это ваша вина, если другие приложения имеют проблемы с вашей БД.

Есть много других зарезервированных слов (~ 300), и мы должны избегать их всех. Если вы измените СУБД с производителя A на B, ваше приложение может не работать, потому что некоторые имена полей теперь являются зарезервированными словами. Поле с именем PERCENT может работать для Oracle db, но на MS SQL Server оно должно рассматриваться как зарезервированное слово.

У меня есть инструмент для проверки дизайна моей базы данных по этим зарезервированным словам; ты тоже?

Вот мои правила

1. не использовать имена длиннее 32 символов (некоторые СУБД не могут обрабатывать более длинные имена)
2. используйте только a-z, A-Z, 0-9 и подчеркивание (: -;, / &! =? + - не допускаются)
3. не начинайте имя с цифры
4. избегайте этих зарезервированных слов

Answer 1

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

Заключение их в кавычки может сделать код действительно неуклюжим, так как вам приходится постоянно экранировать символ кавычки в ваших SQL-выражениях внутри кода. Это также делает командную строку SQL настоящей PITA, на мой взгляд.

В конце концов, это выглядит грязно. Намного лучше потратить время на придумывание другого слова, которое не конфликтует с ключевыми словами SQL.

Твои правила выглядят хорошо для меня.

Answer 2

Простой способ: просто убедитесь, что каждое имя поля заключено в кавычки.

Редактировать: Любой разумный инструмент БД, достойный своей соли, должен делать то же самое, я, конечно, никогда не сталкивался с какими-либо проблемами (по крайней мере, вне моего собственного кода!)

Answer 3

Определенно. У меня есть таблица SQL_RESERVED_WORDS для этой цели.

Oracle может обрабатывать только 30 символов таблицы имен. И все они в верхнем регистре.

Потребуется всего один час ненужной отладки, прежде чем таблица окупится.

Answer 4

Я согласен со вторым пунктом Ярика о пригодности зарезервированных слов. В примере с OP он использует «to», «from» и «rate». Непосредственный вопрос, который у меня возникает, и, следовательно, возможно, у будущего разработчика, звучит так: «Для чего?» Возможно, стоит рассмотреть переименование этих столбцов в «EffectiveFromDate» и «EffectiveUntilDate», если это то, что они представляют.

</ 2в>

Answer 5

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

1. Вам не придется использовать кавычки (или квадратные скобки в мире MS), которые существенно ухудшают читабельность.

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

   Например, как бы вы хотели такие фрагменты:

   -- SQL -----------------------
   declare @sql as varchar(4000)
   set @sql = 'select "To", "From" from MyTable'
   
   ' VB -------------------------
   Dim sql as String
   sql = "select ""To"", ""From"" from MyTable"
   
   // C++ -----------------------
   String sql = "select \"To\", \"From\" from MyTable"
   

2. Большинство зарезервированных слов в любом случае являются плохими кандидатами для именования таблиц, столбцов, переменных и т. Д. В подавляющем большинстве случаев существительные (иногда прилагательные) гораздо лучше подходят для имен, чем глаголы, наречия и предлоги. : -)

Answer 6

Просто избегайте зарезервированных слов.

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

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