数据库表应该与API中定义的结构保持一致吗？

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《数据库表应该与API中定义的结构保持一致吗？》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

假设我有一个 grpc 服务，并且有一个 api 可以像这样创建新用户：

service userservice{
  rpc createuser(createuserrequest) returns (createuserresponse);
}

message user {
  string userid = 1;
  string firstname = 2;
  string lastname = 3;
  string password = 4;
}
message createuserrequest {
  user user = 1;
}

message createuserresponse {
  user user = 1;
}

该服务将用户数据保存到 postgresdb 中的 users_table 中，如下所示：

user1 := newuser() // instantiating the user object as defined in the proto file.
// user2 := newmyuser() // instantiating the myuser object as defined separately in the service.
result := s.db.table(userstable).create(user1)

此外，我正在使用 proto 缓冲区根据上面的 api proto 文件生成服务器和客户端代码。 我的问题是：实例化用户对象时，用户应该是 proto 定义中定义的生成的 user 结构吗？或者我应该像这样定义另一个 user 结构作为专用于 postgresdb 的服务中的模型？

struct MyUser {
      userId string
      firstName string 
      lastName  string 
      password string 
      createdAtMs int64 // an extra field not available in the api
}

后续问题： 每种方法的优点和缺点是什么？最好的设计原则是什么？

正确答案

这两种方式在实践中都会发生。这可能主要取决于您的服务有多少逻辑；逻辑很少的服务（例如，数据库的小包装器）更有可能将原型直接存储在数据库中。具有相似但略有不同的原型是很常见的，其中数据在通过系统时的每​​一步都会被复制。

如果您将原型直接存储在数据库中，然后意识到自己犯了一个错误，则可以通过创建一个与旧消息兼容的新消息来“分叉”原型消息（一个新名称，但所有字段都相同）具有相同的 ID）。将代码迁移到新消息（将旧消息保留在服务中）会很痛苦，但通过这种方法，您不必在切换到新消息类型之前重新编码数据库中的所有数据。

如果您选择在数据库中使用相同的消息，则应确保在存储之前删除未知字段。否则，当您将来添加新字段时，您可能会发现损坏/恶意的客户端已在该字段中存储了数据。

今天关于《数据库表应该与API中定义的结构保持一致吗？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！