OT:Der er IMHO en del ting, SQL Server ikke understøtter, men ville give mening i et virksomhedsmiljø:
- Udskydbare begrænsninger som nævnt her
- MARS:Hvorfor skal du indstille en mulighed for noget helt naturligt?
- CASCADE DELETE-begrænsninger:SQL Server tillader kun én enkelt cascadation-sti for en given CASCADE DELETE-begrænsning. Igen, jeg kan ikke se en grund til, hvorfor det ikke skulle være tilladt at kaskade ved sletning gennem flere mulige stier:I sidste ende, på det tidspunkt, hvor det virkelig udføres, vil der altid kun være én sti, der rent faktisk bliver brugt, så hvorfor er denne begrænsning?
- Forebyggelse af parallelle transaktioner på en enkelt ADO.NET-forbindelse.
- Tvingning af hver kommando, der udføres på en forbindelse, der har en transaktion, der skal udføres i denne transaktion.
- Når du opretter et UNIKT indeks, behandles NULL, som om det var en faktisk værdi, og får kun lov til at vises én gang i indekset. SQL's begreb om NULL som en "ukendt værdi" ville dog indikere, at NULL-værdier ignoreres fuldstændigt, når indekset oprettes...
Alle disse små ting gør mange af de referenceintegritet og transaktionsfunktioner, du ville forvente af et RDBMS i fuld størrelse, næsten ubrugelige i SQL Server. For eksempel, da udskydbare begrænsninger ikke understøttes, er begrebet "transaktion" som en eksternt konsistent arbejdsenhed delvist ophævet, og den eneste levedygtige løsning - bortset fra nogle beskidte løsninger - er slet ikke at definere referenceintegritetsbegrænsninger. Jeg ville forvente, at den naturlige adfærd for en transaktion er, at du kan arbejde inde i den på den måde og i den rækkefølge, du ønsker, og systemet vil sørge for, at den er konsistent på det tidspunkt, du udfører den. Lignende problemer opstår som følge af begrænsningen, at en referentiel integritetsbegrænsning med ON DELETE CASCADE kun må defineres på en måde, så kun én enkelt begrænsning kan føre til kaskadesletning af et objekt. Dette passer virkelig ikke til de fleste scenarier i den virkelige verden.