SSMS zezwala na zduplikowane rekordy w tabeli, ale nie na kolejne aktualizacje

Edytuj: Kiedy mówię „SQL Server”, naprawdę mówię o Management Studio. Przepraszam, jeśli to było mylące.

Och, nienawidzę, gdy takie rzeczy się zdarzają. Pracowałem wczoraj z SQL Server i wypróbowałem komendę PIVOT, aby dowiedzieć się, jak to działa. Dlatego utworzyłem nową tabelę z czterema kolumnami, a pierwsza kolumna będzie miała tę samą wartość dla pierwszych kilku wierszy.

Dodałem „value1” do pierwszego wiersza, pierwszej kolumny i nacisnąłem enter - sinus, nie dodano jeszcze żadnych kluczy ani ograniczeń, pozwoliło mi to na przejście do następnego wiersza z NULL dla innych kolumn w pierwszym wierszu (czyli w porządku). Ku mojemu zdziwieniu, pozwoliło mi to również wpisać „value1” w drugim rzędzie i wejść - to powinno być niemożliwe, ponieważ teraz są dwa identyczne rzędy. Jednakże, ponieważ właśnie się bawiłem, nie przeszkadzało mi to. Dlatego rozpoczynam tworzenie czterech wierszy jako takich:

Tabela 1

Col1       Col2      Col3     Col4
---------------------------------
Value1     NULL      NULL     NULL
Value1     NULL      NULL     NULL
Value1     NULL      NULL     NULL
Value1     NULL      NULL     NULL

Oczywiście jest to dziwne i przełamuje teorię relacyjną, ale tak naprawdę nie obchodziło mnie to, ponieważ jest to tylko stół, który stworzyłem, żeby się z nim bawić. Jednak właśnie wyciągnąłem włosy z tego, co stało się później. Po tym, jak miałem te dane, nie mogłem tego zrobićbyle co na stół. Gdybym próbował wypełnić col2, col3 lub col4 na którymkolwiek z wierszy, SQL Server krzyczałby na mnie, że ma zduplikowane wiersze: „Nie zaktualizowano wiersza. Dane w wierszu 1 nie zostały zatwierdzone .... Wartość wiersza zaktualizowane lub usunięte albo nie powodują, że wiersz jest unikalny, albo zmieniają wiele wierszy (4 wiersze). ”

Innymi słowy, SQL Server pozwolił mi wejść w zduplikowanych wierszach, ale gdy próbowałem zaktualizować wiersze, aby były unikatowe, nie pozwoliło mi, powołując się na powielone wiersze. Najgorsze jest to, że nie mogłem nawet usunąć żadnych wierszy (otrzymuję ten sam komunikat o błędzie). Jedynym rozwiązaniem, które znalazłem w tym scenariuszu, było usunięcie tabeli i rozpoczęcie od nowa - co jest śmieszne.

Moje pytanie brzmi: w jaki sposób takie zachowanie może istnieć w dobrze znanym programie, który ewoluował przez dekadę? Czy to ja jestem bezmózgowy i powinienem zaakceptować zachowanie SQL Server? Dla mnie jest to niedopuszczalne i SQL Server nigdy nie powinien pozwolić mi na wprowadzanie zduplikowanych wierszy w pierwszej kolejności lub powinien umożliwiać mi aktualizację zduplikowanych wierszy, aż wszystkie będą unikalne, a następnie spróbują zapisać.

Nie jest to w żaden sposób przeznaczone na post z nienawiścią do SQL Server. Stosunkowo rzadko spotykam się z takim zachowaniem, ale kiedy to robię, może mnie to naprawdę powstrzymać i doprowadzać do szału. Po prostu nie rozumiem, dlaczego program ma tak wbudowane zachowanie. Na przykład, dlaczego na świecie pozwolono mi wejść do zduplikowanych wierszy w pierwszej kolejności, jeśli nie chciałem pozwolić mi to naprawić?

Pamiętam pracę z MS Access w tamtym dniu i wpadłem na ten sam rodzaj dziwnych, archaicznych zachowań. Kilka razy musiałem skopiować ogromne ilości danych, odtworzyć tabelę i skopiować ją z powrotem, ponieważ program Access pozwolił mi zrobić coś, czego nie powinien mieć, a teraz blokuje mi wszelkie zmiany, aby to naprawić - efektywne wywołanie impasu.

Więc o co tu chodzi? Czy potrzebuję jakiejś zmiany paradygmatu podczas zbliżania się do SQL Server? Czy to ja, czy SQL Server, to jest problem? (Możesz powiedzieć, że to ja, mogę to wziąć.)

questionAnswers(4)

yourAnswerToTheQuestion