Are data tables created in different sections on the homepage?

Some of the sections on the homepage are images, some contain titles and descriptions, and some only have titles. Are these specially created data tables for Storage? If so, it seems that these different sections cannot be created in a data table. For example, the image section needs to store the title, image url, and Article id ,...

Some of the sections on the homepage are images, some contain titles and descriptions, and some only have titles. Are these specially created data tables for Storage? If so, it seems that these different sections cannot be created in a data table. For example, the title, image url, and Article id need to be stored in the image section, while other sections may not need to store the image url. In this way, different sections need different fields.

It may be a bit messy. I want to ask how different elements on the homepage are stored in the background?

Reply content:

Some of the sections on the homepage are images, some contain titles and descriptions, and some only have titles. Are these specially created data tables for Storage? If so, it seems that these different sections cannot be created in a data table. For example, the title, image url, and Article id need to be stored in the image section, while other sections may not need to store the image url. In this way, different sections need different fields.

It may be a bit messy. I want to ask how different elements on the homepage are stored in the background?

Just a table .. Why multiple tables...
Do you still have multiple UI posts in the background? (The article page of Forum 1, and the article page of Forum 100 ?)
It's okay to store titles, images, articles, and Forum positions in a table?
Similarly, when publishing an article, you can select the forum where the article is published.
You know.

A table is enough. A field is used to distinguish different sections.

When the page is displayed, it is split into several arrays according to the plates and pushed to the template.

A table is ready. You don't need to store the image URL. You just need to leave the field blank.

In principle. In the extreme sense, you can create a table with a piece of news and an image. Then, we slowly push it to the normal: A table of the same type of news. Then, we recommend that you add a field to a table for different types of news. And so on. If there is no accurate answer, you need to take into account the convenience of understanding and the efficiency of adding, deleting, modifying, and querying.

SQL storage tree structure for unlimited Classification

CREATE TABLE `typecho_contents` (  `cid` int(10) unsigned NOT NULL auto_increment,  `title` varchar(200) default NULL,  `slug` varchar(200) default NULL,  `created` int(10) unsigned default '0',  `modified` int(10) unsigned default '0',  `text` text,  `order` int(10) unsigned default '0',  `authorId` int(10) unsigned default '0',  `template` varchar(32) default NULL,  `type` varchar(16) default 'post',  `status` varchar(16) default 'publish',  `password` varchar(32) default NULL,  `commentsNum` int(10) unsigned default '0',  `allowComment` char(1) default '0',  `allowPing` char(1) default '0',  `allowFeed` char(1) default '0',  `parent` int(10) unsigned default '0',  PRIMARY KEY  (`cid`),  UNIQUE KEY `slug` (`slug`),  KEY `created` (`created`)) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

This is simple. A single table achieves many extensions.