Zalecenie, by wszystkie ustawienia kolumn były domyślnie ustawione w bazie danych, wydaje mi się bardziej wytycznymi lub najlepszymi praktykami.
Masz całkowitą rację tutaj.
Dlaczego niektórzy uważają to za tak poważny błąd?
Z tego samego powodu, dla którego często słyszysz / czytasz, że „ nigdy nie należy używać:”
- KURSORZY
GOTO sprawozdania- SQLCLR
WITH (NOLOCK)- etc, etc, etc
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):
Podczas konfigurowania serwera Octopus Deploy Server instalacja kończy się błędem FATAL podczas inicjowania instancji OctopusServer. Artykuł dotyczący komunikatu o błędzie nie wyjaśnia, dlaczego jest to wymóg
Sprawdziłem link do strony z dokumentacją i rzeczywiście wyjaśnia, dlaczego jest to wymaganie. Skopiowałem odpowiednie informacje z poniższej dokumentacji:
Musisz również zmienić sortowanie wszystkich obiektów w bazie danych Octopus, w przeciwnym razie mogą wystąpić błędy podczas modyfikowania bazy danych podczas aktualizacji wersji Octopus. Nowe utworzone obiekty będą korzystały ze zaktualizowanego sortowania, a przy próbie (na przykład) łączenia SQL między tymi i istniejącymi obiektami przy użyciu oryginalnego sortowania mogą wystąpić błędy niezgodności zestawień.
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 TABLElub ALTER 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).