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

15

Генераторы кода имеют тенденцию быть проще, когда они генерируют вывод, используя новую скобочную нотацию 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-server t-sql style bernd_k
источник

Ответы:

12

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

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

onedaywhen
источник
10

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

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

Ларри Коулман
источник
Начальные запятые дают понять, где начинаются новые столбцы. Скобки определенно не являются запахом кода, поскольку они четко определяют, что является именем столбца, а что нет. Я не говорю, что вы должны их использовать, но сказать, что они указывают на проблемы, - это слишком много.
Макс Вернон,
9

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

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

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

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

Ник Чаммас
источник
6

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

datagod
источник
6

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

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

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

Аляска
источник