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?
źródło
Odpowiedzi:
Dwa ogólne powody, dla których nie należy usuwać ograniczeń z bazy danych :
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ę.
źródło
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ą.
źródło
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
źródło
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 .
źródło
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.
źródło
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
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.
źródło
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).
źródło
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.
źródło