Ha senso usare la notazione di parentesi di SQL Server nel codice scritto a mano?

I generatori di codice tendono ad essere più semplici quando generano output utilizzando la nuova notazione di parentesi Microsoft ( []) per quasi tutto.

Quando l'ho visto per la prima volta, ho comunque stupito una reincarnazione della notazione identificativa citata in qualche modo vietata.

Per quanto ne so, è un'estensione proprietaria di Microsoft (il che significa che Oracle non lo supporta).

Guardando SQL Server non c'è differenza se si definisce una tabella simile

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

o

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

È una questione di stile personale o aziendale. Sii coerente.

Ora, se si desidera migrare il database su Oracle, le parentesi non sono disponibili.

È possibile utilizzare i vecchi identificatori tra virgolette, ma questi sono case sensitive che causano molti problemi.

È una buona idea rimuovere tutte le parentesi dal codice generato, evitare di usare spazi vuoti, altri caratteri speciali e parole chiave riservate per i nomi e solo il codice in un modo che la maggior parte dei DBMS capisce?

SQL standard utilizza la doppia virgoletta "per identificatori tra virgolette. SQL Server supporta questo utilizzando l' QUOTED_IDENTIFIERopzione ( ANSI_QUOTESin mySQL). SQL standard migliora la portabilità in generale e in questo caso porterebbe a Oracle. Allo stesso modo cambierei le parole chiave SQL in maiuscolo (requisito SQL-92 intermedio) e mi espanderei inta INTEGER(requisito SQL-92 entry level).

Usare inutilmente identificatori citati, qualunque sia il sapore, dovrebbe essere evitato, IMO.

Questo è un problema soggettivo, ma le parentesi non necessarie si trovano in cima alla mia lista di animali domestici - leggermente più fastidiosa dell'errore di ortografia "! =", Ma non così male come le virgole principali negli elenchi di colonne.

Parlando oggettivamente, considera lo scopo delle parentesi: consentire nomi di oggetti che altrimenti non sarebbero legali. Dato questo scopo, le parentesi sono un odore di codice nella peggiore delle ipotesi e un segno di pigrizia nella migliore delle ipotesi.

• Le parentesi sono necessarie se i nomi di tabella o colonna:

  • contenere uno spazio: SELECT [column name] FROM table;
  • contiene una parentesi:, SELECT [wt[f]oSELECT [wt]]f]
  • contenere un simbolo non alfanumerico come ^o !(sì, possono contenere quei simboli!)
  • sono parole chiave riservate come KEY, STATE, RULE, ...

  Ovviamente, se hai il controllo sullo schema, evita di usare nomi come questi. Tuttavia, in alcuni casi il nome migliore è riservato (come KEYper la colonna chiave in una tabella di valori-chiave generica), quindi spetta a voi decidere quanto male volete usarlo (e quindi doverlo citare ovunque).

  Uso anche le parentesi quadre per eliminare l'evidenziazione blu che SSMS e VS forniscono alcune parole chiave come DESCRIPTIONquelle non riservate da SQL Server ma altrimenti speciali per quegli strumenti.

• Sicuramente usare le parentesi quadre durante la generazione dinamica di SQL. Il modo più semplice per farlo è richiamare QUOTENAME()gli oggetti a cui si fa riferimento in modo dinamico (ad es SELECT QUOTENAME(name) FROM sys.databases;.). sp_MSforeachdb, ad esempio, non lo fa .

Quando scrivo codice che genera codice, inserisco le parentesi quadre attorno ai nomi degli oggetti del database. Non includo le parentesi quadre durante la scrittura manuale del codice e trovo che ciò pregiudichi la leggibilità del codice. Inoltre proibisco i nomi degli oggetti del database con spazi. SQL Server ti consentirà di utilizzare spazi nei nomi degli oggetti, ma ciò non significa che sia una buona cosa.

Probabilmente non proverei nemmeno ad avere un DDL portatile. Starei meglio se generassi le definizioni delle tabelle Oracle dalle viste di sistema di SQL Server, se necessario.

Non penso che abbia senso scrivere DML portatile - PL / SQL è totalmente diverso da T-SQL. Per motivi di portabilità, è più semplice esporre il database tramite un'API di stored procedure. Le firme di queste procedure devono essere le stesse su entrambe le piattaforme, ma le implementazioni possono utilizzare funzionalità proprietarie: nel complesso, ciò è molto più semplice rispetto al tentativo di utilizzare solo SQL standard ANSI.

Questa conclusione si basa su diversi anni di esperienza nello sviluppo di sistemi portatili, lavorando sia su Oracle che su SQL Server.