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

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?

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

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

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

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 .

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.

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.

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.

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

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.