这个MySQL数据库可以改进吗，或者它是好的吗？

在分类广告网站中，您有几个类别（汽车、mc、房屋等）。 对于选择的每个类别，一个隐藏的div将变为可见，并显示用户可以指定的附加选项（如果他/她愿意）

我现在正在创建一个数据库，我读了一些关于规范化和优化的文章

这是我今天的上篮

类别表：
-汽车
-mc
-房屋

分类表：
-标题
-说明
-隐藏电话号码
-可变的
-行动
-价格
-修改日期

海报表：
-名称
-passw
-电话
-电子邮件

面积表：
-面积
-社区

CARS表：
-年份
-燃料
-变速箱
-颜色

MC表：
-年份
-类型

房屋表：
-别墅
-公寓
-大小
-房间
等

到目前为止，我每个类别有一个表，大约30个表。 这不是太多了吗？

到目前为止，我还没有为其中任何一个创建PK或FK，还没有那么远

您能告诉我这个设置是否好，或者我应该让它做得不同吗？

另外，您如何在此处设置FK和PK？

---

谢谢

根据我的理解，我会为所有类别制作一个表格，并将类别的名称和ID存储在那里。接下来，我将创建一个单独的表来存储每个类别的附加选项

MySQL Table 1  
----------------   
Category_ID int PRIMARY KEY  
Category_name varchar  

MySQL Table 2  
---------------- 
Category_ID int   
Entry_Number int PRIMARY KEY (this will keep track of which entry everything belongs to)
Additional_Option varchar  
Additional_Option_Answer varchar (this is the one that stores what your user clicks/inputs)

例如，使用：

POSTER TABLE:
- name
- passw
- tel
- email

您可以将此数据用于的类别id存储在

类别id

中，并将

名称
密码
电话
电子邮件
存储在它自己的行中
附加选项
中，用户对这些标准的输入将存储在
附加选项
中

海报的
类别ID将为1，
区域的
类别ID将为2。

如果第一个用户添加了以下内容，则会出现这种情况：

---------------------------------------------------------------------------------------------
Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
---------------------------------------------------------------------------------------------
       1      |   1                |    name                 |   doug
       1      |   1                |    passw                |   1234

---------------------------------------------------------------------------------------------
Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
---------------------------------------------------------------------------------------------
       1      |   2                |    name                 |   Hamlet
       1      |   2                |    passw                |   iliketurtles

如果第二个用户添加了以下内容，则会出现这种情况：

---------------------------------------------------------------------------------------------
Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
---------------------------------------------------------------------------------------------
       1      |   1                |    name                 |   doug
       1      |   1                |    passw                |   1234

---------------------------------------------------------------------------------------------
Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
---------------------------------------------------------------------------------------------
       1      |   2                |    name                 |   Hamlet
       1      |   2                |    passw                |   iliketurtles

此外，让我们应用另一个类别：

AREA TABLE:
- area
- community

---------------------------------------------------------------------------------------------
    Category_ID   |    Entry_Number    |    Additional_Options   |   Additional_Options_Answers
    ---------------------------------------------------------------------------------------------
           2      |   3                |    area                 |   San Francisco
           2      |   3                |    community            |   community_name

通过使用表名中的数据，可以识别类别表的问题。为每个类别设置表的问题主要不是您得到了很多表，而是如果您添加了另一个类别，您必须更改数据库设计。此外，当需要基于数据选择表时，查询数据库也很困难

您应该将过帐属性作为一个表，而不是每个类别一个表。由于每个类别的属性不同，您还需要一个表来描述每个类别使用的属性

描述主要对象（类别、分类、海报、面积、属性）的表将获得主键。其他表只需要外键，因为它们是对象之间的关系

Category (CategoryId, CategoryName)

Classified (ClassifiedId, PosterId, AreaId, ...)

Poster (PosterId, ...)

Area (AreaId, AreaName, ...)

Property (PropertyId, PropertyName)

CategoryProperty (CategoryId, PropertyId)

ClassifiedProperty (ClassifiedId, PropertyId, Value)

首先，您需要为每个表创建主键。通常，最好的方法是使用名为id或tablenameId的顺序id字段。这真的很重要。当数据更改时，绑定到实际数据的主键将导致问题

category (id PK, name)
category_options (id PK, category_id FK->category.id, option_name)

因此，category表的值如下

(1, car)
(2, MC)

期权的价值如下

(1, 1, year)
(2, 1, fuel)
(3, 2, type)

然后，您需要一个表，其中的值实际存储并链接到该项。这只需要在查询一个项目时联接所有3个类别表

category_values (id PK, category_options_id FK-> category_options.id, value, classified_id FK->classified.id)

分类表需要fk到海报和id字段

classified (id PK, poster_id FK->poster.id, headline, description, hide_telephone_nr, changeable, action, price, modify_date)

Poster表非常好，因为它只是为主键添加id字段。我只是认为它通常被称为用户

通过category\u options\u id FK->category\u options.id，我的意思是category\u options\u id应该有对category\u options.id的外键引用

您可以对classified.action和classified.changable进行更多的规范化，但这也增加了复杂性

我希望这有帮助

我还必须强调，这不是唯一可能的解决方案，根据您实际使用数据的方式，这可能不是最好的选择，但它可以正常工作：）
您的设计与基础产品紧密相关。此外，您正在将看似互斥的数据放在不同的列中（例如，一栋房子肯定不能既是别墅又是公寓？），我将采用更广义的形式，例如：

Category 
Classified
Poster

与OP中相同，但添加/声明了主键

然后将所有特定于类别的属性分组到一个类似于表的列表中

Std_Tags {id, category, tag}
{0,Cars,year}
{1,Cars,fuel}
{2,house,type}
{3,house,rooms}

使用另一个表中的值：

classified_tags {std_tags_id, classified_id, value}
{0,13356,2005}
{2,109,villa}
{0,153356,diesel}

这也简化了输入表单的构建，因为通过添加如下表，模板也被明确说明：

Allowed_values {std_tags_id, value}
{1,diesel}
{1,petrol}
{1,LPG}
{2,Villa}
{2,Apartment}

然后，许多数据输入可以使用符合标准搜索的下拉列表来完成

C.
请澄清，正如您在上面看到的，这就是我所做的。。。解释更多我希望这能更好地澄清：）所以用户只在最后一个表中插入数据，值表，对吗？我明白了！ie:CARS->YEAR->INSERTED VALUE（ex 2010）？最后一个表格将是用户自定义输入的唯一表格；是的。哇，我的第一个被接受的答案！我进步的里程碑！好的，我想我明白了。。。你能再解释一下你的第二段吗？我怎样才能“描述每个类别使用的属性”。。。举个例子，一定会很开心！CategoryProperty表u将获得每个类别的knw abt属性。@pesar:CategoryProperty表包含类别的属性。例如，“MC”类别将有两行，一行表示“年”属性，另一行表示“类型”属性。分类在“MC”类别中的属性在ClassifiedProperty表中会有两行，其中包含两个属性的值。闻起来像家庭作业？：）它也是在我想知道为什么ms access作为标签存在？这对你来说是怎样的？谢谢你的回答。请问，你为什么要链接（FK）cla