Apakah masuk akal untuk menggunakan notasi braket SQL Server dalam kode tulisan tangan?

15

Pembuat kode cenderung lebih sederhana ketika mereka menghasilkan keluaran menggunakan notasi braket Microsoft baru ( []) untuk hampir semuanya.

Ketika saya pertama kali melihatnya, saya berpikir wow reinkarnasi dari notasi pengenal yang agak dilarang.

Sejauh yang saya tahu itu adalah ekstensi milik Microsoft (artinya Oracle tidak mendukungnya).

Melihat SQL Server tidak ada perbedaan jika Anda mendefinisikan tabel seperti

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

atau

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

Ini masalah gaya pribadi atau perusahaan. Bersikaplah konsisten.

Sekarang jika Anda ingin memigrasi basis data Anda ke Oracle, tanda kurung bukanlah pilihan.

Anda dapat menggunakan pengidentifikasi yang dikutip lama, tetapi ini adalah case sensitif yang menyebabkan banyak masalah.

Apakah ini ide yang baik untuk menghapus semua tanda kurung dari kode yang dihasilkan, hindari menggunakan tanda kosong, karakter khusus lainnya dan kata kunci yang dicadangkan untuk nama dan kode hanya dengan cara yang dimengerti sebagian besar DBMS?

sql-server t-sql style

— bernd_k
sumber

12

SQL standar menggunakan kutipan ganda "untuk pengidentifikasi yang dikutip. SQL Server mendukung ini menggunakan QUOTED_IDENTIFIERopsi ( ANSI_QUOTESdi mySQL). SQL standar meningkatkan portabilitas secara umum dan dalam hal ini akan port ke Oracle. Demikian pula saya akan mengubah kata kunci SQL ke huruf besar (persyaratan SQL-92 Menengah) dan memperluas intke INTEGER(persyaratan entry level SQL-92).

Tidak perlu menggunakan pengenal yang dikutip, apa pun rasanya, harus dihindari, IMO.

— suatu hari nanti
sumber

10

Ini adalah masalah subyektif, tetapi tanda kurung yang tidak perlu ada di dekat bagian atas daftar saya tentang kencing hewan peliharaan - sedikit lebih menyebalkan daripada salah mengeja "! =", Tetapi tidak seburuk memimpin koma dalam daftar kolom.

Secara obyektif, pertimbangkan tujuan kurung: memungkinkan nama objek yang tidak sah secara hukum. Mengingat tujuan itu, tanda kurung adalah bau kode yang paling buruk, dan merupakan tanda kemalasan.

— Larry Coleman
sumber

Tanda koma membuatnya sangat jelas dari mana kolom baru dimulai. Kurung jelas bukan bau kode karena mereka dengan jelas menggambarkan apa itu nama kolom dan apa yang bukan. Saya tidak mengatakan Anda harus menggunakannya, tetapi untuk mengatakan mereka menunjukkan masalah adalah jangkauan luas.

— Max Vernon

9

Tanda kurung diperlukan jika nama tabel atau kolom Anda:
- mengandung spasi: SELECT [column name] FROM table;
- mengandung braket:, SELECT [wt[f]atauSELECT [wt]]f]
- mengandung simbol non-alfanumerik seperti ^atau !(ya, mereka dapat mengandung simbol-simbol itu!)
- adalah kata kunci yang dipesan seperti KEY, STATE, RULE, ...
Jelas, jika Anda memiliki kendali atas skema tersebut maka hindari menggunakan nama-nama seperti ini. Namun, dalam beberapa kasus, nama terbaik adalah nama yang dicadangkan (seperti KEYuntuk kolom kunci dalam tabel nilai kunci umum) sehingga terserah Anda untuk memutuskan seberapa buruk Anda ingin menggunakannya (dan karenanya harus mengutipnya di mana-mana).

Saya juga menggunakan tanda kurung untuk menekan highlight biru bahwa SSMS dan VS memberikan beberapa kata kunci seperti DESCRIPTIONitu yang tidak disediakan oleh SQL Server tetapi sebaliknya khusus untuk alat-alat itu.
Jelas menggunakan tanda kurung ketika secara dinamis menghasilkan SQL. Cara mudah untuk melakukannya adalah dengan memanggil QUOTENAME()objek yang Anda referensi secara dinamis (misalnya SELECT QUOTENAME(name) FROM sys.databases;). sp_MSforeachdb, misalnya, tidak melakukan ini .

— Nick Chammas
sumber

6

Ketika saya menulis kode yang menghasilkan kode, saya meletakkan tanda kurung di sekitar nama objek database. Saya tidak menyertakan tanda kurung saat menulis kode dengan tangan, dan saya menemukan itu mengurangi dari keterbacaan kode. Saya juga melarang nama objek database dengan spasi. SQL Server akan memungkinkan Anda menggunakan spasi dalam nama objek, tetapi itu tidak berarti itu adalah hal yang baik.

— datagod
sumber

6

Saya mungkin tidak akan mencoba memiliki DDL portabel. Saya akan lebih baik jika saya menghasilkan definisi tabel Oracle dari pandangan sistem SQL Server, jika diperlukan.

Saya tidak berpikir masuk akal untuk menulis DML portabel juga - PL / SQL sama sekali berbeda dari T-SQL. Untuk portabilitas, lebih mudah untuk mengekspos database Anda melalui API prosedur yang tersimpan. Tanda tangan dari prosedur ini harus sama pada kedua platform, tetapi implementasinya dapat menggunakan fitur berpemilik - secara keseluruhan ini jauh lebih mudah daripada mencoba menggunakan hanya SQL standar ANSI.

Kesimpulan ini didasarkan pada beberapa tahun pengalaman dalam mengembangkan sistem portabel, bekerja pada Oracle dan SQL Server.

— AK
sumber