Micheal, Constraints are pretty important to maintaining the quality of a database. Constraints help to ensure that data is properly constructed without dangling references to things that don’t exist or codes that were typo’d. It also ensures you don’t delete something that is referenced elsewhere. Furthermore, constraints serve to document valid navigation in your database, there are many 3rd party tools that use this additional information to improve user experience. You want to use them. In fact, proper constraints are what make OMOP so attractive.
On the other hand, enforcing constraints while loading a large database can slow things down quite a bit. In these cases, you typically drop/disable the constraints (and the corresponding indexes that maintain them), and then enable the constraints and recreate the indexes after the data-set is loaded. This way you enjoy the knowledge that your data is coherent, but don’t have to suffer slow loading speeds. If your source data has reference problems, say there’s missing codes, then you’ll need to fix these before the constraints are enabled.
Furthermore, some data, for example, a top-level cyclic relationship in a vocabulary may be meaningful, but cannot be constructed while the constraints are enforced. I don’t know of OMOP has terminology cycles like this. This may be another reason to temporarily disable constraints. Regardless, you really want to get those constraints back up before you put the database into production.