处理多表关系的更好方法

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%

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

例如

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 

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

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

Answer 1

您的实体表乍一看还不错。但我不明白你的关系表。看起来你试图将一切与一切联系起来，在某些情况下这可能没有意义（优惠真的属于国家吗？）在某些情况下似乎是多余的：当一个页面链接到（许多）城市时，有也不需要把它和国家联系起来，因为国家是由城市决定的。

您应该只在那些真正需要直接多对多关系的实体之间添加关系表。对于这些关系中的每一个，您都需要一个单独的表。

例如对于页面和城市之间的关系：

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

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