Not you indeed, I'd not be questioning you, as we were both arguing in favour - sorry for any confusion.
John Mitchell-245523 (9/3/2015)
ZZartin (9/3/2015)
While it's nice to have the extra check in the DB the work of determining appropriate foreign key values should already have been done in the application correctly, I don't think that's an unreasonable expectation.What about changes that don't go through the application? Suppose you raise a support issue and a junior technician sends you a script to fix it - who or what will do the checking then? What when the application vendor is taken over and a whole new group of programmers takes the code in a different direction and accidentally (or otherwise) leaves out the relationship checks? No, database integrity should be enforced in the database layer.
John
Quite.
Also how else do you find about the bad allocation of records? With the foreign key you get a nice logged error (at least in any sensible application) that helps you track down the misallocation.
If you add a new application that does some work to an established database can you be sure it will do the right thing? If you need to clean up some customers but maintain an order trail - what stops the accidental deletion of the wrong ones? I just fail to see how they are ever not a useful thing - sure, not for the odd table say in an import situation or something but otherwise....