Czy sensowne jest stosowanie notacji nawiasowej programu SQL Server w odręcznym kodzie?

Generatory kodu są zwykle prostsze, gdy generują dane wyjściowe przy użyciu nowej notacji nawiasowej Microsoft ( []) dla prawie wszystkiego.

Kiedy to zobaczyłem, pomyślałem o reinkarnacji nieco zakazanego cytowanego zapisu identyfikatora.

O ile mi wiadomo, jest zastrzeżonym rozszerzeniem firmy Microsoft (co oznacza, że ​​Oracle go nie obsługuje).

Patrząc na SQL Server, nie ma różnicy, jeśli zdefiniujesz tabelę podobną

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

lub

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

To kwestia stylu osobistego lub korporacyjnego. Bądź konsekwentny.

Teraz, jeśli chcesz przeprowadzić migrację bazy danych do Oracle, nawiasy nie są dostępne.

Możesz użyć starych cytowanych identyfikatorów, ale uwzględniają wielkość liter, co powoduje wiele problemów.

Czy dobrym pomysłem jest usunięcie wszystkich nawiasów z generowanego kodu, unikanie używania spacji, innych znaków specjalnych i zastrzeżonych słów kluczowych dla nazw i po prostu kodowanie w sposób zrozumiały dla większości DBMS?

Standardowy SQL używa podwójnego cudzysłowu "dla cytowanych identyfikatorów. SQL Server obsługuje to przy użyciu QUOTED_IDENTIFIERopcji ( ANSI_QUOTESw mySQL). Standardowy SQL ogólnie poprawia przenośność i w tym przypadku byłby przenoszony do Oracle. Podobnie, by zmienić słowo SQL do górnej obudowy (związek pośredni SQL wymóg 92) i rozszerzają intsię INTEGER(poziom wyjściowy SQL 92 wymagań).

Należy niepotrzebnie używać cytowanych identyfikatorów, niezależnie od smaku, IMO.

Jest to kwestia subiektywna, ale niepotrzebne nawiasy klamrowe znajdują się na górze mojej listy petów - nieco bardziej irytujące niż błędne pisowni „! =”, Ale nie tak złe, jak wiodące przecinki na listach kolumn.

Mówiąc obiektywnie, rozważ cel nawiasów: dopuszczając nazwy obiektów, które w innym przypadku nie byłyby legalne. Biorąc pod uwagę ten cel, nawiasy są najgorszym zapachem kodu i co najwyżej oznaką lenistwa.

• Wsporniki są wymagane, jeśli nazwa tabeli lub kolumny:

  • zawierać spację: SELECT [column name] FROM table;
  • zawierać nawias kwadratowy: SELECT [wt[f]lubSELECT [wt]]f]
  • zawierać niealfanumeryczny symbol, taki jak ^lub !(tak, mogą zawierać te symbole!)
  • są zarezerwowane słowa kluczowe , takie jak KEY, STATE, RULE, ...

  Oczywiście, jeśli masz kontrolę nad schematem, unikaj używania takich nazw. Jednak w niektórych przypadkach najlepsza nazwa jest zastrzeżona (np. KEYDla kolumny klucza w ogólnej tabeli klucz-wartość), więc to Ty decydujesz, jak bardzo chcesz go używać (i dlatego musisz go cytować wszędzie).

  Używam również nawiasów, aby ukryć niebieskie podświetlenie, że SSMS i VS podają niektóre takie słowa kluczowe DESCRIPTION, które nie są zarezerwowane przez SQL Server, ale są specjalne dla tych narzędzi.

• Zdecydowanie używaj nawiasów podczas dynamicznego generowania SQL. Najłatwiejszym sposobem jest wywołanie QUOTENAME()obiektów, do których dynamicznie się odwołujesz (np SELECT QUOTENAME(name) FROM sys.databases;.). sp_MSforeachdbna przykład tego nie robi .

Kiedy piszę kod, który generuje kod, umieszczam nawiasy kwadratowe wokół nazw obiektów bazy danych. Nie uwzględniam nawiasów podczas pisania kodu ręcznie i uważam, że szkodzi to jego czytelności. Zabraniam także nazw obiektów bazy danych spacjami. SQL Server pozwoli ci używać spacji w nazwach obiektów, ale to nie znaczy, że to dobrze.

Prawdopodobnie nie próbowałbym nawet mieć przenośnego DDL. Byłbym lepiej, gdybym wygenerował definicje tabel Oracle z widoków systemowych SQL Server, jeśli to konieczne.

Nie wydaje mi się też, żeby pisanie przenośnego DML miało sens - PL / SQL różni się całkowicie od T-SQL. Aby ułatwić przenoszenie, łatwiej jest udostępnić bazę danych za pomocą interfejsu API procedur składowanych. Sygnatury tych procedur muszą być takie same na obu platformach, ale implementacje mogą korzystać z zastrzeżonych funkcji - ogólnie jest to o wiele łatwiejsze niż próba użycia tylko standardowego SQL ANSI.

Wniosek ten opiera się na kilkunastoletnim doświadczeniu w projektowaniu systemów przenośnych, pracujących zarówno na Oracle, jak i SQL Server.