Kiedy przeglądam modele baz danych dla RDBMS, zwykle jestem zaskoczony, że nie znam żadnych ograniczeń (oprócz PK / FK). Na przykład wartość procentowa jest często przechowywana w kolumnie typu int(choć tinyintbyłoby bardziej odpowiednie) i nie ma CHECKograniczenia, aby ograniczyć wartość do zakresu 0..100. Podobnie w przypadku SE.SE odpowiedzi sugerujące ograniczenia sprawdzania często otrzymują komentarze sugerujące, że baza danych jest nieodpowiednim miejscem dla ograniczeń.
Kiedy pytam o decyzję o niewdrożeniu ograniczeń, członkowie zespołu odpowiadają:
Albo, że nawet nie wiedzą, że takie funkcje istnieją w ich ulubionej bazie danych. Jest to zrozumiałe dla programistów używających tylko ORM, ale znacznie mniej od DBA, którzy twierdzą, że mają ponad 5-letnie doświadczenie w danym RDBMS.
Albo że egzekwują takie ograniczenia na poziomie aplikacji, a powielanie tych reguł w bazie danych nie jest dobrym pomysłem, ponieważ narusza SSOT.
Ostatnio widzę coraz więcej projektów, w których nawet klucze obce nie są używane. Podobnie, widziałem tutaj kilka komentarzy na temat SE.SE, które pokazują, że użytkownicy nie dbają zbytnio o integralność referencyjną, pozwalając aplikacji to obsłużyć.
Pytając drużyny o wybór, aby nie używać FK, mówią, że:
Jest to PITA, na przykład, gdy trzeba usunąć element, do którego odwołują się inne tabele.
Skały NoSQL i nie ma tam obcych kluczy. Dlatego nie potrzebujemy ich w RDBMS.
To nie jest wielka sprawa pod względem wydajności (kontekst to zwykle małe intranetowe aplikacje internetowe działające na małych zestawach danych, więc nawet indeksy nie miałyby większego znaczenia; nikogo nie obchodziło by, że wydajność danego zapytania przejdzie od 1,5 s . do 20 ms.)
Kiedy patrzę na samą aplikację, systematycznie zauważam dwa wzorce:
Aplikacja prawidłowo dezynfekuje dane i sprawdza je przed wysłaniem do bazy danych. Na przykład nie ma możliwości przechowywania wartości
102jako wartości procentowej przez aplikację.Aplikacja zakłada, że wszystkie dane pochodzące z bazy danych są całkowicie poprawne. To znaczy, jeśli
102przychodzi w procentach, albo coś, gdzieś się zawiesi, albo po prostu zostanie wyświetlone tak, jak jest dla użytkownika, co prowadzi do dziwnych sytuacji.Podczas gdy ponad 99% zapytań jest wykonywanych przez pojedynczą aplikację, z czasem pojawiają się skrypty - albo skrypty uruchamiane ręcznie w razie potrzeby, albo zadania cron. Niektóre operacje na danych są również wykonywane ręcznie na samej bazie danych. Zarówno skrypty, jak i ręczne zapytania SQL mają wysokie ryzyko wprowadzenia nieprawidłowych wartości.
I tu pojawia się moje pytanie:
Jakie są powody modelowania relacyjnych baz danych bez ograniczeń sprawdzania, a ostatecznie nawet bez kluczy obcych?
To, co jest warte, to pytanie i odpowiedzi, które otrzymałem (szczególnie interesująca dyskusja z Thomasem Kilianem) skłoniły mnie do napisania artykułu z moimi wnioskami na temat ograniczeń bazy danych .