How compatible are ORMs and existing databases that have many constraints (especially unique key constraints / unique indexes outside of primary keys) implemented in the database itself?
(Often these are already existing databases that are shared by many legacy applications. But the good practice of modeling a database is to identify as many database constraints as possible, as well as double-check applications. Also note that the database engine I work with does not support checking pending restrictions.)
The reason I'm asking is because the ORMs I studied, NHibernate and Linq to SQL, do not seem to cope very well with the unique database constraints. For example, deleting a row and reinserting one with the same business key leads to the exclusion of a foreign key. (There are subtle ones, and it’s harder to avoid examples.) ORMs observe the constraints of the primary key and the foreign key, but usually do not pay attention to the unique constraints.
I understand that there are workarounds such as the NHibernate cleanup method. However, I believe this is an extremely impenetrable abstraction and makes it difficult to develop an application with respect to sharing problems. Ideally, all objects can be manipulated in memory using routines, and then the main procedure can take charge of the call for the actual synchronization of the database. This isolates the update and allows custom logic to check all updates before they are actually submitted to the database.
Running the commands in the correct order is nontrivial. See my question here . However, I expected better support for common cases among the popular ORMs. It seems so important for implementing ORM in your existing environment.
ORM - ?