NoSQL w SQL Server

28

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?

Andy Clark
źródło
21
Porozmawiaj z architektem systemu o uzasadnieniu jego porady. Albo ma bardzo dobry powód, który dotyczy twojej konkretnej sprawy (powód, którego niekoniecznie będziemy w stanie odgadnąć, nie wiedząc dokładnie, z czego składa się twoja aplikacja), albo jest po prostu niekompetentny.
Arseni Mourzenko
23
Widziałem wiele baz danych zaimplementowanych w podobny sposób: bez FK, bez ograniczeń CHECK - za każdym razem były to bazy danych zaprojektowane przez niedoświadczonych programistów, którzy nie wiedzieli nic o architekturze baz danych, integralności referencyjnej itp. Ale ważne jest, aby omówić to z twój kolega, zamiast po prostu zakładać, że jest niekompetentny.
Arseni Mourzenko
5
Jestem trochę zdezorientowany; wspominasz o użyciu frameworka Entity (najpierw kod) ... nie oznacza to, że tworzysz obiekty (w sensie C #), a następnie pozwalasz frameworkowi Entity obsługiwać tworzenie odpowiedników bazy danych, w którym to przypadku próba dodania / usunięcia FK itp. jest ćwiczenie polegające na przechytrzeniu Entity Framework (co przypomina cytat Marka Twaina o próbie nauczenia świni śpiewania?)
Foon
2
Jest zbyt wielu ludzi, którzy uważają się za „architektów”, ale tak naprawdę nie mają doświadczenia w kodowaniu lub utrzymywaniu większych systemów.
Doc Brown
2
Odpowiedni: thedailywtf.com/articles/The-Mythical-Business-Layer . „Jeśli się nad tym zastanowić, praktycznie każda linia kodu w aplikacji jest logiką biznesową”. Dotyczy to bazy danych. „Ale równie ważne jest - jeśli nie bardziej - pamiętanie, że prawie cały kod aplikacji będzie logiką biznesową. Istnieje już wystarczająca liczba narzędzi; aplikacja nie potrzebuje warstwy ogólnej ” (moje podkreślenie). Osoba polecająca to prawdopodobnie próbuje przekształcić bazę danych w jedną taką ogólną warstwę. Krótko mówiąc, najprawdopodobniej stawiają modne słowa ponad rzeczywistość.
jpmc26

Odpowiedzi:

74

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.)

Mason Wheeler
źródło
17
Miałem nieco bardziej dyplomatyczną odpowiedź, która próbowała znaleźć (rozsądny) powód, dla którego architekt mógł to robić. Po trzeźwej refleksji przystępuję do odpowiedzi.
Blrfl
7
Whoa whoa, złe próby architektury są powodem, aby pójść do pracy gdzie indziej? Cholera, nigdy nie byłbym w stanie kontynuować pracy, gdybym przyjął taką perspektywę.
Kzqai
5
@Kzqai jest też architekt, który zasadniczo nie rozumie architektury. To zaczyna brzmieć jak dyrektywa 595 i tak, jeśli ktoś chciałby mnie zmusić do użycia młotków do wkręcenia śrub w kawałek drewna, znajdę kogoś, kto nie zmusza mnie do niewłaściwego użycia narzędzi do budowy czegoś.
4
Integralność referencyjna jest głównym tematem teorii baz danych, nie wspominając już o wszystkich bazach danych, które ją obsługują w świecie rzeczywistym. Najwyraźniej współpracownik Andy'ego ma rację w swojej analizie, reszta świata akademickiego i zawodowego jest w 100% w błędzie. Punkty bonusowe za wzmiankę o Daily WTF .
2
@AndyClark Powinieneś to rzucić. Powodem jest to, że jest to nuklearna bomba zegarowa w centrum twojej firmy. To tylko kwestia czasu, kiedy kał uderza w respirator. Kiedy tak się stanie, będziesz miał szczęście pracować na 72-godzinnej zmianie, w najgorszym przypadku będziesz szukał pracy ... lepiej szukać pracy, gdy masz dochód.
ArTs
2

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 .

Paul Draper
źródło
12
Śmiem twierdzić, że Joel nie jest idiotą, ale dowcipna odpowiedź w podcastie, bez żadnego wyjaśnienia, jest, IMHO, warta nawet mniej niż oświadczenie każdego idioty.
Martin Ba
11
Joel jest facetem od arkuszy kalkulacyjnych, a nie facetem od baz danych, więc jego nieznajomość standardowych praktyk w zakresie relacyjnych baz danych nie jest chyba zaskakująca ... Bez obrazy, Joel. :-)
Eric King
3
Rzeczywisty cytat Joela to technologie, takie jak LINQ, które stanowią powód do kłopotania się z ustawieniem klucza obcego. Joel nie jest administratorem bazy danych, a od przeszukiwania swojego bloga i długoletniego czytelnika nie mogę znaleźć od niego niczego, co mówi na ten temat lub próbuje doradzić w zakresie optymalizacji baz danych, projektowania modeli danych itp. Niesamowite Joela , ale nie jest teraz ani nigdy nim nie był - ani nie twierdził, że tak jest! - ekspert w dziedzinie baz danych lub modelowania danych. To tak, jakby zacytować Einsteina na temat odsetek składanych - lub, w tym przypadku, kanapek. (Odniesienie do XKCD, nie ma za co.) :)
BrianH
4
Joel Spolsky znany jest z silnych, kontrowersyjnych opinii. Zobacz FogBugz jest napisany w zastrzeżonym języku ; Wstrzykiwanie zależności jest zbyt skomplikowane (btw, była to najbardziej kontrowersyjna odpowiedź na Stackoverflow przed zamknięciem) ; Bazy danych XML działają wolno ; itp.
BlueRaja - Danny Pflughoeft
2
@BlueRaja: Umm ... Bazy danych XML wolne, szczególnie w porównaniu z relacyjnymi bazami danych. Od kiedy to jest kontrowersyjne lub opinia?
Mason Wheeler,