我正在设计一个全球ERP/调度系统，该系统必须托管在Google Cloud SQL和Google Datastore上。
在大多数情况下，数据是强关系的，并且体积不大或不稳定，因此自然适合使用关系数据库。
当前设计的地址本地存储在客户、合同、员工、站点、工作订单、合同站点表中。。总共大约12个不同的地方。我要求DEV团队修改设计，创建一个可以被所有其他实体引用的ADDRESS表(如果需要，可以使用链接表为地址历史、多个地址等提供灵活性)。
问题——由于地址/联系方式的格式对于所有这些场景、不同的国家和多个电话号码等都有很大的不同，我认为address&CONTACTDETAILS应该移到DataStore中，并通过Cloud SQL平台中的id引用它们。因此，该结构是完全灵活的，以适应世界的地址格式。
这听起来合理吗？还是过度设计了解决方案，应该只使用CLoud SQL中的通用地址表？
我有一个担忧，因为谷歌平台的瓶颈似乎是单一的MySQL主机。。这是一个仅限于16 vCPU的托管服务，因此我正在尝试将更多功能区域移动到数据存储中。
希望这是有道理的！
您当然可以做到这一点，而且不会是第一个运行混合数据库系统的人。不过，你会增加复杂性，在走上这条路之前，你应该权衡几件事。
-
您提到了16vCPU的限制-地址不太可能是担心这一点的原因，尽管云数据存储会更容易扩展(如中所示，我们为您提供)
-
对于具有更多样化模式要求的数据，由于您已经在使用CandSQL，因此可以简单地使用JSON类型来存储它。只要您在Cloud SQL Second Gen.上即可。
-
事务：如果您需要同时涉及云SQL和云数据存储中的数据的操作是事务性的，那么您必须自己实现。如果你能忍受潜在的不一致和/或清理，那没问题。
-
云数据存储无疑会让您有更大的灵活性来存储这种类型的数据并高效地大规模查询。这是它擅长的用例。