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

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

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

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

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

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

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

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

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

Мне ваши правила нравятся.

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

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

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

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

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

   NB: Удобочитаемость может быть особенно нарушена, когда вам нужно сгенерировать код 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. Большинство зарезервированных слов в любом случае являются плохими кандидатами для именования таблиц, столбцов, переменных и т. д. В подавляющем большинстве случаев существительные (иногда прилагательные) намного лучше подходят для имен, чем глаголы, наречия и предлоги. :-)

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

</2c>