During the development process, what is the problem about table connection query and table splitting query for data retrieval?

For example, a complete job search information can include (basic personal information table, personal education information table, Personal Certificate Table, personal job search information table, and Personal Job Search renewal table .... I want to obtain a complete personal job information. I know two examples:
A complete job information can include (Personal basic information table, personal education information table, Personal Certificate Table, personal job information table, and personal job seeking information table .... Extended tables like this)

Now, I want to obtain a complete personal job information. I know two solutions: 1. Linked List query. 2. query the complete information of a single table multiple times.

Excuse me: What are the advantages and disadvantages of these two methods? In the past development, we prefer the data retrieval method? Or is there any good solution? What can I do if there is more data?

Reply content:

For example:
A complete job information can include (Personal basic information table, personal education information table, Personal Certificate Table, personal job information table, and personal job seeking information table .... Extended tables like this)

Now, I want to obtain a complete personal job information. I know two solutions: 1. Linked List query. 2. query the complete information of a single table multiple times.

Excuse me: What are the advantages and disadvantages of these two methods? In the past development, we prefer the data retrieval method? Or is there any good solution? What can I do if there is more data?

Even table queries do not increase as much data volume as you expect in the future, and all associated table queries have indexes. for example, your table contains a total of thousands of data records, and the growth volume is only 10 records in a few weeks. you may not consider that much.
However, when your data volume increases to 100,000 or million in the future, you need to split the table and try to distinguish hot and cold data (there is a read/write requirement, which should be distinguished from the one written for permanent read ).
Based on your business characteristics, I can see that there are still some cold data, that is, one write, there is no need to write, there is only a read demand, this can be put into a separate table, and then perform a long period of cache.

The minimum number of database requests is the best!

For your scenario, it is recommended that you check a single table multiple times. If you have an index, it will not be slow, mainly for good maintenance.

Look... if you use grouping in the linked list, you 'd better just split the query. It doesn't matter if you have other basic functions.

Single-table queries are the primary feature, and the speed of queries with a small amount of data can be ensured by using join table queries.