2008-10-22 12 views
20

Po prostu "migrowaliśmy" bazę danych SQL Server 2005 z DEVEL do TEST. W jakiś sposób podczas migracji zmieniono DB z nieczułego na wielkość na wrażliwy - więc większość zapytań SQL złamała się spektakularnie.Czy są korzyści z bazy danych uwzględniającej wielkość liter?

Co chciałbym wiedzieć, to - czy istnieją wyraźne zalety stosowania schematu uwzględniającego wielkość liter?

UWAGA: Mam tu na myśli nazwy tabel, nazwy kolumn, zapisane nazwy proc. Itp. NIE mam na myśli faktycznych danych przechowywanych w tabelach.

Podczas pierwszej kontroli nie mogę znaleźć ważnego powodu, który oferuje korzyści w porównaniu z niewrażliwością na wielkość liter.

Odpowiedz

12

Właśnie dowiedziałem się, dlaczego MY rozróżniamy wielkość liter. Ma to na celu zapewnienie, że kiedy wdrażamy go na stronie klienta, nasz DB działa niezależnie od tego, czy w SQL Server jest rozróżniana wielkość liter czy nie.

To jedna odpowiedź, której się nie spodziewałem.

+0

To jedyny powód, dla którego zrobimy to na pewno. – nickd

+2

Druga odpowiedź: spraw, aby połowa systemów testowych była rozróżniana, a druga połowa nieczuła. Spowoduje to wychwycenie obu klas błędów. – Darron

+0

Mamy różne sortowania serwerów na DEV i TEST. Zapewnia to, że zawsze określamy COLLATE na dowolnych tymczasowych tablicach, które tworzymy (na przykład w SProc) i dowolne formatowanie daty, które przypadkowo polega na konfiguracji serwera. – Kristen

5

Nie wszystkie sekcje kodu Unicode mają odwzorowanie bijective między dużymi i małymi literami - lub nawet dwoma zestawami przypadków.

W tych regionach "niewrażliwość na wielkość liter" jest trochę bez znaczenia i prawdopodobnie wprowadza w błąd.

To wszystko, o czym mogę teraz myśleć; w zestawie ASCII, chyba że chcesz, aby Foo i foo były inne, nie widzę sensu.

+1

Ciekawi, ile osób dowie się, co oznacza słowo bijective? :-). Ci bez podstawowej teorii mnogości/kombinatoryki znajdą się w ciemności bez Wikipedii? – Bill

1

Nieczułość przypadków jest wybawieniem, kiedy programiści nie przestrzegają żadnych konwencji podczas pisania kodu SQL lub pochodzą z języków programowania, w których niewrażliwość na wielkość jest normą, taką jak VB.

Ogólnie rzecz biorąc, łatwiej jest radzić sobie z bazami danych, w których nie ma możliwości, że ID, id i ID są odrębnymi polami.

Poza osobistymi preferencjami dotyczącymi tortur, zdecydowanie zaleca się zachowanie niewrażliwości na wielkość liter.

Jedyna baza danych, w której kiedykolwiek pracowałem, została skonfigurowana pod kątem wrażliwości na wielkość liter, to Great Plains. Zauważyłem, że pamiętam, że każda obudowa ich schematów była bolesna. Nie miałem przywileju pracy z nowszymi wersjami.

O ile nie zmieniło się i jeśli moja pamięć służy, natura wrażliwości na wielkość liter, o której mówisz, jest określana w czasie instalacji i jest stosowana do wszystkich baz danych. Tak było w przypadku instalacji programu SQL Server, na której działała baza danych Great Plains. Wspomniałem, że w przypadku wszystkich baz danych w tej instalacji rozróżniana była wielkość liter.

7

Naprawdę nie mogę wymyślić żadnego dobrego powodu, dla którego identyfikatory SQL powinny uwzględniać wielkość liter. Mogę myśleć o jednym, jednym z tych, które MySQL podaje, dlaczego w nazwach ich tabel jest rozróżniana wielkość liter. Każda tabela jest plikiem na dysku, twój system plików rozróżnia wielkość liter, a twórcy MySQL zapomnieli o table_file = lc(table_name). Jest to mnóstwo zabawy, gdy przenosisz schemat MySQL do systemu plików niewrażliwego na wielkość liter.

Mogę wymyślić jeden wielki powód, dla którego nie powinny być one wrażliwe na wielkość znaków.

Niektóre schematu autor będzie mądry i zdecydować, że this_table oczywiście oznacza coś innego niż This_Table i zrobić te dwie tabele (lub kolumny). Równie dobrze możesz napisać "wstawić tutaj błędy" w tym miejscu schematu.

Również niewrażliwość na wielkość liter pozwala wyrazić większą ekspresję w SQL, aby uwydatnić tabele i kolumny względem poleceń, nie trzymając się tego, co postanowił autor schematu.

SELECT this, that FROM Table; 
3

Większość języków tam jest wielkość liter, podobnie jak większość algorytmy porównania, większość systemów plików, itp Case niewrażliwość jest dla leniwych użytkowników. Chociaż ma tendencję do ułatwiania pisania i prowadzi do wielu wariantów tych samych nazw, różniących się tylko przypadkiem.

Osobiście między (MyTable, mojatabela, myTable, mojatabela, mojatabela, mojatabela, mojatabela), chciałbym proszę chciałbym zobaczyć jeden wersji uniwersalnej.

1

Obsługuję serwer baz danych Sybase Advantage i używa on formatu płaskiego pliku, umożliwiającego DBF, a także własnego zastrzeżonego formatu ADT. Sprawa, w której widzę wrażliwość na wielkość liter, jest problemem podczas korzystania z naszej wersji serwera na Linuksie. Linux jest wrażliwy na wielkość liter, dlatego mamy opcję w naszym db do zamawiania małych liter wszystkich połączeń. Wymaga to, aby pliki tabel były pisane małymi literami.

2

Lubię wrażliwość na wielkość liter, głównie dlatego, że do tego przywykłem z programowania w Perlu (i większości innych języków). Lubię używać StudlyCaps dla nazw tabel i wszystkich małych liter z podkreśleniami dla kolumn.

Oczywiście wiele baz danych umożliwia cytowanie nazw w celu wymuszania obudowy, tak jak robi to Postgres. Wydaje się to również rozsądnym podejściem.

1

Jestem prawie pewny, że specyfikacja SQL wymaga złożenia sprawy (która jest faktycznie taka sama jak niewrażliwość) w przypadku identyfikatorów. PostgreSQL składa się, aby zmniejszyć, ORACLE składa się do górnej.

Powiązane problemy