NoSQL w SQL Server

To pytanie nie dotyczy różnicy między SQL a NoSQL. Szukam jakiegoś uzasadnienia dla czegoś, co w tej chwili naprawdę nie ma dla mnie sensu (może z powodu mojego braku zrozumienia lub uznania).

Nowy projekt rozpoczęliśmy od zera przy użyciu MVC5, kodu Entity Framework 6 i SQL Server 2008. Kiedy architekt przejrzał schemat bazy danych stwierdził, że wszystkie klucze obce i inne tego rodzaju ograniczenia powinny zostać usunięte, ponieważ jest to „logika biznesowa” i należy zastosować w warstwie biznesowej kodu aplikacji.

Moim zdaniem klucze obce stanowią część integralności danych / referencji i nie naśladują logiki biznesowej. Logikę biznesową postrzegam bardziej jako proces i sprawdzanie poprawności, które kontrolują, jakie / kiedy / jak / dlaczego stosowane są referencje. Rozumiem, że wyjątkowe ograniczenia są prawdopodobnie procesami biznesowymi, ale dla mnie to tylko uzupełnia logikę i stanowi część integralności.

Drugim argumentem jest przyjęcie podejścia NoSQL do danych. Znalazłem to naprawdę niezwykłe i niekonwencjonalne: biorąc pod uwagę użycie SQL-Server 2008, potrzebę raportowania, danych nieskalowanych do terabajtów oraz brak uwzględnienia technologii takich jak Mongo, Raven itp.

Czy ktoś wcześniej spotkał się z takim scenariuszem? Dlaczego ktoś miałby stosować podejście NoSQL w SQL Server zaprojektowanym dla danych referencyjnych i nie chcieć kluczy obcych?

Podczas przeglądania schematu bazy danych stwierdził, że wszystkie klucze obce i inne tego rodzaju ograniczenia powinny zostać usunięte, ponieważ jest to logika biznesowa i należy je stosować w warstwie biznesowej.

Potem jest idiotą, a niektóre fragmenty twojej bazy kodów prawdopodobnie kiedyś trafią do The Daily WTF . Masz całkowitą rację, że jego podejście nie ma sensu, i szczerze mówiąc, nie ma też jego wyjaśnienia.

Spróbuj wytłumaczyć mu, że ograniczenia integralności referencyjnej nie są „logiką biznesową”; są standardem poprawności z własną wbudowaną weryfikacją. Logika biznesowa dotyczy tego, co robisz z danymi; integralność polega na zapewnieniu, że same dane nie są uszkodzone. A jeśli to nie zadziała ... no cóż, dowodzi. Możesz albo zastosować się do jego planu i spróbować nieco złagodzić obrażenia, albo zacząć szukać lepszego miejsca do pracy. (Lub obydwa.)

Nie mam jeszcze powodu, aby utworzyć klucz obcy

- Joel Spolsky

Oprócz ogólnych oświadczeń, warto zauważyć, że istnieją uzasadnione i mocne powody, aby nie stosować ograniczeń unikatowości lub kluczy obcych. Większość wybiera coś takiego:

• Wydajność. Wykonywanie kontroli integralności przy transakcjach atomowych nie jest bezpłatne. Często baza danych jest najtrudniejszą częścią Twojej architektury do skalowania. Być może już wykonujesz kontrole w logice aplikacji i wolałbyś nie ponieść drugiego spadku wydajności.
• Brak potrzeby. Być może twoje dane są brudne i nie masz nic przeciwko. Zależy to bardzo od tego, co robisz.

Zobacz także Co jest nie tak z kluczami obcymi?

Ale te nie pasują do przyczyn twojego pytania.

Jest to logika biznesowa i powinna być stosowana w warstwie biznesowej.

Ten powód jest nieco dziwny. Unikalność i inne ograniczenia integralności są w dużej mierze domeną bazy danych ACID. Kod aplikacji nie może zbliżyć się do gwarancji atomowości i integralności SQLServer. Jeśli potrzebujesz silnej integralności danych, głupotą byłoby zignorowanie bazy danych.

Drugim argumentem jest to, że chcą przyjąć podejście NoSQL do przechowywania danych, a więc nie chcą takich ograniczeń.

Drugi powód nie jest tak naprawdę powodem; to wniosek. Chociaż prawdą jest, że ograniczenia są kompromisem między poprawnością a wydajnością, a bazy danych NoSQL odchylają się w tym kierunku.

Być może twój architekt systemu ma na uwadze te uzasadnione powody i źle to zrozumiałeś. A może jest on bladym idiotą.

W każdym razie istnieją ważne (choć nie uniwersalne) powody, aby powstrzymywać się od używania unikatowości i ograniczeń klucza obcego.

PS Jeśli stwierdzisz, że nie chcesz kluczy obcych, nadal możesz używać relacyjnej bazy danych. Generalnie relacyjne bazy danych są bardziej dojrzałe niż ich odpowiedniki NoSQL. Jako pojedynczy węzeł mogą być nawet szybsze , a na nich można zbudować abstrakcję NoSQL .