Są dwa powody, dla których muszę zadać to pytanie:
tSQLt
Platforma testowa T-SQL tSQLt uważa, że jest to kwestia „wysokiego poziomu ważności”, gdy istnieją kolumny z sortowaniem innym niż domyślny. Autor testu stwierdza, co następuje:
NIE sugeruję, aby każda kolumna ciągów znaków miała sortowanie pasujące do domyślnego sortowania dla bazy danych. Zamiast tego sugeruję, że kiedy jest inaczej, powinien istnieć dobry powód.
Jednak ważność nieudanego testu jest, jak wspomniano, uważana za wysoką.
Octopus Deploy
Podczas konfigurowania serwera Octopus Deploy, instalacja kończy się niepowodzeniem z błędem FATAL podczas inicjowania instancji OctopusServer. Artykuł związany z komunikatem o błędzie-nie wyjaśnia, dlaczego jest to wymóg, ale po prostu stwierdza, że będzie to wymóg dla przyszłych wdrożeń z tym i Octopus wersji 3.8.
Na marginesie, pakiet narzędzi CI RedGate, DLM Automation Suite , obsługuje wdrożenia z różnymi zestawieniami bez reklamacji.
Zalecenie, by wszystkie ustawienia kolumn były domyślnie ustawione w bazie danych, wydaje mi się bardziej wytycznymi lub najlepszymi praktykami. Dlaczego niektórzy uważają to za tak poważny błąd?
źródło
Odpowiedzi:
Masz całkowitą rację tutaj.
Z tego samego powodu, dla którego często słyszysz / czytasz, że „ nigdy nie należy używać:”
GOTOsprawozdaniaWITH (NOLOCK)Niektóre funkcje / opcje / technologie są bardziej skomplikowane niż inne i generalnie wymagają od użytkownika większej wiedzy, ponieważ szanse na kłopoty podczas korzystania z nich są znacznie większe niż szanse na brak problemów. Łatwiej jest więc uogólnić reguły przeciwko takim rzeczom dla całej populacji. W rzeczywistości, kiedy piszę „Standardy kodowania” w pracy, zawsze będę mieć zasadę, której nigdy nie będęużywam KURSORÓW, ale używam ich osobiście, ponieważ wiem zarówno „kiedy”, jak i jak „skutecznie” z nich korzystać. Ale ludzie, którzy tylko sporadycznie piszą zapytania, nie powinni tego wiedzieć. Jest to również podobne do „nie edytuj rejestru, chyba że absolutnie wiesz, co robisz” lub zasad, które ustalamy jako rodzice dla naszych (bardzo małych) dzieci, w przypadku których musimy im powiedzieć, aby nie robili czegoś po prostu dlatego, że są nie jest w stanie przejść przez skomplikowane sytuacje, w których można zrobić coś konkretnego lub jak to zrobić.
W przypadku zestawień jest to bardzo skomplikowany i mylący temat, w którym możesz natrafić zarówno na twarde błędy (są to problem, ale mniejszy problem, ponieważ są oczywiste i dlatego łatwo je naprawić) i na „dziwne” zachowanie, w którym trudno jest wyjaśnić, dlaczego rzeczy działają tak, jakimi są (dlaczego niektóre elementy są filtrowane lub nie są filtrowane poza oczekiwaniami, LUB dlaczego sortowanie działa poza oczekiwaniami). I niestety, wydaje się, że istnieje dość duża ilość dezinformacji, która sprzyja masowemu zamieszaniu. Właściwie pracuję nad projektem, aby znacznie zwiększyć ogólną wiedzę na temat zestawień i kodowania itp. Mam nadzieję, że przeciwdziałam błędnym informacjom i mitom, ale jeszcze nie jestem gotowy, aby je opublikować (kiedy to zrobię, zaktualizuję ten link do niego).
W przypadku sortowania należy użyć tego, co jest najbardziej uzasadnione w przypadku biznesowym. Pojęcie nie mieszania zestawień w tabeli lub bazie danych jest podejściem domyślnym, ale jeśli spojrzysz na zestawienia zastosowane dla różnych kolumn widoków katalogu systemowego, zauważysz, że używasz różnych zestawień. Zgadzam się więc z głównym cytatem w pytaniu, że JEŻELI Kolacje będą inne, to powinno być celowe, ale nie ma w tym nic złego.
W związku z tym z pytania (wyróżnienie dodane):
Sprawdziłem link do strony z dokumentacją i rzeczywiście wyjaśnia, dlaczego jest to wymaganie. Skopiowałem odpowiednie informacje z poniższej dokumentacji:
Oni mówią, że ich kod w bazie Octopus ma połączenia między kolumnami smyczkowych i prawdopodobnie może mieć nowego kodu wprowadzonego w przyszłej aktualizacji, która ma dodatkowe przyłącza na nowych kolumn smyczkowych. Nowe kolumny, za pośrednictwem
CREATE TABLElubALTER TABLE ... ADD, zostaną przypisane domyślne sortowanie bazy danych, jeśliCOLLATEsłowo kluczowe nie zostało określone dla nowych kolumn ciągów. I JOIN między kolumnami łańcuchowymi, które nie mają tego samego sortowania, wygenerują błąd niezgodności sortowania. Wydaje się również, że pozwalają użytkownikowi wybrać własne sortowanie (być może w celu uwzględnienia różnych lokalizacji), ponieważ na górze mówią, że jedynym wymogiem jest, aby sortowanie nie uwzględniało wielkości liter. A ponieważ nie jest gwarantowane, że sortowanie bazy danych, w której znajduje się ich kod, nie zawsze jest takie samo, nie mogą użyćCOLLATEsłowa kluczowego do wymuszenia tego samego sortowania we wszystkich nowych kolumnach ciągów (technicznie mogą, ale wymaga to dynamiki SQL, więc nie jest łatwo poradzić sobie z generowaniem skryptów aktualizacji). Gdyby byli w stanie użyćCOLLATEsłowa kluczowego, moglibyuniknij domyślnego sortowania bazy danych innego niż kolumny ciągów. Pozwoliłoby to uniknąć poważnych błędów „niedopasowania sortowania”, ale nadal pozostawiłoby otwartą możliwość operacji porównawczych obejmujących jedną z tych kolumn łańcuchów oraz literału lub zmiennej łańcucha, co skutkowałoby „dziwnym” zachowaniem, ponieważ używałby sortowania kolumny, a nie bazy danych Porównanie. Oczywiście tego można się spodziewać. Ale ponieważ jest to aplikacja innej firmy, zachowanie powinno być zgodne z zamierzeniami, a nie 50/50 szansy między a) tym, czego użytkownik chciał (lub nie miał nic przeciwko) ib) tym, co użytkownik uważa za błąd (a następnie marnuje czas wsparcia dostawcy na pogoń za gęsią skórką i / lub blogi na temat tego, jak ich oprogramowanie jest wadliwe).źródło
Krótko mówiąc: COLLATION definiuje sortowanie i porównywanie .
Tak więc sortowanie określa zasady, których SQL Server używa do porównywania i sortowania danych znakowych. Reguły te znają język / ustawienia regionalne i mogą również uwzględniać wielkość liter, akcent, Kana i szerokość. Sufiksy sortowania identyfikują czułość reguł słownika (nie): _CS (rozróżnia małe i duże litery), _CI (nie rozróżnia wielkich i małych liter), _AS (rozróżnia małe i duże litery), _AI (niewrażliwe na duże litery) i _KS (rozróżnia małe i duże litery) Zestawienia binarne, identyfikowane przyrostkami _BIN (binarny) i _BIN2 (punkt kodu binarnego), są wrażliwe pod każdym względem.
Różne sortowania z pewnością wymagają obejścia, aby uniknąć błędów „nie można rozwiązać konfliktu kolizji” i mogą zabić wydajność ze względu na znane wyrażenia niewymienne . Radzenie sobie z różnymi zestawieniami może być koszmarem (już tam był), dlatego zalecenie, aby wybrać jeden i trzymać się go.
Więcej referencji:
źródło
Podobnie jak w przypadku wielu rzeczy, w poprzednich wersjach SQL mogło to powodować dość znaczące problemy. Zobacz ten artykuł z SQL7 / 2000
SqlServerCentral Collation
Jest teraz znacznie bardziej wytrzymały i zdarzają się sytuacje, w których jest usprawiedliwiony w nowocześniejszych systemach, ale wciąż istnieją pewne dość interesujące zastrzeżenia dotyczące jego zmiany.
Oto kolejna przydatna seria o bardziej nowoczesnych wersjach. Dan Guzman, który, jak wierzę, regularnie publikuje tutaj posty, aby wkrótce mógł zabrać głos :)
SQL Collation Hell
Krótko mówiąc, zgodność, standaryzacja i potencjalne trafienia wydajności są głównymi powodami, dla których nie należy stosować mieszanego sortowania.
źródło
Przesyłanie danych między zestawieniami może zmienić dane, jeśli są one char (tekst 8-bitowy) zamiast nchar (16-bit).
Sądzę, że z tej strony https://the.agilesql.club/blogs/Blogs/Ed-Elliott/What-collation-variables-take-on-inT-SQL, że gdy zmiennej jest przypisany tekst z tabeli, to jest to domyślnie przetłumaczone na / traktowane jako zestawienie bieżącej bazy danych. Ale co dzieje się z tekstem w zmiennej po przejściu do innej bazy danych? Czy te bajty są ponownie tłumaczone (jeśli jest to wymagane) do nowego sortowania?
Wziąłem sztuczkę sortowania, aby usunąć akcenty literowe „łacińskie” i zostawić tylko tekst ASCII, czego potrzebowałem, ponieważ nasze oprogramowanie zewnętrzne dusiło akcenty - umieściłem tekst w zestawieniu zawierającym tylko ASCII i współczesny alfabet grecki;
Collate SQL_Latin1_General_CP1253_CI_AI. „Slán” akcentuje rzymskie litery! ;-)Ale złe wieści, gdybym chciał je zatrzymać!
źródło