OT:Det finns IMHO en hel del saker som SQL Server inte stöder, men som skulle vara vettiga i en företagsmiljö:
- Uppskjutningsbara begränsningar som nämns här
- MARS:Varför behöver du ställa in ett alternativ för något helt naturligt?
- CASCADE DELETE-begränsningar:SQL Server tillåter bara en enda kaskaderingsväg för en given CASCADE DELETE-begränsning. Återigen, jag ser ingen anledning till varför det inte skulle tillåtas att överlappa vid radering genom flera möjliga vägar:i slutändan, vid den tidpunkt då den verkligen körs, kommer det alltid att finnas bara en sökväg som faktiskt används, så varför är denna begränsning?
- Förebyggande av parallella transaktioner på en enda ADO.NET-anslutning.
- Tvingande av varje kommando som körs på en anslutning som har en transaktion som ska utföras inom denna transaktion.
- När du skapar ett UNIKT index, behandlas NULL som om det vore ett verkligt värde och tillåts endast visas en gång i indexet. SQLs uppfattning om NULL som ett "okänt värde" skulle dock indikera att NULL-värden ignoreras helt när indexet skapas...
Alla dessa små saker gör många av referensintegriteten och transaktionsfunktionerna du kan förvänta dig av ett RDBMS i full storlek nästan värdelösa i SQL Server. Till exempel, eftersom uppskjutningsbara begränsningar inte stöds, förnekas begreppet en "transaktion" som en externt konsekvent arbetsenhet delvis, den enda genomförbara lösningen - förutom några smutsiga lösningar - är att inte definiera referensintegritetsbegränsningar alls. Jag förväntar mig att det naturliga beteendet för en transaktion är att du kan arbeta inuti den på det sätt och i den ordning du vill, och systemet kommer att se till att det är konsekvent när du utför det. Liknande problem uppstår från begränsningen, att en referensintegritetsrestriktion med ON DELETE CASCADE endast får definieras på ett sätt som endast en enda restriktion kan leda till kaskadradering av ett objekt. Detta passar verkligen inte de flesta verkliga scenarier.