Имеет ли смысл использовать скобочную запись SQL Server в написанном от руки коде?

Генераторы кода имеют тенденцию быть проще, когда они генерируют вывод, используя новую скобочную нотацию Microsoft ( []) почти для всего.

Когда я впервые увидел это, я, правда, удивился реинкарнации несколько запрещенной цитируемой записи идентификатора.

Насколько я знаю, это проприетарное расширение от Microsoft (то есть Oracle не поддерживает его).

Глядя на SQL Server, нет никакой разницы, если вы определяете таблицу как

CREATE TABLE [dbo].[Table_2] ([col1] [int], [col2] [int]);

или

CREATE TABLE dbo.Table_2 (col1 int, col2 int);

Это вопрос личного или корпоративного стиля. Быть последовательным.

Теперь, если вы хотите перенести вашу базу данных в Oracle, скобки не подходят.

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

Является ли хорошей идеей удалить все скобки из сгенерированного кода, избегать использования пробелов, других специальных символов и зарезервированных ключевых слов для имен и просто кода таким образом, который понимает большинство СУБД?

Стандартный SQL использует двойные кавычки "для идентификаторов в кавычках. SQL Server поддерживает это с помощью QUOTED_IDENTIFIERопции ( ANSI_QUOTESв mySQL). Стандартный SQL улучшает переносимость в целом и в этом случае переносит в Oracle. Точно так же я изменил бы ключевые слова SQL на верхний регистр (требование Промежуточного SQL-92) и расширил бы intдо INTEGER(требование уровня SQL-92 начального уровня).

Излишне использовать цитируемые идентификаторы, какой бы ни была разновидность, следует избегать, ИМО.

Это субъективная проблема, но ненужные скобки находятся в верхней части моего списка любимых писарей - немного более раздражающе, чем опечатка "! =", Но не так плохо, как начальные запятые в списках столбцов.

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

• Скобки требуются, если имена вашей таблицы или столбца:

  • содержать пробел: SELECT [column name] FROM table;
  • содержать скобку: SELECT [wt[f]илиSELECT [wt]]f]
  • содержать не буквенно-цифровой символ, например ^или !(да, они могут содержать эти символы!)
  • являются зарезервированными ключевыми словами , как KEY, STATE, RULE, ...

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

  Я также использую скобки, чтобы скрыть синюю подсветку, которую SSMS и VS дают некоторые ключевые слова, подобные DESCRIPTIONэтим, которые не зарезервированы SQL Server, но в остальном являются специальными для этих инструментов.

• Обязательно используйте скобки при динамическом генерировании SQL. Самый простой способ сделать это - вызвать QUOTENAME()объекты, на которые вы динамически ссылаетесь (например SELECT QUOTENAME(name) FROM sys.databases;). sp_MSforeachdbНапример, не делает этого .

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

Я бы, вероятно, даже не пытался иметь портативный DDL. Было бы лучше, если бы я генерировал определения таблиц Oracle из системных представлений SQL Server, если это необходимо.

Я не думаю, что имеет смысл писать переносимый DML - PL / SQL полностью отличается от T-SQL. Для переносимости проще выставить вашу базу данных через API хранимых процедур. Подписи этих процедур должны быть одинаковыми на обеих платформах, но реализации могут использовать проприетарные функции - в целом это гораздо проще, чем пытаться использовать только стандарт SQL ANSI.

Этот вывод основан на многолетнем опыте разработки портативных систем, работающих как на Oracle, так и на SQL Server.