Чи має сенс використовувати позначення дужок 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 вимога).

Необхідно уникати використання котируваних ідентифікаторів, незалежно від аромату, IMO.

Це суб'єктивне питання, але непотрібні дужки знаходяться біля верхнього списку моїх вихованців - трохи більше дратівливо, ніж неправильне написання "! =", Але не так погано, як провідні коми в списках стовпців.

Об'єктивно кажучи, розгляньте мету дужок: дозволити назви об'єктів, які б не були законними в іншому випадку. Враховуючи цю мету, дужки - це кодовий запах в гіршому випадку, а в кращому випадку - лінь.

• Дужки потрібні, якщо назви вашої таблиці чи стовпців:

  • містити пробіл: 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.