处理多个表关系的更好方法

Question

假设我有一些像...这样的表格 国家

id name  
1  Cyprus  
2  India   

州

id name country_id   
1   a     1   
2   b     2   
3   c     2  

城市

id name state_id   
1   x     1     
2   y     2  
3   z     3  
4   p     2    

页面

id name  slug    status   
1   ab   a-b       1      
2   pq   p-q       0   
3   abc  a-b-c     1     

mode_of_training

id  name 
1   Virtual
2   Classroom

项目

id name description 
1   a   something   
2   b   something

价格

id price currency_code 
1   200   USD
2   300   AUD
3   4000  INR

优惠

id name   discount
1  xyz-1   20%
2  abc-2   30%
3  pqr-3   10%

以这种方式创建表结构是正确的吗？这样我就可以重复使用它们了 使用那里。

例如

items_relation_table

id country_id state_id  city_id  page_id item_id price_id offer_id  status
1   0           0         0       1        1       1         0        1
2   0           0         0       1        1       1         1        0
3   1           0         1       2        2       1         2        1
4   1           0         1       3        3       2         1        1 

• 现在我不需要使用表格的字段值
• 如果我想改变价格。我只会在一个地方改变价格
• 我节省了字节数。
• 数据库表格大小不足

但我的问题是 要获取数据，我需要使用连接
或者创建视图是更好的主意 或者有更好的方法来创建表结构

Answer 1

乍一看你的实体表看起来很好。但我不理解你的关系表。看起来你试图把所有事情与所有事情联系起来，在某些情况下可能没有意义（提供真的属于国家吗？）在某些情况下似乎是多余的：当一个页面链接到（很多）城市时，没有必要将它与这些国家联系起来，因为这些国家是由城市决定的。

您应该仅在真正需要处于直接多对多关系的实体之间添加关系表。对于每个关系，你需要一个单独的表。

e.g。对于页面和城市之间的关系：

cities(id, name, state_id) <--> cities_pages(city_id, page_id) <--> pages(id, name, slug, status)

是的，您必须连接表才能获取数据。这是关系数据库背后的基本思想之一。如果您的表格被正确编入索引并且根本不是昂贵的操作（假设性能是您关心的话），请不要害怕加入。当然，如果对您的应用程序有意义，您可以添加一些视图，但这将包括相同的JOINS，您只需在CREATE VIEW语句后面抽象它们。