Does it make sense to have native relationships in the database if the relation in the active record duplicates them?

Question

MySQL

When designing a database, I make links between tables - this is convenient both for visual perception and sometimes technically, for example, when cascading deleting related data by a foreign key. It is clear that this is done correctly, but in the case of Yii (Yii 2), in any case, we duplicate them (at the database level) at the level of the application’s business logic (yes, connection methods are created during code generation), but the question arises: why then it would not be possible to leave all the logic at the application level (php), as it seems to me it will be easier to work this way, and use the database as a storage of unrelated tables (at the database level).
Does it make sense to have native relationships in the database if the relation in the active record duplicates them?

Answer 1

It's not worth it, if it's obvious to you now, it does not mean that it will remain obvious in a year or will be obvious to someone who will maintain the code instead of you in the future. In addition to this, you will have to write detailed documentation for your code (setting foreign keys is much easier than describing 100 pieces of code that you need to consider simply because the keys are not set), and your changer to study it carefully before starting work and more - always keep in mind. I don’t know how in yii, but in laravel you can work with the database using Orm eloquent and query builder. In eloquent, I can still describe some rules, but I have no guarantees that the programmer who will work on the project after me will not decide to use the query builder, bypassing all the logic written in the models. And in the case of the integrity of the database, these are problems not only of the programmer, these are problems in the first place of the project. Php does not shake hands with such a programmer, but the database is easy.

Answer 2

Good ORMs always build a complete structure of relationships with all Constrainments and Foreign keys in the database.

Answer 3

If you do not set foreign keys, then the data can only be changed through your application. If suddenly you need to change something bypassing the described algorithms, then you risk losing data integrity. And such situations happen quite often.
If you expose the keys, then the database itself will monitor the integrity. It will prevent you from writing inconsistent data and will cascade delete all "orphaned" records when deleting (if the key requires it).
Plus, cascading deletion of the database will make it faster than your code. You for example delete the user and it is necessary to delete all its records. To do this, you first have to select all of its records. Delete them. And then delete the user. And with foreign keys, you simply delete the user, and the database itself will clean up all dependent records.

Answer 4

Of course there is a sense, IMHO, it's not even discussed. All this visualization, auto-generation of relays, and so on - all this is garbage compared to the main task of keys: maintaining data integrity. This is the task of the database, and only she will be able to cope with it qualitatively. If there is no awareness of the mega-importance of the integrity of the database and the role of keys in this - most likely there is simply little experience.
And be careful with cascading deletion. Often, when deleting, some additional logic should work, for example, in the same afterDelete. With cascade deletion, it goes at the database level, and not at the application level, so the logic does not work out.