Database Design Principles: association or not Association?

Database Design Principles: association or not Association? When designing a website database (determined to use Hibernate), there is often debate. The focus of the debate is mainly on the association between tables: some tend to remove any association between the table and the table; some speak in integrity, and all associations must be kept. Opinion 1: I prefer to remove

Database Design Principles: association or not Association? When designing a website database (determined to use Hibernate), there is often debate. The focus of the debate is mainly on the association between tables: some tend to remove any association between the table and the table; some speak in integrity, and all associations must be kept. Opinion 1: I prefer to remove

Database Design Principles: association or not Association?

When designing a website database (determined to use Hibernate), there is often debate. The focus of the debate is mainly on the association between tables:
Some tend to remove any association between the table and the table; some speak in integrity, and all associations must be kept.

Opinion 1:I tend to remove all associations for the convenience of development. Then, when writing the code, pay attention to integrity issues.

Opinion 2:

If foreign key association is not used, many fields must be concentrated in a table, resulting in data redundancy. The database table structure is designed according to the method driven by the domain model. Each object in the domain model has only one responsibility, so the data items in the object do not have the transfer dependency. The database table structure design in this way satisfies the third paradigm from the very beginning: A table must meet the second paradigm, and there is no transfer dependency between attributes.
If it is a small project, it is not a problem to develop it easily but not to link it. However, if it is a large project, it is better to follow the rules.

Opinion 3:

It depends on what kind of pressure system you are working on. If the system requires tens of thousands of transactions per second, dear, I suggest you use less join. It doesn't matter if the number of systems is less than 1 W/S. Integrity is more important than anything else. when the pressure is too high, compromise! My strategy is for tables under the primary pressure. Generally, there are always several focus tables in the system. The data access pressure is high and the reading and writing are intensive. These tables are well designed and should not be associated, write and write operations to allow experienced programmers to encapsulate DAO APIs. Other small tables need to be joined to prevent programmer problems. We have been working on this for four years. Projects of 200 MB and more than 0.5 million rows now tend to be completely unrelated, and new data models will not be associated.

Opinion 4:

Specific analysis

Business table I think Association is better

Some historical information, such as logs, is basically unrelated to me, and the maximum redundancy is ~

My point of view:

I have insufficient experience in db and will not comment on it for the moment.