• ZZartin (9/2/2015)


    David.Poole (9/2/2015)


    If you are the person who will bear the consequences then if you are willing to do so then you can do without foreign keys. Chances are that if you are the person who would bear the consequences then you would be quite emphatic that they should be used.

    What is highly unprofessional is to make a decision where people for whom you have no responsibility bear the brunt of your decision.

    Hmm... I guess why I find this topic so interesting is that I keep hearing this "the consequences will dire" statement about not using foreign keys and I just don't see it. Foreign keys protect the integrity of an ERD they do not protect the integrity of data.

    But those relationships do protect the integrity of the data. You can only add information where the enforced relationship allows you to add information. For example, let's say you set up the classic foreign key relationship to a list of Provinces. The only data that can ever be entered is from the list of Provinces. That's protecting the data, not the ERD. Throw away the foreign key. Now you get to deal with about 600 variations on the string 'KANSAS' because there is nothing to prevent anything at all from going into the database. Multiply that by all the Provinces. Further, since you don't have referential integrity protecting the data, we get to have Provinces from the US included in French data. Counties in the UK tossed in amongst the Canadian Provinces. All this making things worse and worse for the data, not simply for the ERD. To heck with the ERD. Who cares about the ERD. We care about the data. We care about what we can feed back to the business people in a meaningful fashion.

    I've seen reporting projects and BI processes abandoned because the data was so horrifically dirty. I've seen quite literally thousands of man hours spent cleaning data because what was in the database was unusable. This isn't about theory. It's about the real world and real work.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning