Adakah yang bisa merekomendasikan standar pengkodean untuk TSQL?


9

Kami telah lama memiliki standar pengkodean untuk kode .Net kami, dan tampaknya ada beberapa sumber yang memiliki reputasi baik tentang cara menerapkannya yang berkembang seiring waktu.

Saya ingin dapat menyatukan beberapa standar untuk SQL yang ditulis untuk digunakan oleh produk kami, tetapi sepertinya tidak ada sumber daya di luar sana tentang konsensus untuk apa yang menentukan SQL yang ditulis dengan baik?


1
Pinal Dave memiliki daftar standar pengkodean di situsnya . Mereka terlihat seperti dasar yang adil untuk seperangkat standar.
Will A


1
@Scott yang hanya mencakup pengidentifikasian; apa-apa tentang penamaan, penggunaan kursor / prosedur tersimpan / pilihan tipe data atau apa pun yang benar-benar mempengaruhi kualitas kode ...
Rowland Shaw

1
tepatnya, maka mengapa saya mengatakan itu "terkait", bukan "duplikat".
Scott Whitlock

Jawaban:


6

Dalam pengalaman saya, hal-hal utama yang saya cari adalah:

  • Penamaan tabel dan kolom - lihat apakah Anda menggunakan ID, Referensi atau Nomor untuk kolom jenis ID, tunggal atau bentuk jamak untuk nama (bentuk jamak yang umum untuk nama tabel - misalnya THING, tunggal untuk nama kolom - misalnya THING_ID). Bagi saya hal yang paling penting di sini adalah konsistensi yang menghindari orang membuang-buang waktu (misalnya Anda tidak mengalami kesalahan ketik di mana seseorang telah menempatkan HAL sebagai nama tabel karena Anda hanya tahu secara intuitif bahwa nama tabel tidak pernah tunggal).

  • Semua ciptaan harus menyertakan setetes (tergantung pada objek yang ada) sebagai bagian dari file mereka. Anda mungkin juga ingin menyertakan izin hibah, terserah Anda.

  • Memilih, memperbarui, memasukkan dan menghapus harus diletakkan satu nama kolom, satu nama tabel dan satu di mana klausa / pesanan dengan klausa per baris sehingga mereka dapat dengan mudah berkomentar satu per satu selama debugging.

  • Awalan untuk jenis objek khususnya di mana mereka mungkin bingung (jadi v untuk tampilan menjadi yang paling penting). Tidak yakin apakah itu masih berlaku tetapi dulu tidak efisien untuk prosedur tersimpan selain prosedur sistem untuk memulai sp_. Mungkin praktik terbaik untuk membedakannya toh usp_ adalah apa yang saya gunakan paling baru.

  • Standar yang menunjukkan bagaimana nama pemicu harus mencakup apakah itu untuk pembaruan / masukkan / hapus dan tabel yang berlaku. Saya tidak memiliki standar yang disukai tetapi ini adalah informasi penting dan harus mudah ditemukan.

  • Standar untuk kepemilikan objek dalam versi SQL Server sebelumnya atau skema yang seharusnya ada pada 2005 dan kemudian. Ini panggilan Anda apa adanya, tetapi Anda tidak boleh menebak siapa yang memiliki sesuatu / tempat tinggalnya) dan jika memungkinkan skema / pemilik harus dimasukkan dalam skrip CREATE untuk meminimalkan kemungkinan pembuatannya secara salah.

  • Indikator bahwa siapa pun yang menggunakan SELECT * akan diminta untuk minum satu liter air seni mereka sendiri.

  • Kecuali ada alasan yang sangat, sangat bagus (yang tidak termasuk kemalasan di pihak Anda), miliki, tegakkan, dan pertahankan hubungan kunci utama / kunci asing sejak awal. Bagaimanapun, ini adalah basis data relasional, bukan file datar dan catatan yatim piatu yang akan membuat kehidupan dukungan Anda seperti neraka di beberapa titik. Perlu diketahui juga bahwa jika Anda tidak melakukannya sekarang saya bisa menjanjikan Anda Anda tidak akan pernah berhasil menerapkannya setelah acara karena ini 10 kali pekerjaan setelah Anda memiliki data (yang akan sedikit kacau karena Anda tidak pernah memaksakan hubungan dengan benar).

Saya yakin saya telah melewatkan sesuatu tetapi bagi saya merekalah yang sebenarnya menawarkan manfaat nyata dalam sejumlah situasi yang layak.

Tetapi seperti semua standar, lebih sedikit lebih banyak. Semakin lama standar pengkodean Anda, semakin kecil kemungkinan orang untuk membaca dan menggunakannya. Setelah Anda melewati beberapa halaman dengan spasi baik mulai mencari untuk menjatuhkan hal-hal yang tidak benar-benar membuat perbedaan praktis di dunia nyata karena Anda hanya mengurangi kemungkinan orang melakukan hal itu.

Sunting: dua koreksi - termasuk skema di bagian kepemilikan, menghapus tip yang salah tentang hitungan (*) - lihat komentar di bawah.


1
Beberapa pilihan aneh ... "SELECT COUNT (*)" buruk? Pernah mendengar tentang skema (yang tidak sama dengan pemilik)? Yang lainnya baik
gbn

1
@ Jon Hopkins - Saya tahu mengapa itu buruk untuk menggunakan SELECT *. Alangkah baiknya jika Anda bisa mengatakan mengapa menggunakan SELECT COUNT (*) itu buruk.
k25

1
@ gbn @ k25 - Beberapa tahun yang lalu (2002?) Saya punya DBA yang sangat panas dalam hitungan (*) tetapi Googling menanggapi pertanyaan Anda, sepertinya ini sudah ketinggalan zaman (jika memang benar). sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (Diperlukan Registrasi). Dia terutama Oracle DBA sehingga mungkin masalah asli di sana yang dia anggap juga masalah untuk pengoptimal SQL.
Jon Hopkins

1
@ GBN - Ya saya punya, meskipun saya sudah relatif lepas tangan sejak diperkenalkan jadi reaksi otomatis saya adalah pengguna. Saya akan memperbarui jawaban untuk menutup skema.
Jon Hopkins

1
@ gbn, @ k25 - Lebih banyak menggali tentang hitungan (*). Rupanya ini adalah masalah di Oracle 7 dan sebelumnya, diperbaiki di 8i dan seterusnya. Tidak jelas apakah itu pernah menjadi masalah dalam SQL Server tetapi tentu tidak lagi. DBA saya kedaluwarsa rasanya.
Jon Hopkins

3

tampaknya tidak ada sumber daya di luar sana pada konsensus untuk apa yang menentukan SQL ditulis dengan baik

Itu karena tidak ada konsensus. Sama seperti contoh, saya akan memiliki jawaban yang berbeda untuk setidaknya setengah dari item dalam daftar Jon Hopkins, dan berdasarkan pada jumlah detail pada daftarnya, itu adalah dugaan aman bahwa kami berdua bekerja dengan database untuk mencari nafkah.

Yang mengatakan, standar pengkodean masih merupakan hal yang baik untuk dimiliki, dan standar yang dipahami dan disetujui oleh semua orang dalam tim adalah hal yang lebih baik, karena standar itu kemungkinan besar akan diikuti.


1
+1. Saya pikir yang paling penting adalah Anda memiliki konsistensi di antara tim Anda.
Dean Harding

1
Karena minat, apa yang akan Anda lakukan secara berbeda? Apakah mereka sebagian besar masalah selera (tata letak dan sebagainya) atau apakah ada kesalahan "keras"?
Jon Hopkins

1
@ Jon: tidak ada kesalahan keras, hanya hal-hal subjektif seperti nama tabel tunggal, kebencian pemicu, dll. BTW, "SELECT *" baik-baik saja di dalam "EXISTS ()".
Larry Coleman

1
contoh yang adil (dan saya menggunakannya dengan ADA dan tidak memaksa diri untuk minum air seni).
Jon Hopkins

1

Selain jawaban Jon Hopkins ...

  • Pisahkan objek internal vs eksternal

    • IX, UQ, TRG, CK dll untuk kendala dan indeks dll
    • huruf kecil atau CapsCase untuk klien yang menghadapi mis. uspThing_Add
  • Untuk objek internal, buat mereka eksplisit jika "non default"

    • UQ = kendala unik
    • UQC = kendala berkerumun unik
    • PK = kunci utama
    • PKN = kunci primer tidak tercakup
    • IX = indeks
    • IXU = indeks unik
    • IXC = indeks berkerumun
    • IXCU atau IXUC = indeks cluster unik
  • Gunakan skema untuk menyederhanakan penamaan + izin. Contoh:

    • Helper.xxx untuk prok internal
    • HelperFn.xxx untuk udfs
    • WebGUI.xxx untuk beberapa kode yang menghadap
    • Data dan / atau Riwayat dan / atau Pementasan untuk tabel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.