Mendokumentasikan web raksasa prosedur tersimpan yang saling terkait dalam database MS SQL: Alat atau format apa?

Saya harap ini adalah pertanyaan dengan jawaban yang lebih pendek dari "Baca buku 1000 halaman", tetapi kemudian, jika itu situasi sebenarnya, maka pukul saya dengan itu.

Saya bukan DBA sungguhan, saya pengembang perangkat lunak yang menyadari bahwa kami membutuhkan DBA, namun toko tempat saya bekerja tidak memiliki DBA nol. Namun desain database MS SQL kami termasuk beberapa prosedur tersimpan inti, adalah kekacauan besar. Prosedur yang disimpan lambat, kami menduga mereka memiliki bug, tetapi kami bahkan tidak tahu bagaimana mereka diharapkan bekerja, jadi kami tidak tahu bagaimana cara memperbaikinya.

Sebagai permulaan, saya telah memutuskan bahwa kita akan mendokumentasikan bagaimana seharusnya semua ini bekerja, kemudian kita akan memulai pengujian unit, dan membangun serangkaian tes unit yang membantu membuktikan bahwa prosedur yang tersimpan benar-benar berfungsi. Logika yang mereka lakukan adalah bagian kunci dari aplikasi kita, bisa dibilang, ini adalah "permata mahkota" dari produk utama perusahaan kami, dan cara kerjanya benar-benar tidak berdokumen.

Saya mencari dokumentasi teknis khusus yang mungkin diharapkan DBA profesional, atau mungkin menulis sendiri, jika mereka harus, untuk memahami jaringan raksasa prosedur tersimpan yang saling memanggil.

1. Apa format yang biasa untuk mendokumentasikan prosedur tersimpan yang besar? Deskripsi nilai yang diharapkan untuk setiap Parameter Dalam (yaitu "prekondisi", "postkondisi", yaitu, untuk parameter boolean apa yang berubah ketika Anda menghidupkan atau mematikannya, dll?)

2. Bagaimana biasanya orang mendokumentasikannya? Hanya komentar SQL? Perkakas eksternal yang spesifik untuk tujuannya? "Dokumentasi" eksternal? Kami tidak memiliki alat SQL, selain studio MS SQL Management, tetapi kami bertanya-tanya apakah ada alat yang akan membuat pemahaman, dokumentasi, dan pengujian lingkungan kita lebih baik. Mungkin itu cara yang lebih baik untuk mengajukan pertanyaan saya; Alat apa yang saya butuhkan untuk menyelesaikan kekacauan kami?

Tujuan kami adalah untuk dapat:

A. Gunakan dokumentasi yang kami hasilkan, atau alat apa pun yang kami tambahkan ke lingkungan kami, untuk membantu memahami bagaimana prosedur seharusnya bekerja, sehingga kami kemudian dapat membuat cakupan uji unit untuk prosedur yang tersimpan.

B. Perlihatkan pengembang aplikasi-klien cara memanggil setiap prosedur tersimpan yang rumit ini dengan benar.

C. Unit menguji prosedur tersimpan kami.

Yang paling penting tentang dokumentasi adalah masuk akal bagi Anda. Tidak ada cara standar untuk melakukan ini.

Jika Anda memiliki banyak prosedur tersimpan yang semuanya terhubung satu sama lain dimulai dengan diagram Visio dengan satu objek untuk setiap prosedur, maka tautan di antara mereka sehingga Anda dapat melacak bagaimana hal-hal dari prosedur ke prosedur mungkin merupakan awal yang cukup baik.

Alat RedGate SQL Dependency Tracker mungkin membantu. Ini dapat menunjukkan secara grafis objek database mana (SP's / views / tables) yang saling bergantung. Saya telah menggunakannya saat bekerja dengan beberapa tabel yang saya tidak terbiasa dengan menentukan urutan untuk menonaktifkan kendala.

Saya juga menjalankannya di seluruh database hanya untuk bersenang-senang dan itu cara TMI. Jika Anda dapat memfokuskannya ke area spesifik dari DB yang tidak saling tergantung gila, mungkin akan membantu. Pohon ketergantungan memiliki opsi untuk mengatur secara visual sendiri menggunakan algoritma yang berbeda dan itu saja membuat eval berharga.

Menelusuri. Pilihan lain adalah menulis baris log pada awal dan akhir dari prosedur tersimpan yang kritis. Setiap baris dapat menyertakan tanggal, "level detail", "konteks" tebakan terbaik, "subkontek", nama proc. dan jumlah baris. Mungkin akan berantakan (pikirkan windows event log) tetapi mungkin berguna di beberapa bagian. Jika SP digunakan untuk benar-benar melakukan log insert dan kemudian dapat dinyalakan / dimatikan dengan mudah tanpa beban tambahan (ymmv).

Catatan, saya pernah memuat printer dengan kertas 11 x 17 keren, menemukan font kecil yang bagus dan beberapa lekukan logis untuk meringkas aliran kompleks data / SP ke ~ 5 halaman dari beberapa pseudo-SQL. Saya cukup yakin saya akhirnya merujuknya beberapa kali dan tidak ada yang berani mendekatinya karena tidak standar dan sulit untuk mempercayai sesuatu yang tidak terintegrasi dan bisa ketinggalan zaman. Meskipun demikian, proses dokumentasi memang sangat familiar dengan kode tersebut!

Paul White mengubah saya ke alat gratis Atlantis Schema Surf dari Atlantis Interactive, yang mungkin bisa membantu Anda.