处理外键 / EF核心6跨数据库查询的微服务策略
我们在.NET 6.0和使用实体框架Core 6中写了一些应用程序。
这些应用程序从SQL Server数据库中消耗数据。每个应用程序都有自己的数据库，这些数据库位于单个SQL Server实例上。
最近，我们需要创建一个新的数据库，其中包含世界各地的邮政编码，街道，社区和城市。在唯一的数据库中，该数据已很好地标准化。
为了满足新的要求，我们需要在数据库中存储此新数据（实际上仅是外国密钥）。例如：应用程序“ X”的用户将存储他的城市。实际上，这个城市是包含其CityID GUID的外键（来自外部数据库）。
我们了解到，跨数据库的直接数据库调用是一个反模式，这就是为什么我们正在为这种情况寻找替代方案的原因。
Micro Service Architecture建议每个应用程序都应处理自己的数据，但不幸的是，没有办法处理外键。
我们在解决此情况的研究中发现：
- 代表外部数据和外键的SQL Server视图。
- 服务松散地为邮政编码。每个客户端数据库将存储这些ID，但是没有外国钥匙检查和执行。
- 跨数据库复制数据复制的触发因素
是否有人对这种情况有最佳实践的提示？
谢谢。
We have some applications written in .NET 6.0 and using Entity Framework Core 6.
These applications consume data from SQL Server databases. Each application has its own database, and these databases are on a single SQL Server instance.
Recently, we needed to create a new database containing Postcodes, Streets, Neighborhoods and Cities around the world. This data is well normalized in a unique database.
To meet a new requirement, we will need to store this new data (actually, only the foreign keys) across the databases. For example: A user from the application "x" will store his city. In practice, this city is foreign key containing his CityID guid (that comes from an external database).
We understand that direct database calls across the databases is an anti-pattern, that's why we are looking for alternatives for this case.
Micro services architecture suggests that each application should handle its own data, but unfortunately, there is no way to handle foreign keys.
We found in our research to solve this case:
- A SQL Server view that represents external data and foreign keys.
- Services loosely coupled for the postcodes. Each client database will store these IDs, but there will be no foreign keys check and enforce.
- Triggers for data replication across databases
Does anyone have a tip for this scenario with the best practices?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论