Tüm sütun harmanlamalarını veritabanında varsayılan olarak tutma önerisi bana daha çok yönergeler veya en iyi uygulamalar gibi görünüyor.
Burada tamamen haklısın.
Neden bazıları tarafından bu kadar ciddi bir hata olarak kabul edilir?
Aynı nedenle sık sık " asla kullanmamalısınız " ifadesini duyarsınız / okursunuz.
- imleçleri
GOTO ifadeleri- SQLCLR
WITH (NOLOCK)- vs, vs, vs
Bazı özellikler / seçenekler / teknolojiler diğerlerinden daha karmaşıktır ve genellikle kullanıcı tarafından daha fazla bilgi gerektirir, çünkü kullanırken sorun yaşama şansı, herhangi bir sorun yaşama şansından çok daha yüksektir. Dolayısıyla, genel nüfus için bu tür şeylere karşı genel kurallara sahip olmak daha kolaydır. Aslında, "Kodlama Standartları" nı iş yerinde yazarken, aslaCURSOR'ları kullanıyorum, fakat onları kendim kullanıyorum çünkü hem "ne zaman" kullanacağımı hem de onları etkili bir şekilde nasıl kullanacağımı biliyorum. Ancak yalnızca ara sıra sorgu yazan kişilerden bunu bilmeleri beklenmemelidir. Bu aynı zamanda, "ne yaptığınızı kesinlikle bilmediğiniz sürece Kayıt Defterini düzenlemeyin" veya (çok küçük) çocuklarımız için ebeveyn olarak yaptığımız kurallara benzer. belirli bir şeyi yapmanın ne zaman uygun olduğu ya da nasıl yapılacağı konusunda karmaşıklıkları aşamayan.
Harmanlama durumunda, bu çok karmaşık ve kafa karıştırıcı bir konudur ve her iki sabit hata ile de karşılaşabilirsiniz (bunlar bir sorundur, ancak açık ve dolayısıyla düzeltilmesi yeterince kolay olduğundan) daha az sorun olabilir. bir şeyin neden olduğu gibi davrandığını açıklamanın zor olduğu davranışlar (bazı öğeler neden beklentilerin dışında filtrelenir veya filtrelenmez VEYA sıralama neden beklentilerin dışında hareket eder). Ve ne yazık ki, etrafında toplu karışıklık yaratan oldukça büyük miktarda yanlış bilgi var gibi görünüyor. Aslında Harmanlama ve kodlamalar, vb genel bilgi büyük ölçüde artırmak için bir proje üzerinde çalışıyorum ve umarım yanlış bilgi ve mitleri karşı koymak, ama henüz yayınlamak için hazır değil (bittiğinde bunu bir bağlantı ile güncelleyeceğim).
Harmanlama için, iş durumu için en anlamlı olanı kullanmanız gerekir. Harmanlamaları bir tablo veya veritabanında karıştırmama kavramı varsayılan bir yaklaşımdır, ancak sistem kataloğu görünümlerinin çeşitli sütunları için kullanılan Harmanlamalara bakarsanız, çeşitli Harmanlamaların kullanıldığını göreceksiniz. Bu yüzden, Harmanlamalar farklı olacaksa, kasıtlı olmalı, ancak doğal olarak yanlış olan hiçbir şey olmadığı sorusundaki ana alıntıya katılıyorum.
Soruyla ilgili olarak (vurgu eklendi):
Octopus Deploy Sunucusu yapılandırılırken, OctopusServer örneğinin başlatılması sırasında kurulum bir FATAL hatasıyla başarısız olur. Hata iletisiyle ilgili makale bunun neden bir gereklilik olduğunu açıklamıyor
Bağlantılı dokümantasyon sayfasını kontrol ettim ve bunun neden bir gereklilik olduğunu açıklıyor. İlgili bilgileri aşağıdaki belgelerden kopyaladım:
Ahtapot Veritabanındaki tüm nesnelerin harmanlamasını da değiştirdiğinizden emin olmalısınız, aksi takdirde Ahtapot sürüm yükseltmeleri sırasında veritabanını değiştirirken hatalar oluşabilir. Oluşturulan yeni nesneler güncellenmiş harmanlamayı kullanır ve orijinal harmanlamayı kullanarak bunlar ve mevcut nesneler arasında SQL birleşimleri yapmaya çalışırken (örneğin) harmanlama yanlış eşleşme hataları oluşabilir.
Ahtapot veritabanındaki kodlarının dize sütunları arasında JOIN'leri olduğunu ve gelecekteki bir yükseltmede yeni dize sütunlarında ek JOIN'ler bulunan yeni bir kodun eklenebileceğini söylüyorlar . CREATE TABLEVeya yoluyla yeni sütunlara, ALTER TABLE ... ADDveritabanının varsayılan Harmanlaması atanırsa,COLLATEyeni dize sütun (lar) ı için anahtar kelime belirtilmedi. Ve aynı harmanlama içermeyen dize sütunları arasında JOINs bir harmanlama uyuşmazlığı hatası oluşturur. Ayrıca, kullanıcının kendi Harmanlamasını seçmesine izin veriyor gibi görünüyorlar (muhtemelen farklı yerel ayarları barındırmak için) çünkü üstte tek gereklilik Harmanlama'nın büyük / küçük harfe duyarsız olduğunu söylüyorlar. Ve kodlarının içinde bulunduğu veritabanının Harmanlanması her zaman aynı olacağından emin olmadığı için COLLATE, aynı Harmanlamayı tüm yeni dize sütunlarında zorlamak için kullanamazlar (teknik olarak yapabilirler, ancak bu Dinamik gerektirir) SQL, güncelleme komut dosyaları oluştururken uğraşmak o kadar kolay değildir). Kullandıkları mümkün olsaydı COLLATEanahtar kelime, o zaman olabilirVeritabanı varsayılan harmanlama dize sütunlarından farklı olması ile kurtulmak. Bu zor "Harmanlama uyuşmazlığı" hatalarını önleyecektir, ancak yine de bu dize sütunlarından birini ve bir dize değişmez veya değişkenini içeren karşılaştırma işlemleri olasılığını açık bırakacaktı. Harmanlama. Tabii ki, bu beklenen davranış çok iyi olabilir. Ancak bu bir üçüncü taraf uygulaması olduğundan, davranış, a) kullanıcının istediği (veya itiraz etmediği) ve b) kullanıcının bir hatayı düşündüğü (ve sonra) arasındaki 50/50 şans yerine amaçladıkları şey olmalıdır. satıcının vahşi kaz kovalamaca ve / veya yazılımlarının nasıl buggy olduğu ile ilgili bloglarda destek süresini boşa harcar).