Czy mój wieloserwerowy RDBMS lub moja aplikacja powinny obsługiwać referencyjną integralność bazy danych?

Czy elementy takie jak klucze obce, ograniczenia, wartości domyślne itp. Powinny być obsługiwane przez system zarządzania bazą danych (w tym przypadku MS SQL 2005) czy aplikację? Słyszałem opinie z obu stron i szczerze mówiąc nie jestem pewien, w którą stronę pójść.

Istnieje szansa, że ​​będziemy obejmować wiele serwerów / baz danych i nie sądzę, aby klucze obce można było stosować na połączonych serwerach. Oprócz tego w projekcie bazy danych znajdują się odwołania cykliczne, które uniemożliwiają mi korzystanie ON UPDATE CASCADEze wszystkiego.

Baza danych to MS SQL 2005 (prawdopodobnie 2008) i wszystkie interakcje z nią powinny przechodzić przez aplikację.

Jeśli istnieje szansa, że ​​baza danych zostanie zmodyfikowana poza twoją aplikacją, potrzebujesz ograniczeń w bazie danych. Jeśli DB jest i zawsze będzie niczym więcej niż tylnym końcem aplikacji, możesz je pominąć, chociaż na wszelki wypadek udokumentowałbym je i prawdopodobnie zatrzymam je, jeśli wydajność nie będzie tak zła. (Oprogramowanie Peoplesoft działa w ten sposób - ograniczenia są w oprogramowaniu, a (nie wymyślam tego) uruchamia wszystko jako SYS na Oracle.)

Chcesz, aby aplikacja monitorowała takie rzeczy, aby mogła reagować inteligentnie, a w najlepszym razie nie przesyłać użytkownikowi komunikatu o błędzie bazy danych.

I tak, jest to podwójny zasięg, ale bez niego prawdopodobnie dostaniesz możliwe do uniknięcia uszkodzenie danych lub zły interfejs użytkownika.

Idealnie oba. Nie powinno nie mieć DB poradzić, ale potem znowu, jeśli aplikacja wyjdzie z danych DB odrzuci, to jest błąd wykonania, więc aplikacja powinna mieć przynajmniej jakiś kod poświęconą zachowaniu integralności referencyjnej. Ponadto ustawienie odpowiednich ograniczeń w SQL w bazie danych jest znacznie prostsze niż ustawienie kodu po stronie klienta, więc wykonanie go w bazie danych znacznie zmniejsza ilość pracy, którą musisz wykonać.

Jeśli jest to ważne, pozwól bazie danych sobie z tym poradzić. W ten sposób nie musisz się martwić, że ktoś uzyska dostęp do bazy danych poza aplikacją i zmieni lub wprowadzi jakieś niespójne lub zduplikowane dane. Chyba że są to elementy wysokiego poziomu specyficzne dla aplikacji (np. „Tylko użytkownicy z działu X posiadający klasę dostępu ZZZ powinni należeć do grupy 999”), ale zwykle nie jest to określane jako „referencyjna” integralność.

Powiedziałbym umieścić w bazie danych. Jeśli używasz trwałego frameworka, automatycznie pobiera klucze.

Oba są zdecydowanie właściwą drogą. Będziesz potrzebować logiki sprawdzania poprawności w swoim kodzie, aby zapobiec złym aktualizacjom i wstawieniom, a także poinformować użytkowników, co jest nie tak i jak to naprawić. Posiadanie bazy danych w celu zatrzymania rzeczy, więc jeśli coś wejdzie i nie przejdzie sprawdzania poprawności, nie zepsuje rzeczy na dobrej linii.

Powinieneś utrzymywać zawartość bazy danych na wyższym poziomie. EG, egzekwuj referencyjną liczbę całkowitą, a być może niektóre nie są zerowe. Ale nie martw się ograniczaniem długości lub formatów, ponieważ najlepiej jest to renderowane w całości w aplikacji.