Consult the design of classified information field

how to design a database of classified information?

I want to write all the main contents of the information (title,content) in an info table. I don"t know how to design the table for special properties.

category table-Real Estate Job Category

info table, real estate, work, car, etc.

  • id categoryId title content

Category information includes real estate, work, etc., but each type has different special properties, such as real estate area, community, job position, benefits, etc.
but the meta table does not know how to design it. Solve the problem or how to solve it

A scheme

id metaname metavalue infoId
area. 120
small area. Community name
position. Sales

or Plan B this feeling field will be many, because not only the real estate job, but also the car and so on

id area Community position infoId
120name sales

=

update the table designed by yourself. If someone has a better one later, please advise

+-------------------+
| Tables            |
+-------------------+
| houses            |
| informations      |
| jobs              |
| category          |
+-------------------+

informations table
+------------+------------------+------+-----+---------+----------------+
| Field      | Type             | Null | Key | Default | Extra          |
+------------+------------------+------+-----+---------+----------------+
| id         | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| title      | varchar(255)     | NO   |     | NULL    |                |
| content    | text             | YES  |     | NULL    |                |
| category_id| int(10) unsigned | NO   | MUL | NULL    |                |
| field_id   | int(10) unsigned | NO   |     | NULL    |                |
| field_type | varchar(10)      | NO   |     |         |                |
+------------+------------------+------+-----+---------+----------------+

houses table
+--------------+------------------+------+-----+---------+----------------+
| Field        | Type             | Null | Key | Default | Extra          |
+--------------+------------------+------+-----+---------+----------------+
| id           | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| layout_shi   | tinyint(4)       | NO   |     | NULL    |                |
| layout_ting  | tinyint(4)       | NO   |     | NULL    |                |
| layout_wei   | tinyint(4)       | NO   |     | NULL    |                |
| area         | smallint(6)      | NO   |     | NULL    |                |
+--------------+------------------+------+-----+---------+----------------+

jobs table
+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| id          | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| gangwei     | varchar(255)     | NO   |     | NULL    |                |
| company     | varchar(255)     | NO   |     | NULL    |                |
| address     | varchar(255)     | NO   |     | NULL    |                |
| fuli        | varchar(255)     | YES  |     | NULL    |                |
+-------------+------------------+------+-----+---------+----------------+

the field_id in the informations table is houses or jobs and the id,field_type is houses or jobs.
informations is associated with houses and jobs polymorphisms

I"m learning laravel, so that"s about it.

Mar.22,2021

1. Real Estate-worksheet
Category ID Real Estate Information ID Job Information ID

2. Property list
property information ID attribute 1 attribute 2.

3. Worksheet

work information ID attribute 1 attribute 2.


doesn't quite understand your needs.


probably know what you mean. In fact, your own design is to give the common to the abstract model. I do not recommend designing in this way in the storage layer. There are many differences in the model properties of each category, and redundancy is not allowed, but it is not conducive to future expansion. Each category builds a table separately. It is good for the abstraction you want to leave in the application layer to abstract the model. All stacked in one table is too unfriendly for expansion and modification. I hope it will be helpful to you.

Menu