最好有一个主表或拆分为多个表？答案

【问题标题】：Better to have one master table or split into multiple tables?最好有一个主表或拆分为多个表？
【发布时间】：2017-10-19 02:25:30
【问题描述】：

我正在创建一个数据库，但我不确定设计表格的最佳方式。我有一个房地产表格，我想存储有关这些属性的信息 - 例如卧室、浴室、尺寸……如果有用的话，我可能还有其他想要存储的信息——例如：最后购买价格或建造日期，所以我需要灵活地添加。

是为每个“特征”创建一个单独的表还是为所有特征创建一个表更好？将特征分开似乎更清晰，但在编程方面更容易拥有一张表。

特性表

id  property_id  characteristic  value
1   1            bedrooms        3
2   1            bathrooms       2
3   1            square feet     1000
4   2            bedrooms        2
...

或

卧室桌

id  property_id  bedrooms
1   1            3
2   2            2
...

浴室桌

id  property_id  bathrooms
1   1            2
...

如果这是一个愚蠢的问题，请原谅我，我的数据库设计知识非常基础。

【问题讨论】：

一张桌子似乎适合这个（id在这里没有用处）
但是，在使用 eav 模型时，我喜欢按数据类型拆分属性，所以整数类型的东西放在一个表中，日期类型的东西放在另一个表中，等等，

标签： mysql database-design entity-attribute-value

【解决方案1】：

我建议在您的两个建议之间采取中间立场。即兴发挥我会做的

属性表（UID地址zip其他唯一标识属性）

房间表（UID、propertyID、房间类型、房间大小、地板、形状、颜色、饰面、其他房间特定细节等）

物业详情（uid、propertyID、地块大小、学区、成本、税率、其他整个物业详情）

最后是一两张历史记录表，例如。

房产销售历史（UID、PropertyID、销售日期、销售价格、销售原因等）

通常仅通过“是否匹配”逻辑对数据进行分组可以产生良好的结果....只需考虑表的 1to1 和 1tomany 关系需求。

【讨论】：

【解决方案2】：

我专注于此：

“我有一张房地产表”

现在据我所知，你必须是另一种类型：

Houses
Bedrooms
Comfort room and so on.

进一步解释：你必须是一张桌子：

1. House type
2. House names,description,housetypeid,priceid,bedroomid,roofid,comfortroomid and any other that related to your house.
3. Bedroom type
4. Comfort room type
5. Dining type
6. roof type if it has.
7. House prices
8. Bathroom type

类似的东西。

【讨论】：

即使有墙类型。

【解决方案3】：

一个有几列的表：

价格列、#br、#bath、FR、DR、sqft 和少量其他常用检查属性。然后是一个 JSON 列，其中包含所有其他信息（2 台洗碗机、水疗中心、海景等）。

对单独的列使用WHERE 子句，然后在您的客户端代码中完成过滤，这样可以更轻松地查看 JSON。

【讨论】：