Rekomendasi untuk menjaga semua kumpulan kolom ke database default sepertinya lebih seperti pedoman atau praktik terbaik bagi saya.
Anda sepenuhnya benar di sini.
Mengapa itu dianggap kesalahan serius oleh sebagian orang?
Untuk alasan yang sama Anda akan sering mendengar / membaca bahwa "Anda tidak boleh menggunakan:"
- CURSOR
GOTO pernyataan- SQLCLR
WITH (NOLOCK)- dll, dll, dll
Beberapa fitur / opsi / teknologi lebih rumit dari yang lain dan umumnya membutuhkan lebih banyak pengetahuan oleh pengguna karena kemungkinan mendapat masalah saat menggunakannya jauh lebih besar daripada kemungkinan tidak memiliki masalah. Jadi, lebih mudah untuk membuat aturan umum terhadap hal-hal seperti itu untuk populasi umum. Bahkan, ketika menulis "Standar Pengkodean" di tempat kerja, saya akan selalu memiliki aturan untuk tidak pernahgunakan CURSOR, namun saya sendiri yang menggunakannya karena saya tahu "kapan" menggunakannya dan "bagaimana" menggunakannya secara efektif. Tetapi orang-orang yang hanya sesekali menulis kueri seharusnya tidak diharapkan mengetahuinya. Ini juga mirip dengan "jangan mengedit Registry kecuali jika Anda benar-benar tahu apa yang Anda lakukan", atau aturan yang kami buat sebagai orang tua untuk anak-anak kami (sangat muda) di mana kami perlu memberi tahu mereka untuk tidak melakukan sesuatu hanya karena mereka tidak mampu melintasi kompleksitas ketika boleh melakukan hal tertentu atau bagaimana melakukannya.
Dalam kasus Collations, ini adalah topik yang sangat kompleks dan membingungkan, dan Anda dapat mengalami kedua kesalahan tersebut (ini adalah masalah tetapi lebih sedikit masalah karena jelas dan karenanya cukup mudah untuk diperbaiki) dan menjadi "aneh" perilaku di mana sulit untuk menjelaskan mengapa sesuatu bertindak seperti itu (mengapa beberapa item difilter, atau tidak difilter, di luar harapan, ATAU mengapa penyortiran bertindak di luar harapan). Dan sayangnya, tampaknya ada sejumlah besar informasi yang salah yang melayang-layang yang semakin menambah kebingungan massa. Saya sebenarnya sedang mengerjakan sebuah proyek untuk sangat menambah pengetahuan umum tentang Collations dan encoding, dll dan mudah-mudahan menangkal kesalahan informasi dan mitos, tetapi belum siap untuk merilisnya (ketika selesai saya akan memperbarui ini dengan tautannya).
Untuk Collation, Anda perlu menggunakan apa yang paling masuk akal untuk kasus bisnis. Gagasan tidak mencampur Collations dalam tabel atau database adalah pendekatan default, tetapi jika Anda melihat Collations yang digunakan untuk berbagai kolom dari tampilan katalog sistem, Anda akan melihat berbagai Collations yang digunakan. Jadi saya setuju dengan kutipan utama dalam pertanyaan bahwa JIKA Collations akan berbeda, itu harus disengaja, tetapi tidak ada yang salah dengan itu.
Mengenai hal ini dari pertanyaan (penekanan ditambahkan):
Saat mengkonfigurasi Octopus Deploy Server, pengaturan gagal dengan kesalahan FATAL selama inisialisasi OctopusServer-instance. Artikel yang terkait dengan pesan kesalahan tidak menjelaskan mengapa ini merupakan persyaratan
Saya memeriksa halaman dokumentasi yang tertaut dan memang menjelaskan mengapa itu merupakan persyaratan. Saya telah menyalin info terkait dari dokumentasi di bawah ini:
Anda harus memastikan bahwa Anda juga mengubah susunan semua objek dalam Basis Data Gurita, jika tidak kesalahan dapat terjadi saat memodifikasi basis data selama pemutakhiran versi Gurita. Objek baru yang dibuat akan menggunakan collation yang diperbarui, dan ketika mencoba (misalnya) melakukan SQL joins antara ini dan objek yang ada menggunakan collation asli, collation mis-match error dapat terjadi.
Mereka mengatakan bahwa kode mereka, dalam basis data Gurita, memiliki GABUNGAN antara kolom string dan mungkin bisa memiliki kode baru yang diperkenalkan dalam peningkatan di masa depan yang memiliki GABUNGAN tambahan pada kolom string baru . Kolom baru, baik melalui CREATE TABLEatau ALTER TABLE ... ADD, akan diberi Collation default dari database jikaCOLLATEkata kunci tidak ditentukan untuk kolom string baru. Dan BERGABUNG di antara kolom string yang tidak memiliki Collation yang sama akan menghasilkan kesalahan ketidakcocokan Collation. Mereka juga tampaknya memungkinkan pengguna untuk memilih Collation mereka sendiri (mungkin untuk mengakomodasi lokal yang berbeda) karena mereka mengatakan di atas bahwa satu-satunya persyaratan adalah bahwa Collation tidak peka terhadap huruf besar-kecil. Dan karena Collation dari database tempat kode mereka tidak dijamin akan selalu sama, mereka tidak dapat menggunakan COLLATEkata kunci untuk memaksa Collation yang sama di semua kolom string baru (well, secara teknis mereka bisa, tetapi itu membutuhkan Dynamic SQL jadi tidak mudah untuk ditangani saat membuat skrip pembaruan). Jika mereka dapat menggunakan COLLATEkata kunci, maka mereka bisalolos dengan memiliki Collation default Database berbeda dari kolom string. Itu akan menghindari kesalahan "Collation mismatch" yang sulit, tetapi masih akan tetap membuka kemungkinan operasi perbandingan yang melibatkan salah satu kolom string dan string literal atau variabel yang menghasilkan perilaku "aneh" karena akan menggunakan Collation kolom dan bukan Database. Pemeriksaan. Tentu saja, itu perilaku yang bisa diharapkan. Tetapi karena ini adalah aplikasi pihak ke-3, perilaku seharusnya menjadi apa yang mereka maksudkan daripada peluang 50/50 antara a) apa yang diinginkan pengguna (atau tidak keberatan) dan b) apa yang dianggap bug oleh pengguna (dan kemudian membuang waktu dukungan vendor pada pengejaran angsa liar dan / atau blog tentang bagaimana perangkat lunak mereka buggy).