Should we use foreign-key constraints when persisting Domain Models?
By Saulo, 1 year, 6 months ago in Technology. 1 Comment
Since last summer I’ve been working with three other Software Engineering undergraduates on a web enterprise application that will eventually replace a legacy ERP system. We used patterns from Martin Fowler’s Patterns of Enterprise Application Architecture (a great book, by the way), and the well-known three-layered architecture.
One day we had a discussion related to the persistence of Domain Models and whether we should enforce foreign-key constraints at the database level. My first reaction was that the very use of a relational database implied the enforcement of such constraints, but some of my colleagues argued that the database should be seen as nothing but a persistence mechanism and therefore we should avoid placing any business logic in it. We ended up by not using foreign-key constraints.
Would you have done otherwise? I would like to hear what other software engineers/developers have to say about this.
I agree that the database is in the data layer, however I see no problem in having an “extra” check in your database apart from requiring you to consistently chance the checks when you change the logic.