OT:Existuje IMHO docela dost věcí, které SQL Server nepodporuje, ale dávaly by smysl v podnikovém prostředí:
- Zde zmíněná odložitelná omezení
- MARS:Proč jen potřebujete nastavit volbu pro něco zcela přirozeného?
- Omezení CASCADE DELETE:SQL Server umožňuje pouze jednu kaskádovou cestu pro dané omezení CASCADE DELETE. Opět nevidím důvod, proč by nemělo být povoleno kaskádovat při mazání více možnými cestami:Nakonec, v době, kdy se skutečně provede, bude vždy skutečně použita pouze jedna cesta, tak proč je toto omezení?
- Prevence paralelních transakcí na jediném připojení ADO.NET.
- Vynucení každého příkazu provedeného na připojení, které má v rámci této transakce provést transakci.
- Při vytváření UNIQUE indexu se s hodnotou NULL zachází, jako by to byla skutečná hodnota, a může se v indexu objevit pouze jednou. Pojem SQL NULL jako "neznámá hodnota" by však naznačoval, že hodnoty NULL budou při vytváření indexu zcela ignorovány...
Všechny tyto maličkosti dělají mnoho z referenční integrity a transakčních funkcí, které byste očekávali od RDBMS plné velikosti, v SQL Serveru téměř nepoužitelnými. Protože například nejsou podporována odložitelná omezení, pojem „transakce“ jako externě konzistentní jednotka práce je částečně negován, jediným schůdným řešením – kromě některých nečistých řešení – je vůbec nedefinovat omezení referenční integrity. Očekával bych, že přirozeným chováním transakce je, že v ní můžete pracovat způsobem a pořadím operací, které chcete, a systém se postará o to, aby byla konzistentní v době, kdy ji provedete. Podobné problémy vyplývají z omezení, že omezení referenční integrity s ON DELETE CASCADE může být definováno pouze tak, že pouze jedno jediné omezení může vést ke kaskádovému odstranění objektu. To opravdu neodpovídá většině reálných scénářů.