我是否应该在DB中为UserAddress助手类Java、Hibernate、Postgres创建一个单独的表？

我正在为用户管理制作一个小型的restful服务。通过赋值，用户由以下值定义：

◦ First name 
◦ Last name 
◦ Date of birth 
◦ Login 
◦ Password 
◦ Input field “About me” 
◦ Address of residence (country, city, street, house, flat)

在设计时，我注意到了地址，并认为将所有内容都写在一个地址字段中，并在数据库表中创建一个类似的属性是错误的，因为这样按地址进行不同的过滤将变得非常不方便。然后，我将地址字段分隔为5个字段（括号中的字段）。然而，在这样做之后，我意识到，给定id字段，我的类有13个字段，在我的理解中，这使得类过载和“错误”。然后我决定为地址创建一个单独的类，并将其用作用户的字段，即：

@Entity
public class UserAddress {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private long id;
    private String country;
    private String city;
    private String street;
    private int house;
    private int flat;

}

在这样做之后，我不完全确定如何进行，因此我有以下问题：

我应该在UserAddres中将5个地址字段移动到一个单独的类中吗

如果是这样，是否值得创建该类实体并在数据库中为其创建表

是否应该将其视为一个完整的类（创建吸气剂/设置器、均衡器和哈希代码、服务层、控制器和知识库层）？

按地址过滤用户会比原来更复杂吗

处理这种情况的最好办法是什么

将它们移动到一个额外的表中，允许您为每个用户存储多个地址，而无需冗余用户数据（如名称）

是的，因为JPA/Hibernate将使用@OneToMany和@ManyToOne注释处理PK/FK关系

等于/Hashcode是。getter和setter可能是的，这取决于您处理这些数据的方式。如果您有用户输入，例如通过GUI，则需要getter和setter。在某个地方，您可能需要将地址和用户数据“融合”到服务的用户数据（即将发布的数据）。
编辑：如果地址对象无效且不属于用户，则只能通过其用户对象操纵地址对象，这有助于数据的一致性

不，JPA提供了连接表的方便方法

关于Restful服务的最佳实践是在实体（数据库和应用程序之间的用户+地址）和DTO（应用程序和第三方之间的用户+地址）之间有一个映射器

---

我没有GUI，我只做服务器端，但控制器和存储库呢。我应该有机会与地址进行个性化交互，还是应该只通过用户访问地址。