OT:IMHO jest kilka rzeczy, których SQL Server nie obsługuje, ale ma sens w środowisku korporacyjnym:
- Odroczone ograniczenia, jak wspomniano tutaj
- MARS:Tylko dlaczego musisz ustawić opcję na coś całkowicie naturalnego?
- Ograniczenia CASCADE DELETE:SQL Server zezwala tylko na jedną ścieżkę kaskadową dla danego ograniczenia CASCADE DELETE. Ponownie, nie widzę powodu, dla którego nie powinno być dozwolone kaskadowanie przy usuwaniu wieloma możliwymi ścieżkami:w końcu, w momencie rzeczywistego wykonania, zawsze będzie używana tylko jedna ścieżka, więc dlaczego czy to ograniczenie?
- Zapobieganie równoległym transakcjom na pojedynczym połączeniu ADO.NET.
- Wymuszanie każdego polecenia wykonanego na połączeniu, które ma transakcję do wykonania w ramach tej transakcji.
- Podczas tworzenia indeksu UNIQUE, wartość NULL jest traktowana jako rzeczywista wartość i może pojawić się w indeksie tylko raz. Pojęcie SQL o NULL jako „nieznanej wartości” wskazuje jednak, że wartości NULL są całkowicie ignorowane podczas tworzenia indeksu...
Wszystkie te drobiazgi sprawiają, że wiele z referencyjnych integralności i funkcji transakcyjnych, których można oczekiwać od pełnowymiarowego RDBMS, jest prawie bezużyteczne w SQL Server. Na przykład, ponieważ ograniczenia podlegające odroczeniu nie są obsługiwane, pojęcie „transakcji” jako zewnętrznie spójnej jednostki pracy jest częściowo negowane, a jedynym realnym rozwiązaniem – z wyjątkiem kilku brudnych obejść – jest w ogóle nie definiowanie ograniczeń integralności referencyjnej. Spodziewałbym się, że naturalnym zachowaniem transakcji będzie to, że możesz w niej pracować w taki sposób i w kolejności operacji, jakie lubisz, a system zadba o to, by była spójna w momencie jej realizacji. Podobne problemy wynikają z ograniczenia, że ograniczenie integralności referencyjnej z ON DELETE CASCADE można zdefiniować tylko w taki sposób, że tylko jedno ograniczenie może prowadzić do kaskadowego usuwania obiektu. To naprawdę nie pasuje do większości rzeczywistych scenariuszy.
