Should we use foreign-key constraints when persisting Domain Models?

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.

  • Anonymous

    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.

  • Amine

    As most Engineers respond “It depends”.
    Generally speaking, having FK checks is good reflex because in development early stages, when GUIs are not already made, collaborators on project will insert data directly into their databases, and if there is not appropriate checks, we could finish with non-coherent data into several tables. Many bugs will appear after that due to that fact. I believe that FK Checks doesn’t simply belong to Business Rules/ Logic.
    hope it helps.