Czy są wymagane unikalne ograniczenia dla DB?

Question

Ostatnio się zastanawiałem. Powiedzmy, że robimy webapp z JSF + Spring + JPA/Hibernate (lub dowolnymi innymi technologiami) i powiedzmy, że mamy jednostkę "User". Chcemy, aby Użytkownik miał unikalny login. Jeśli chcemy to zrobić, możemy umieścić @UniqueConstraint w kolumnie "Login", ale mimo to nasza aplikacja musi podczas rejestracji użytkownika sprawdzać, czy dane wejściowe użytkownika są poprawne (unikatowe), czy nie, bez tego i tylko z ograniczeniem DB po prostu dostaniemy błąd. To sprawiło, że myślę, czy ograniczenia DB są naprawdę potrzebne/pomocne? Mogę tylko pomyśleć, kiedy dadzą nam jakieś korzyści, gdy ktoś spróbuje nas zhakować (ale myślę, że nasza aplikacja powinna być odporna na wstrzykiwanie SQL) lub staramy się ręcznie zmienić zawartość DB (która nie powinna naprawdę się stało). Właściwie teraz, kiedy o tym myślę, czy ograniczenia DB są w zasadzie konieczne/dobre praktyki? Podobnie jak długość łańcucha itp

Answer 1

Dla mnie kategorycznie tak, patrz Database as a Fotress Dan Chak od 97 Myśli Każdy Software Architect powinien wiedzieć. Mówi o wiele lepiej niż ja.

Answer 2

Tak, są. Wymuszają integralność danych na najniższym poziomie.

może chcesz ręcznie zmienić zawartość DB (czyli uaktualnienia do nowej wersji)

Możecie zapomnij sprawdzić niektóre ograniczają w kodzie.

Możesz na to patrzeć jak sprawdzanie poprawności klienta/serwera. Twój program to klient, db to serwer. Głównie sprawdzanie poprawności klienta jest wystarczające, ale musisz mieć walidację serwera, na wypadek gdyby coś poszło nie tak.

Answer 3

Myślę, że osoba danych powiedziałaby, że oba są absolutnie niezbędne. Twoje pytanie zakłada, że ​​twój kod aplikacji warstwy pośredniej będzie znajdować się przed tą bazą danych teraz i na zawsze.

Prawda jest taka, że ​​aplikacje na poziomie średnim przychodzą i odchodzą, ale dane na zawsze.

Nie ma uciec od długości kolumn w projekcie schematu. Sądzę, że pytasz, czy dobrym ćwiczeniem dla środkowego poziomu jest ich egzekwowanie. Może nie, ale są kluczem do bazy danych.

Answer 4

Często, gdy zadeklarujesz, że zestaw kolumn ma być unikalny, jest to coś, o co będziesz chciał zapytać - więc najprawdopodobniej powinno być ono zindeksowane.

Tak, twoje zgłoszenie powinno wykonać odpowiednie sprawdzenie, ale co zrobić, jeśli błąd się zepsuł? Jeśli twoja baza danych wie, że coś ma być unikalne, przynajmniej wiesz, że nie będziesz przechowywać nieprawidłowych danych (lub nie "źle" nieprawidłowych danych, takich jak duplikaty danych, które mają być unikatowe). W każdym razie możesz zadać przeciwne pytanie: ile to kosztuje?

Answer 5

Ograniczenia, zarówno unikalne, jak i obce, nie tylko egzekwują integralność danych, ale mają wpływ na wydajność. Bez znajomości tych "nieformalnych" stałych, optymalizatorzy bazy danych podejmą nieprzewidywalne decyzje dotyczące sposobu wykonywania wyciągów.

Answer 6

Jeśli chcesz mieć złe dane, usuń unikalne ograniczenia z bazy danych. Pracowałem z bazami danych od lat 70. ubiegłego wieku i przeszukałem lub zaimportowałem dane przechowywane w setkach baz danych. Nigdy nie widziałem dobrych danych w bazach danych, w których ograniczenia są nieprawidłowo ustawione na poziomie aplikacji. Wiele rzeczy innych niż aplikacja trafia do bazy danych (import z innych systemów, szybka aktualizacja danych prod w celu naprawienia problemu z danymi uruchamianego z okna zapytania, innych aplikacji itp.). Wiele razy aplikacja jest zastępowana, a ograniczenia są tracone.

Answer 7

ale nasza aplikacja musi sprawdzić podczas rejestracji użytkownika, czy wejście użytkownik jest ważna (niepowtarzalny), czy nie, bez tego i tylko z DB przymusu będziemy po prostu pojawia się błąd .

To najzabawniejsza rzecz, jaką kiedykolwiek czytałem. Po prostu pojawia się błąd? To naprawdę wszystko czego potrzebujesz? Czy kiedykolwiek słyszałeś o pułapce błędów? Spróbuj Catch ring dzwonki?

W rzeczywistości aplikacja jest bardzo kontrowersyjna, aby "sprawdzić". Baza danych będzie sprawdzać w każdym razie na ograniczeniu, więc dlaczego robi to dwa razy. Aplikacja powinna po prostu wstawić wiersz, jakby wszystko było w porządku. DB sprawdzi wyjątkowość i zgłosi błąd w przypadku awarii ... Twoja aplikacja powinna POŁOŻYĆ ten błąd i zrobić to, co robiłeś w ramach istniejącego czeku.

Answer 8

Tak. Po prostu złap błąd naruszenia klucza, a ograniczenie kluczowe wykona pracę za Ciebie bez konieczności ponoszenia dodatkowych kosztów dodatkowego sprawdzenia.