Rest 关于如何构造数据模型的思考

假设我有两个用于RESTful API契约的模型：用户和交付

// User

id      | Long
-----------------
name    | String
-----------------
street1 | String
-----------------
street2 | String
-----------------
city    | String
-----------------
state   | String
-----------------


// Delivery

id           | Long
--------------------
recipient_id | Long
--------------------

这种结构假设交付与用户绑定，而实际上用户与地址绑定。将数据结构分为三种模型似乎更有意义：用户、交付和地址：

// User

id         | Long
--------------------
name       | String
--------------------
address_id | Long


// Delivery

id           | Long
--------------------
recipient_id | Long
--------------------
address_id   | Long
--------------------

// Address

id      | Long
-----------------
street1 | String
-----------------
street2 | String
-----------------
city    | String
-----------------
state   | String
-----------------

---

有三种模型的缺点是，如果一种模型要获取交付的街道地址，那么每个请求都必须有一个连接。然而，业务逻辑在语义上是这样的。交付和用户都链接到地址，这是对他们关系的恰当描述。如果api响应需要用户和地址之间的联合类型，可以声明一个UserAddress类型，该类型具有来自地址和用户模型的值。但我不确定哪种方法是正确的。请给我一些建议，告诉我该怎么做。

根据我个人的想法，第二种结构比较合适。由于总地址（包括街道、城市等）将是单个用户的一个属性，因此我认为将所有这些属性添加到用户信息中不是一个好的决定

其次，如果用户更新其地址，将如何更新？如果更新的地址已在地址表中，则只能更改有界地址id，但如果使用第一个结构，则应更新用户的所有地址属性

顺便说一句，从UML的角度来看，第二种选择也会更好。从流程中可以看出，交付使用地址进行处理，一个地址与一个用户绑定。同时，地址仅与用户绑定，而不是用户的属性，例如：我使用酒店地址作为订单地址，但如果我已退房怎么办？您是否也要更新这种情况下的用户表

总之，我认为第二种选择比第一种更好，无论是从结构方面还是从现实世界方面

---

希望能对您有所帮助。：-）

您可能会得到更多的反馈，了解如何在不重新创建的情况下将此问题转移到那里？