Не используйте в именах спецсимволы

Обоснование
Если в имя включены специальные символы, становится трудно или даже невозможно использовать это имя в БД или в программе на хост-языке, а также переместить схему в другой SQL-продукт.
В табл. 1.2 приведены символы, которые могут быть частью имени в стандартном SQL и в популярных SQL-продуктах.

Табл. 1.2. Символы, допустимые в именах

	Стандартный SQL	IBM	Oracle	Microsoft
Первый символ	Буква	Буква, $ # @	Буква	Буква, # @
Последующие Символы	Буква, цифра, _	Буква, цифра, $ # @ _	Буква, цифра,$ * _	Буква, цифра,* @
Различие верхнего и нижнего регистра	Нет	Нет	Нет	По желанию
Название		Обычный идентификатор	Идентификатор без кавычек	Регулярный идентификатор

Как правило, первым символом имени должна быть буква, а остальные символы могут быть буквами, цифрами и символом подчеркивания “_”. В различных СУБД допускается применение также символов $, # или @, но ни в одной СУБД не допускается применение всех трех сразу. Вообще, нет ни одного спецсимвола, который можно было бы спокойно использовать в любом продукте. В ПО Microsoft, например, имена, начинающиеся символами @ или #, имеют особое значение. В Oracle нельзя использовать спецсимволы в именах некоторых объектов.
Да и с буквами все ли ясно? В оригинальном SQL разрешалось использовать только латинские буквы верхнего регистра, что означает 26 вариантов. В наши дни репертуар несколько расширился, но не злоупотребляйте буквами, не входящими в набор символов Latin-1, и вот почему.
1. В продуктах IBM буквы распознаются не всегда корректно.Буквой считается любой многобайтовый символ за исключением пробела. Регистр символа система не определяет.
2. В продуктах IBM и Oracle используется набор символов из БД.При миграции могут возникнуть проблемы с экзотическими буквами. Продукты Microsoft работают с символами Unicode и с этой проблемой не сталкиваются.
В стандарте SQL-92 не разрешается заканчивать идентификатор символом подчеркивания. Не стоит также вставлять в имя несколько подчеркиваний подряд. При современном лазерном качестве печати пересчитать их будет сложновато.

Исключения
Нет.

По возможности не используйте идентификаторы в кавычках

Обоснование
Идентификаторы в кавычках (quoted identifiers) впервые появились в стандарте SQL-92. Предполагалось, что они будут использоваться для создания псевдонимов столбцов, улучшая читаемость распечаток. В реальности же они противоречат принципам многоуровневой архитектуры, ставят под вопрос переносимость кода и провоцируют программиста на создание неуклюжих систем имен. Основные характеристики идентификаторов с ограничителями (delimited identifiers) суммируются в табл. 1.3.

Табл. 1.3. Символы, допустимые в идентификаторах с ограничителями

	Стандартный SQL	IBM	Oracle	Microsoft
Ограничители	""	""	""	"" или [ ]
Первый символ	Любой	Любой	Любой	Любой
Последующие символы	Любой	Любой	Любой	Любой
Различие верхнего и нижнего регистра	Да	Да	Да	По желанию
Название	Идентификатор с ограничителями	Идентификатор с ограничителями	Идентификатор в кавычках	Идентификатор с ограничителями

Если правила использования символов в именах кажутся вам слишком жесткими, вы вольны обойти их, поместив идентификатор в двойные кавычки. В результате получится так называемый идентификатор с ограничителями (или идентификатор в кавычках, в терминологии Oracle). Идентификатор с ограничителями может начинаться с любого символа и вообще содержать любой символ. Конечно, возникает неясность с использованием внутри идентификатора самого символа ". Стандартный способ — записать его дважды (“Работ""ники”), но в документации он явно описан не всегда.
Поддержка имен с ограничителями практически универсальна, с двумя важными исключениями: 1) продукты IBM допускают использование только букв и цифр для меток и имен переменных в хранимых процедурах; 2) в продуктах Microsoft не разрешается использовать идентификаторы в кавычках при сброшенном флаге QUOTED_IDENTIFIER. Первое исключение связано, вероятно, с тем, что в продуктах IBM процедуры SQL перед компиляцией “переводятся” на другой компьютерный язык.
Рассмотрим в качестве примера создание таблицы с делимитированным идентификатором в качестве имени:

CREATE TABLE "t" ("columni" INTEGER NOT NULL);

Теперь обратимся к таблице так, словно ее имя является обычным идентификатором:

SELECT columni FROM t;

Сработает? Согласно стандарту SQL, не должно, но может сработать в продукте Microsoft. Причины обсуждаются в разделе “Разработайте строгие правила использования прописных букв”.
Идентификаторы в кавычках не особенно хорошо стыкуются с хост-языками, особенно когда в идентификаторе имеются пробелы или спецсимволы. Вот, например, вполне корректное выражение для вставки данных:

INSERT INTO Table ([field with space]) VALUES (value);

Объект ADO сгенерирует следующий код:

INSERT INTO Table (field with space) VALUES (value);

что является синтаксической ошибкой.

Исключения
Иногда нужно поделиться результатом с кем-то, кто не может прочитать или понять имена столбцов с использованием символов из набора Latin-1. В этом случае для форматирования выводимых данных можно применить псевдонимы в кавычках. Мне приходилось делать так для поляков и китайцев.
Я также применял имена в кавычках в документации, чтобы они безошибочно воспринимались как имена объектов схемы, а не как обычные слова в предложениях.
Обычная причина этой ошибки в том, что программист путает имя элемента данных с отображаемым заголовком. В традиционных процедурных языках файл с данными и программа находятся на одном уровне. В SQL база данных полностью отделена от интерфейса, в котором эти данные отображаются.