SQL Server'ın parantez gösterimini elle yazılmış kodda kullanmak mantıklı mı?

Kod üreteçleri [], hemen hemen her şey için yeni Microsoft parantez gösterimini ( ) kullanarak çıktı ürettiklerinde daha basit olma eğilimindedir .

İlk gördüğümde, biraz yasaklanmış alıntı yapılan tanımlamanın bir reenkarnasyonu vay.

Bildiğim kadarıyla Microsoft'un tescilli bir uzantısıdır (yani Oracle desteklemez).

SQL Server'a baktığınızda,

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

veya

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

Bu kişisel veya kurumsal bir tarz. Tutarlı ol.

Şimdi veritabanınızı Oracle'a taşımak istiyorsanız, parantez seçeneği yoktur.

Eski alıntı tanımlayıcıları kullanabilirsiniz, ancak bunlar büyük / küçük harfe duyarlıdır ve bu da çok fazla soruna neden olur.

Oluşturulan koddaki tüm köşeli parantezleri kaldırmak, adlar için boşluklar, diğer özel karakterler ve ayrılmış anahtar kelimeler kullanmaktan kaçının ve çoğu DBMS'nin anlayacağı şekilde kodlayın iyi bir fikir mi?

Standart SQL, "alıntılanmış tanımlayıcılar için çift ​​tırnak kullanır . SQL Server bunu QUOTED_IDENTIFIER( ANSI_QUOTESmySQL'de) seçeneğini kullanarak destekler . Standart SQL genel olarak taşınabilirliği geliştirir ve bu durumda Oracle'a bağlanır. Benzer şekilde ben harfe SQL anahtar kelimeleri (Orta SQL-92 gereksinim) değiştirmek ve genişletmek istiyorum intiçin INTEGER(giriş seviyesi SQL-92 şartı).

Gereksiz olarak alıntı yapan tanımlayıcıları kullanmak, lezzet ne olursa olsun kaçınılmalıdır, IMO.

Bu sübjektif bir konudur, ancak gereksiz parantezler evcil hayvan peeves listemin üst kısmına yakındır - "! =" Yanlış yazımından biraz daha sinir bozucu, ancak sütun listelerinde önde gelen virgüller kadar kötü değil.

Nesnel olarak konuşursak, parantezlerin amacını düşünün: aksi takdirde yasal olmayacak nesne adlarına izin verme. Bu amaç göz önüne alındığında, parantezler en kötü kod kokusu ve en iyi tembellik işaretidir.

• Tablo veya sütun adlarınız varsa köşeli ayraçlar gereklidir:

  • boşluk içermesi: SELECT [column name] FROM table;
  • köşeli ayraç içerir:, SELECT [wt[f]veyaSELECT [wt]]f]
  • Bir ihtiva olmayan alfanümerik sembolü gibi ^ya !(evet, onlar olabilir bu simgeleri içeren!)
  • Hangi ayrılmış anahtar kelimeler gibi KEY, STATE, RULE, ...

  Açıkçası, şema üzerinde kontrolünüz varsa, bu gibi isimler kullanmaktan kaçının. Bununla birlikte, bazı durumlarda en iyi ad ayrılmış bir addır ( KEYgenel bir anahtar / değer tablosundaki anahtar sütun için olduğu gibi ), bu yüzden onu ne kadar kötü kullanmak istediğinize karar vermek size kalmıştır (ve böylece her yerde alıntı yapmanız gerekir).

  Ayrıca, SSMS ve VS'nin DESCRIPTIONSQL Server tarafından ayrılmadığı, ancak bu araçlara özel olduğu gibi bazı anahtar kelimeler verdiği mavi vurgulamayı bastırmak için köşeli ayraçlar kullanıyorum .

• Dinamik olarak SQL oluştururken parantez kullanın. Bunu yapmanın kolay yolu QUOTENAME(), dinamik olarak başvuruda bulunduğunuz nesneleri çağırmaktır (örn. SELECT QUOTENAME(name) FROM sys.databases;). sp_MSforeachdb, örneğin, bunu yapmaz .

Muhtemelen taşınabilir DDL'ye bile sahip olmayacağım. Gerekirse SQL Server'ın sistem görünümleri dışında Oracle tablo tanımları oluştursaydım daha iyi olurdu.

Taşınabilir DML yazmanın mantıklı olduğunu düşünmüyorum - PL / SQL T-SQL'den tamamen farklı. Taşınabilirlik için, saklı yordamların bir API'sı aracılığıyla veritabanınızı göstermek daha kolaydır. Bu prosedürlerin imzaları her iki platformda da aynı olmalıdır, ancak uygulamalar özel özellikler kullanabilir - genel olarak bu, yalnızca ANSI standart SQL'i kullanmaya çalışmaktan çok daha kolaydır.

Bu sonuç, hem Oracle hem de SQL Server üzerinde çalışan taşınabilir sistemler geliştirmedeki uzun yıllara dayanan deneyime dayanmaktadır.

Kod üreten bir kod yazdığımda, veritabanı köşebentlerini veritabanı nesne adlarının etrafına koydum. Elle kod yazarken köşeli parantezleri dahil etmiyorum ve kodun okunabilirliğinden düştüğünü görüyorum. Ayrıca boşluk ile veritabanı nesne adlarını yasaklar. SQL Server, nesne adlarında boşluk kullanmanıza izin verir, ancak bu iyi bir şey olduğu anlamına gelmez.