Ograniczenia w relacyjnych bazach danych - dlaczego nie usunąć ich całkowicie?

20

Czy istnieje obecnie jakiś powód do budowania ograniczeń między tabelami (wewnątrz serwera SQL)? Jeśli tak, to kiedy? Większość aplikacji w moim obszarze opiera się na zasadach obiektowych, a tabele są łączone na żądanie. Zapotrzebowanie jest oparte na zapotrzebowaniu aplikacji. Nie załaduję zestawu ograniczonych tabel do prostego wyszukiwania, które z kolei (po akcji) wymagają kolejnego prostego wyszukiwania.

Narzędzia ORM, takie jak EntityContext, Linq2Data, NHibernate, same obsługują ograniczenia, przynajmniej wiesz, jakie tabele potrzebują się wzajemnie. Czy ograniczanie wewnątrz serwera polega na dwukrotnym wprowadzaniu (wymuszaniu) tych samych zmian?

Zwykle nie jest to kwestia do podjęcia decyzji, ale ta baza danych jest zaprojektowana zupełnie inaczej. Projekt wygląda normalnie dobrze, głównie odzwierciedlał obiekty używane przez aplikacje. To, co mnie niepokoi, to wszystkie ograniczenia skonfigurowane wewnątrz SQLserver z „not cascade”. Co oznacza, że ​​podczas kodowania nowych zapytań do bazy danych musisz grać „szukaj i znajdź”. Niektóre przypadki wymagają do 10 poziomów dokładnej kolejności, aby wykonać jedno usunięcie.

To mnie zaskakuje i nie jestem pewien, jak sobie z tym poradzić.

W moim prostym świecie takie ustawienie sprawia, że ​​ograniczenia tracą większość celu. OK, jeśli baza danych była dostępna z hostów bez znajomości projektu.

Jak postąpiłbyś w tym scenariuszu?
Dlaczego nie usunąć wszystkich ograniczeń z bazy danych i utrzymać je na poziomie aplikacji?

Niezależny
źródło
6
Planowałeś zawsze uzyskiwać dostęp do danych za pomocą jednego narzędzia ORM? A może planujesz „zabawną” replikację wszystkich ograniczeń we wszystkich używanych narzędziach ORM?
Donal Fellows
1
Na mój ostatni komentarz do Petera muszę się zgodzić. Punkt polegający na oparciu wszystkich ograniczeń bazy kodu (i usunięciu ich z bazy danych) był bardzo wąski i prawdopodobnie w pełni można go zastosować do aplikacji krótkotrwałych. Prawdopodobnie również dla niektórych deweloperów / projektów RAD.
Niezależny
4
Drobny nitpick: Myślę, że staje się nieco mylące, gdy nazywasz połączenia klucza obcego między tabelami „relacjami”. „Relacje” w relacyjnej bazie danych to same tabele, a nie połączenia. Zwłaszcza, gdy mówimy dalej o „projektowaniu relacyjnym” - czy to oznacza tabele, czy może klucze obce?
Thomas Padron-McCarthy
Dzięki. Nazywam „połączenia między tabelami” dla ograniczeń. Stąd prawdopodobnie masz rację, że widzę „relacyjną bazę danych” dla zasad projektowania tabel (struktura tabel). Jeszcze bardziej precyzyjnym opisem byłby „wzorzec projektowy” w odniesieniu do bazy danych „relacja kontra obiekt”.
Niezależny
1
Twoja baza danych przeżyje kod aplikacji. Ponadto ORM szkodzi wydajności aplikacji i istnieje duża szansa, że ​​w końcu zechcesz ją ominąć, przynajmniej w niektórych przypadkach użycia. Jeśli teraz tego nie wiesz, w końcu się dowiesz. samsaffron.com/archive/2011/03/30/… . Ponadto usunięcie wszystkich ograniczeń pozostawia bazę danych całkowicie niezdolną do ochrony własnej integralności, gdy jest ona nadużywana przez aplikacje inne niż Twoja, co może być czymkolwiek - od innej faktycznej aplikacji po exec w korytarzu z Excelem.
Craig,

Odpowiedzi:

46

Dwa ogólne powody, dla których nie należy usuwać ograniczeń z bazy danych :

  • Dostęp do niego mogą uzyskać więcej aplikacji, teraz lub w przyszłości , które mogą korzystać z ORM. Nawet jeśli twórcy tych aplikacji wiernie powielają wszystkie istniejące tam ograniczenia (co może być znacznie trudniejsze przy użyciu niższych poziomów rozwiązań innych niż ORM), zawsze jest to dodatkowa praca. A jeśli nie, wystarczy jedno małe pominięcie, aby złamać integralność schematu ... czego nie chcesz ryzykować. W większości firm dane przechowywane w ich bazie danych są siłą napędową ich działalności, więc ich integralność musi być zapewniona w dowolny sposób. A wypróbowanym i sprawdzonym najlepszym sposobem osiągnięcia tego jest wdrożenie jak największej liczby ograniczeń w DB.
  • Optymalizator zapytań w dużej mierze opiera się na ograniczeniach znanych na poziomie bazy danych. Jeśli usuniesz ograniczenia, wydajność zapytania może zacząć się pogarszać . Możesz nie zauważyć tego od razu, ale któregoś dnia cię uderzy, a wtedy może być już za późno, aby to łatwo naprawić. Rzeczy polegają na tym, że wydajność DB ma tendencję do załamania w szczytowym czasie obciążenia, gdy jest najmniejsza możliwość dokonania ostrożnych, przemyślanych ulepszeń projektu, popartych dokładnymi pomiarami wydajności i szczegółową analizą w celu ustalenia przyczyn.

Twój konkretny przypadek brzmi, jakby schemat DB mógł zostać pierwotnie wygenerowany przez narzędzie ORM (lub zaprojektowany przez osobę niezbyt doświadczoną w świecie relacyjnym), więc jest on nieoptymalny z relacyjnego punktu widzenia. Prawdopodobnie lepiej jest go przeanalizować i ulepszyć w kierunku bardziej „naturalnego” projektu relacyjnego, zachowując przy tym spójność z widokami ORM. Przydatne może być zaangażowanie eksperta DB w tę analizę.

Péter Török
źródło
5
@Jonas, następnie porozmawiaj z facetem o spostrzeżonych problemach z jego projektem DB. Relacyjne i zorientowane obiektowo to dwa różne światy - żaden z nich nie jest „poprawą” w stosunku do innych per se i oba mają swoje miejsce. Projektowanie aplikacji C # na zasadach relacyjnych jest równie dużym błędem, jak projektowanie DB w sposób OO.
Péter Török
3
@Jonas, odzwierciedlając twoje aktualizacje: jeśli musisz pisać zbyt skomplikowane zapytania, aby osiągnąć pozornie proste rzeczy w stosunku do schematu DB, jest to albo znak, że projekt DB jest nieodpowiedni do swoich celów - albo że nie masz wystarczających umiejętności (proszę nie obrażaj się, z twojego postu nie wynika, jak bardzo masz doświadczenie w SQL. Jako wyłączenie odpowiedzialności sam nie jestem ekspertem.)
Péter Török
1
Prawdopodobnie mam kilka wyrażeń do nauczenia się, aby stać się zauważalnym :). Przeczytałem ponownie pytanie i odpowiedzi i muszę cofnąć. Zdecydowanie mocną stroną jest DB jako wzorzec dla wszystkich ograniczeń. Wszystkie systemy muszą być zaprojektowane od tego. Bardzo wąski pogląd, by stwierdzić, że baza kodu wykona pracę. Jeśli każdy system może podjąć własną decyzję o ograniczeniach, zakończy się to wysoką apelacją ze źle sugerowanymi relacjami i osieroconymi całymi tabelami. Jeśli nie teraz, nastąpi to później z innymi programami kodującymi.
Niezależny
8
„Dostęp do niej mogą uzyskać kolejne aplikacje, teraz lub w przyszłości.” Nie wspominając o tym, że administrator bazy danych uruchamia surowe zapytania SQL, aby rozwiązać problem z bazą danych, podczas gdy użytkownicy czekają ...
Thomas Padron-McCarthy
5
+1: jeśli db przechowuje dane biznesowe (nie tylko konfigurację aplikacji itp.), Prawdopodobieństwo, że baza danych zostanie uruchomiona / zostanie przedłużona poza bieżącą aplikację, zbliża się do 100%
Binary Worrier
27

Aplikacje mogą przychodzić i odchodzić, ale dane żyją wiecznie. W mojej firmie DB ma ponad 30-40 lat i będzie istniał tak długo, jak długo firma będzie istnieć. Aplikacje się zmieniają, programiści przychodzą i odchodzą. Lepiej jest mieć integralność i dobry logiczny model danych. W ten sposób ktoś może spojrzeć na dane i uzyskać zrozumiałe zrozumienie bez konieczności przechodzenia przez złożoną bazę kodu. Pomaga to również znacznie w raportowaniu. Również aplikacje mogą i będą mieć błędy, a ograniczenie DB jest przed tym zabezpieczeniem. Moja domyślna pozycja to mieć jak najwięcej ograniczeń (FK i czek).
Jedynym powodem, dla którego nie ma ograniczenia, jest to, że wzorzec projektowy na to nie pozwala, np . Problemy z tabelą hierarchii lub wydajnością.

softveda
źródło
Powiem, że robisz tu bardzo mądrą radę. Moim zdaniem może lepiej pasować do rozwoju RAD lub cokolwiek rozwijającego się, w którym aplikacje mają krótki okres użytkowania - tylko ze względu na minimalizację konserwacji podczas programowania.
Niezależny
15

To, co mnie niepokoi, to wszystkie ograniczenia skonfigurowane wewnątrz SQLserver z „not cascade”.

Nie przeszkadza mi to, to znaczy, że ktoś wykazał się zdrowym rozsądkiem. Kaskadowe usuwanie jest często bardzo niekorzystne dla bazy danych. Po pierwsze, czasami chcesz, aby usunięcie nie powiodło się, jeśli masz dane w powiązanych tabelach. Na przykład, jeśli masz klienta, który ma zamówienie w przeszłości, nie chcesz, aby został usunięty lub stracisz dane o tym, dla kogo było zamówienie, a kaskadowe usunięcie spowoduje usunięcie rekordu, który zepsułby Ci raportowanie finansowe .

Wydaje ci się, że łatwość rozwoju jest najważniejsza. W świecie baz danych jest to po prostu nieprawda. Integralność danych jest pierwszą najważniejszą rzeczą, po której następuje wydajność i bezpieczeństwo danych. Jeśli pisanie zapytań zajmuje więcej czasu, niech tak będzie.

Na bazę danych zwykle działa wiele aplikacji = jedna lub więcej witryn internetowych lub aplikacji komputerowych, aplikacja raportująca, usługi sieciowe, okno zapytań, procesy ETL itp. Jeśli nie wymuszasz ograniczeń na poziomie bazy danych, najpierw tracisz integralność danych, ponieważ jedna z tych aplikacji może nie spełniać wszystkich zasad. Po drugie, musisz wielokrotnie zakodować te ograniczenia i przepisać je, jeśli później zdecydujesz się użyć innej aplikacji. Po trzecie, nie można z góry kontrolować, czy konieczne będzie wykonanie jakiegoś zadania konserwacji danych, które nie nastąpi przez aplikację (na przykład naprawienie danych z importu danych złego klienta lub zmiana wszystkich 10 000 000 rekordów od jednego klienta do innego klienta, gdy firma jest kupowana przez konkurenta). Zazwyczaj twórcy aplikacji nie

HLGEM
źródło
Dzięki za odpowiedź. Wszystkie procesy i typy aplikacji, o których mówisz, powinny rozmawiać z DAL (który z kolei zawiera ograniczenia). ALE! Twój punkt jest doskonały, a twój komentarz jest dobry. Sidenote: Tak. Staram się próbować sposobów na ułatwienie rozwoju. Dla mnie mniej złożoności może oznaczać mniej sposobów na zło. To nie „chce się rozwijać łatwiej / szybciej”, nawet jeśli mogłoby być - jeśli jest źle traktowane. Dlatego publikuję to pytanie! Widziałbym też kogoś zdrowego rozsądku, gdyby ta nie-kaskada została wybrana rozsądnie, a nie w 100% jak w tym scenariuszu. Muszę znaleźć powody.
Niezależny
@Jonas, mogą występować również przyczyny związane z wydajnością. Zależy od liczby rekordów potomnych. OK, jeśli usuwasz małe grupy, ale jeśli mogłyby zostać uruchomione miliony rekordów, lepiej jest robić partie i nie blokować wszystkich tabel podczas całego procesu. Zasadniczo wiele baz danych nie zezwala na kaskadowe usuwanie tylko z tego powodu, ponieważ może zablokować system prod, jeśli usunięcie wpłynie na zbyt wiele rekordów.
HLGEM
2
Nie wszystkie procesy nie powinny rozmawiać z DAL. Procesy ETL zwykle nie powodują żadnych zmian na poziomie bazy danych, które mają wpływ na wiele rekordów, gdy nastąpi duża zmiana (np. Wykupienie klienta). Nie można również zabronić nikomu używania okna zapytania w celu dokonania jednorazowej zmiany. Nigdy nie widziałem bazy danych, która nie wymuszałaby ograniczeń na poziomie bazy danych, które nie miałyby z czasem problemów z integralnością.
HLGEM
10

Czytałem kiedyś gdzieś w zasadzie, że: Dane są kluczem twojej aplikacji . Jeśli kiedykolwiek będziesz uzyskiwać dostęp do danych tylko za pośrednictwem interfejsu użytkownika (a mam na myśli zawsze , tak jak teraz i na zawsze, przez całą wieczność ... i przez cały okres użytkowania aplikacji), to nie potrzebujesz ograniczeń bazy danych. Ale zawsze istnieje szansa, że ​​coś innego niż sama aplikacja będzie musiała dotykać danych, na przykład usługa internetowa, publiczny interfejs API, zadanie rake / zadanie SQL / cron / automatyczny skrypt, a wtedy zaoszczędzisz sobie wiele potencjalnych problemów droga, zachowując ograniczenia DB.

Mocno wierzę, jest to jeden z obszarów rozwoju oprogramowania, gdzie powinien nie stosować suche (i jestem w pełni spodziewając grono downvotes do tej wypowiedzi). Twoje dane są sercem i duszą Twojej aplikacji - jeśli kiedykolwiek zostaną uszkodzone nie do naprawienia, to: koniec gry. Warto IMO egzekwować ograniczenia wszędzie tam, gdzie są potrzebne. Jeśli to oznacza w postaci wyzwalaczy i ograniczeń na poziomie bazy danych, sprawdzania poprawności po stronie serwera w oprogramowaniu pośrednim i Javascript po stronie klienta w interfejsie użytkownika (dla aplikacji internetowych), wtedy IMO jest złem koniecznym, aby zapewnić, że dane są zawsze nieskazitelne .

Wayne Molina
źródło
6

Czy wiesz, co oznacza ORM? Mapowanie obiektowo-relacyjne. Cytując Wikipedię „technikę konwersji danych między niekompatybilnymi systemami typów”. Tak, modele relacyjne i obiektowe nie pasują do siebie. ORM wykonują całkiem niezłą konwersję, przestrzegając zasad obu systemów typów. RDBMS są zorganizowane w taki sposób, aby uzyskać integralność danych za pomocą ograniczeń. Ogólnie rzecz biorąc, integralność jest bardzo miłą rzeczą, dlatego ORM zwykle używają ich podczas tworzenia modelu danych do przechowywania danych obiektowych. Twoja ORM prawdopodobnie ma dobry powód, aby używać ograniczeń „niekaskadowych”. A jeśli to zmusza Cię do skomplikowanych zapytań zamiast tworzenia / aktualizowania / upuszczania określonych obiektów, oznacza to, że coś jest nie tak z konfiguracją ORM.

Jeśli uważasz, że koncepcja relacyjna jest denerwująca, to dlaczego nie używasz obiektowej bazy danych? Jakiś czas temu były one powolne (dlatego większość ludzi nadal używa RDBMS), ale z tego, co słyszałem, nieco się zmieniło. Pozbyłbyś się wszystkich relacyjnych nitpików. Po prostu wskakuj, wskakuj.

Jacek Prucia
źródło
Temat dotyczy wyprowadzenia funkcjonalności ograniczenia z DB i polegania na ustawieniach / rozwijaniu w bazie kodu (np. Mówienie w sieci: Entity / Linq2Sql).
Niezależny
Tak, wiem, ale chodzi mi o to, że najpierw musisz zrozumieć, dlaczego istnieją ograniczenia, a następnie dlaczego ich usunięcie może być złym pomysłem.
Jacek Prucia
Przeniósł! Nie upuszczono. Rozumiem, że żałujesz wiedzy o qustion, o której nie chodziło.
Niezależny
Naprawdę nie można przenosić niczego między niekompatybilnymi systemami. Zrzucisz ograniczenia DB, wprowadzisz ograniczenia aplikacji i po prostu będziesz mieć nadzieję, że będą działać tak samo (co może okazać się zarówno prawdziwe, jak i fałszywe). W każdym razie moje szczere przeprosiny, jeśli źle zrozumiałem twoje pytanie.
Jacek Prucia
Dzięki! „Ruch” oznacza „ruch” literatury. Co oznacza, że ​​tworzysz ograniczenia aplikacji (dobre wyrażenie) w każdym systemie. Przynajmniej każdy system, który nie może współdzielić tego samego DAL. Bardzo dobrym przykładem były bezpośrednie zapytania od administratora db, które „coś naprawiły”. Brak ograniczeń db i brak wiedzy projektowej może prowadzić do osieroconych danych lub dziwnych, całkowicie wykpionych danych.
Niezależny
6

Cóż, właśnie to zrobił eBay i prawdopodobnie mają jedną z największych baz danych na świecie:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Pomimo tego, co powiedziano powyżej o zwiększeniu wydajności przez integralność referencyjną, można ją faktycznie obniżyć; dlatego ogromne bazy danych usuwają swoje ograniczenia i wykonują pracę w warstwie aplikacji. I o ile wiem, to jedyny naprawdę dobry powód.

Po zlikwidowaniu tych ograniczeń zasadniczo tracisz siatkę bezpieczeństwa, która utrzymuje dane w czystości i powoduje własne problemy. Tak jak w przypadku wszystkiego, jest to działanie równoważące. Wydaje mi się, że ogólnie rzecz biorąc należy zachować integralność referencyjną.

Pracując w środowisku programistycznym o silnej integralności referencyjnej wiem, że z punktu widzenia dewelopera może to być całkowity ból; często w środowisku programistycznym trochę brudnych danych nie ma znaczenia, a opracowanie sposobu usunięcia wiersza może zająć godzinę lub dłużej. Jednak może być również bardzo przydatny, ponieważ ograniczenia wyraźnie wyrażają schemat.


źródło
Wreszcie ktoś, kto mnie rozumie :-). Masz całkowitą rację, równowaga jest tutaj naprawdę ważnym punktem. Przeniesienie ograniczeń na poziom aplikacji może być bezpieczną alternatywą, jeśli zostanie to zrobione jako punkt strategiczny. Byłoby dobrze, gdyby niektóre adresy URL witryn wykazywały obniżoną wydajność ze względu na silne ograniczenia / integralność.
Niezależny
10
Tak i nie zapominaj - nie zapominaj - że Ebay, podobnie jak Facebook i Amazon - jest razy ponad 99,99% baz danych, a to, co jest dla nich dobre, prawdopodobnie bardzo różni się od tego, co jest dobre dla twojej bazy danych.
Tony Andrews
2
I eBay, Facebook, Amazon prawdopodobnie nie korzystają z baz danych bez ograniczeń dla swojego oprogramowania finansowo-księgowego, oprogramowania do inwentaryzacji lub danych kadrowych lub gdziekolwiek, gdzie utrata danych nie jest krytyczna.
HLGEM
2
Jeśli masz wystarczająco dużo czasu, wiedzy i pieniędzy, możesz ostatecznie zaprogramować dowolny RDBMS, serwer WWW lub system operacyjny, aby spełnić określone potrzeby.
JeffO
1
eBay nie zrobił tego, dopóki ogromna liczba danych, z którymi mieli do czynienia, nie przekroczyła zdolności serwerów baz danych do poradzenia sobie i mieli miliony na zainwestowanie w nową architekturę. Jeśli robisz miliardy transakcji dziennie, z pewnością pracuj nad usunięciem ograniczeń i przejściem do całkowicie opartego na kolejkach, bezkontaktowego, ogromnie skalowalnego systemu, takiego jak eBay. W przeciwnym razie nie lekceważ serwera bazy danych i nie narażaj bazy danych na uszkodzenie danych poprzez usunięcie wszystkich ograniczeń.
Craig,
4

Po pierwsze - moja odpowiedź: nie, nie powinieneś polegać na samej aplikacji, aby dbać o swoje dane.

Wskazuje to na szerszą debatę: ORM zachęcają do pogardy dla „bezpośredniej” interakcji DB, często kosztem normalizacji / integralności referencyjnej. Tabele są wymuszone mapowane do dowolnych hierarchii obiektów, kosztem projektu wynikającego z modelu relacyjnego. Prawdopodobnie poświęcono tutaj oddzielenie, które jest preferowane przez OOP, ponieważ aplikacja sprawia, że ​​jego konstrukcja jest odczuwalna w strukturze danych. Chociaż ORM wykazał się dużą użytecznością, wydaje się, że opiera się na nadużyciach lub nieufności wobec SQL.

Pojawiają się nowe paradygmaty, na przykład programowanie funkcjonalne. Jeśli zespół programistów zdecyduje się zastosować nową metodologię programowania, jakie to będzie miało konsekwencje dla danych, które zostały ustrukturyzowane zgodnie z wymaganiami ORM?

Zgadzam się z @Jacek Prucia - myślę, że ORM nie pasuje do RDBMS, osobiście wybrałbym DBAL na RDBMS lub wybrałem OODB z ORM.

sunwukung
źródło
+1 za mówienie jako alternatywę dla tematu. Drugą stroną debaty jest oczywiście: „Jak złe byłyby niektóre dane?” a odpowiedzią może być anulowanie lub wprowadzenie miliardów pieniędzy na konto bankowe w milionach dolarów. Jak również niektóre osierocone dane, które są usuwane za pomocą dobrych procedur czyszczenia. Podsumowanie tego tematu przypomina spójność kosztów elastyczności. Co z kolei w pełni zależy od ważności zawartości bazy danych i jej wykorzystania.
Niezależny
3

Ograniczenia są twoją jedyną gwarancją spójności i integralności danych na poziomie bazy danych. Jasne, możesz egzekwować ograniczenia za pomocą kodu aplikacji, ale co, jeśli w przyszłości będziesz musiał bezpośrednio modyfikować dane? Możesz zrozumieć, jak zachować integralność danych, ale ktoś inny może tego nie zrobić. Utrzymanie ograniczeń na poziomie danych gwarantuje, że integralność jest zapewniona, nawet gdy ktoś krąży w miejscach, których nie rozumie.

Ponadto załóżmy, że twoja aplikacja musi zostać przepisana, ale z tą samą bazą danych. Wszystkie te ograniczenia w kodzie są tylko błaganiem o błędy, które uniemożliwiają pewne wejście, jednocześnie umożliwiając przesyłanie błędnych danych.

Podczas opracowywania zachowaj prostotę. Ograniczenia pozwalają ci to zrobić. (To powiedziawszy, gdy ograniczenie generuje błąd, nie wyrzucaj tego samego błędu użytkownikowi. Spraw, aby błąd był zrozumiały).

(Co do kwestii kaskady: to dobra rzecz. Wolę rzucić błąd, że niektóre inne rekordy muszą zostać najpierw usunięte, niż polegać na kaskadzie, aby wszystko było w porządku. Kaskady są ładne w teorii, ale niekoniecznie więc w praktyce).

Kerri Shotts
źródło
2

Jednym z problemów związanych z ograniczeniami w bazie danych jest to, że dają one programowi ograniczone informacje o tym, co się nie udało i jak to naprawić. Oznacza to, że dla płynnej obsługi często konieczne jest powtórzenie sprawdzania ograniczeń w aplikacji, a zatem sprawdzanie ograniczeń bazy danych jest marnotrawstwem.

Grozi to naruszeniem integralności danych, więc mamy tutaj kompromisy. W przypadku ważnych danych zapewnienie integralności danych jest prawie zawsze ważniejsze niż wydajność i zdecydowanie lepiej jest zawieść transakcję, nawet jeśli wygląda na arbitralną, niż popsuć dane.

Dlatego, aby bezpiecznie usunąć ograniczenia, należy zabezpieczyć dostęp do bazy danych, aby nic nie mogło zmienić bazy danych bez sprawdzania ograniczeń. Nie jest to niezawodne przy pisaniu nowych aplikacji lub wymyślaniu doraźnych sposobów postępowania z danymi, ponieważ wystarczy jeden błąd, a baza danych jest uszkodzona.

Dlatego, aby zrezygnować z ograniczeń bazy danych, konieczne jest ustalenie, co można, a czego nie można zrobić z bazą danych z góry, aby wszystkie aplikacje mogły być pisane, przeglądane i testowane w szerokim zakresie. Wszystkie wymagania dotyczące bazy danych muszą zostać ustalone z góry, a wszelkie zmiany wymagań dotyczących bazy danych będą wymagały intensywnej pracy. Jest to coś w rodzaju metodologii zamrożonego wodospadu, która działa tylko w bardzo szczególnych przypadkach. (Projektowanie, wdrażanie i utrzymywanie zgodności z wymaganiami przypomina chodzenie po wodzie. Coś musi najpierw zostać zamrożone, a jeśli nie jest wystarczająco zamrożone, wyniki mogą być katastrofalne).

Jednym z przypadków, w którym działa, są masowe aplikacje dla przedsiębiorstw, takie jak PeopleSoft i SAP, w których aplikacja robi już praktycznie wszystko, a istnieją dokładnie zdefiniowane sposoby jej rozszerzenia. Istnieją inne, bardzo rzadkie, możliwości.

Tak więc, chyba że pracujesz nad bardzo dużym projektem przedsiębiorstwa (a nie chciałbym) lub nie możesz chodzić po wodzie w stanie płynnym, pozostaw te ograniczenia w bazie danych.

David Thornley
źródło
1
Dzięki za odpowiedź. Ograniczenia będą w db dla tego projektu! Jestem całkowicie przekonany :). Będę również miał szersze oczy, kiedy podejmę decyzję w sprawie przyszłych projektów i w rozmowach z innymi częściami.
Niezależny
1
Weź również pod uwagę, że bez ograniczeń pozostawiasz to samemu kodowi aplikacji, aby wykryć, że się zepsuł. To ten sam kod aplikacji, który naruszył ograniczenie w twoim przykładzie, ograniczenie, które uratowało twoją bazę danych przed niespójnością lub uszkodzeniem danych. Nawiasem mówiąc, stosowanie ograniczeń nie oznacza automatycznie niższej wydajności, a nieużywanie ograniczeń pozostawia bazę danych narażoną, więc nie może się chronić.
Craig,