在生产环境中从 mysql 迁移到 nosql 数据库，无需更改代码且 mysql 无需外键和索引

Question

我这里有两种情况：

1. 在不更改代码的情况下将 mysql 数据库迁移到 nosql（不使用 orms）
2. 在mysql中不使用外键和索引（因为他们将来想迁移到不同的数据库） 3.all 这是通过非常少的代码更改完成的

这些问题是由我的团队负责人提出的。所以我没有正确给他的答案，因为我觉得在没有索引和外键的情况下 mysql 不太可能，首先，如果他们不打算使用 mysql.then 为什么他们选择那个。

1. 我想知道软件行业的人是这样的 经常或他们会根据自己的需要正确选择
2. 他们说外键验证是由 api 级别完成的 不是 mysql 级别

我不理解他们，因为我经验不足，所以我不知道他们为什么这样说。请给我一些见解，这是否是一个好的做法？

Answer 1

我认为不添加代码是不可能的 - 您需要以某种方式实现 nosql DB 引擎管理数据的方式。如果项目的编码明确分离了业务逻辑和数据库代码，那么使用新数据库实现而不是旧数据库实现是一件简单的事情。如果不是这种情况，并且您的数据库实现泄漏到您的业务逻辑中，那么在不更改代码的情况下将无法进行切换。根据代码库的大小，它可能/很可能会太昂贵。

如果您想查看 dB 逻辑与业务逻辑完全分离的示例，请查看此存储库：https://github.com/fathersson/money-transfer （这不是我的存储库，我今天偶然发现了它）

如果您想学习和理解驱动该设计的原理，请从寻找 "clean architecture" and/or "Domain Driven Design" 开始——我认为第一个更容易理解，还有是 Robert C. Martin 在 YouTube 上的一些演讲，您可以在买书之前先看一看。

编辑：我目前正在处理的项目确实从 rds 上的 postgresql 运行 更改为使用不同存储库的 dynamodb，而没有更改任何现有业务逻辑。这样可以节省很多钱。所以是的，更改数据库后端确实发生了并且是由需求驱动的。

除此之外，当我开始处理新功能 set/micro service/bounded 上下文时，我通常会从使用地图的简单内存存储库实现开始。完成初始用例集后，我对数据库要求有了更多了解，并根据这些要求和一般要求选择数据库引擎，以限制使用的不同技术的数量。