I am wondering what your thoughts are on maintaining relationship constraints within a MS SQL DB.
I am migrating a system into a .NET environment from ASP. This brings with it business objects and other tiered-coding techniques, which work to abstract the database from the user/API. The new application has a definite API above an Entity Framework DAL.
The application DB in the old database is large and the purpose of some of the tables will be changing to start containing binary data, in the form of files, etc. I’m keen to split these off into separate DBs to ease management at the client sites where disk space is at a premium.
Is there any value in retaining relationship constraints between tables?
Assumptions:
- Code is tested
- Where relations are important, execution is performed under a Transaction
- Access to the DB is via the API only, other access by third parties is unsupported.
Reasons to keep constraints:
- Enforces the data structure
- JOINs are faster?
- Query Plan assistance?
Reasons to remove constraints in new .NET version:
- One can assume that the API/BIZ logic would manage relations such as Parent/Child.
- Reduces opportunity to hive off sections of the DB into other catalogs (the system is built using a Plug-in architecture, most tables may operate in isolation)
- Am I correct in believing that SQL has to do additional checks during INSERT on constraints, which may be unnecessary when an API above the DB is managing this?
I don’t support the assertion that constraints “are indexed automatically”. Only Unique and Primary Keys do. Foreign keys don’t, although in most cases I would recommend having an index on the “child” matching the FK’s columns.
Nevertheless I would still recommend FKeys as they
But most of all, have you thought about keeping your data in a single database, but separating it in multiple filegroups? You could achieve your goal a more flexible disk space management without the hassles of Foreign Keys spanning multiple DBs