OT: There are IMHO quite a few things SQL Server does not support, but would make sense in an enterprise environment:
- Deferrable constraints as mentioned here
- MARS: Just why do you need to set an option for something entirely natural?
- CASCADE DELETE constraints: SQL Server does only allow one single cascadation path for a given CASCADE DELETE constraint. Again, I don’t see a reason why it shouldn’t be allowed to cascade on deletion through multiple possible paths: In the end, at the time it really is executed, there will always be only one path being actually used, so why is this restriction?
- Prevention of parallel transactions on a single ADO.NET connection.
- Forcing of every command executed on a connection that has a transaction to be executed within this transaction.
- When creating a UNIQUE index, NULL is treated as if it was an actual value, and allowed to appear only once in the index. SQL’s notion of NULL as an “unknown value” would, however, indicate, that NULL values be ignored altogether when creating the index…
All these little things make many of the referential integrity and transactional features you would expect from a full-sized RDBMS nearly useless in SQL Server. For example, since deferrable constraints are not supported, the notion of a “transaction” as an externally consistent Unit Of Work is partly negated, the only viable solution – except fro some dirty workarounds – being to not define referential integrity constraints at all. I would expect, the natural behavior of a transaction be that you can work inside it in the way and order of operations you like, and the system will make sure it is consistent at the time you commit it.
Similar problems arise from the restriction, that a referential integrity constraint with ON DELETE CASCADE may only be defined in a way that only one single constraint can lead to the cascaded deletion of an object. This really doesn’t fit most real-world scenarios.