外键拆分手记

外键,手记 · 浏览次数 : 35

小编点评

## 思路解析和代码实现 这个思路使用多个 small service 来拆分一个单体系统,并通过渐进拆分的方式确保系统高度可用。该思路通过在数据表中添加表示外键的字段来实现外键约束,并使用 EF Core 的 `ForeignKey` 属性显式指定外键名称。 **主要步骤:** 1. **指定外键结构**:创建两个实体类 `AD_Insect_Info` 和 `AD_Insect_Datum`,并定义它们之间的一对多关系。 2. **创建多个 service**:根据需要创建多个数据库服务,每个服务负责处理特定数据库的逻辑。 3. **实现渐进拆分**:在完全拆分前,在旧系统中保持旧数据与新数据的隔离,并确保数据完整性。 4. **使用 EF Core 提供的 ForeignKey 属性**:显式指定外键名称,避免使用导航属性。 5. **根据需要进行数据更新和查询**:在拆分完成后,需要进行数据库连接并执行相应的操作。 **代码示例:** ```csharp // AD_Insect_Info实体类 public class AD_Insect_Info { [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)] public int Id { get; set; } public string Name { get; set; } public virtual List Results { get; set; } } // AD_Insect_Datum实体类 public class AD_Insect_Datum { [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)] public int Id { get; set; } public virtual AD_Insect_Info AttachDevice { get; set; } [NotMapped] public override string AttachId => AttachDevice.AttachDeviceId; } // AD_Insect_Data数据库上下文 public class AD_Insect_Data : DbContext { // ...其他数据库操作代码 ... // 获取外键列名称 public string AttachDeviceId => _context.AD_Insect_Infos .Where(w => w.Id == 1) // 例如,获取对应数据表中的 "AttachDeviceId" 列 .Select(w => w.AttachDeviceId) .FirstOrDefault(); } // 使用 ForeignAttribute 指定外键名称 [ForeignKey("AttachDeviceId")] public int AttachDeviceId { get; set; } ``` **注意:** * 代码示例仅供参考,可能需要根据实际需求进行调整。 * 拆分过程中需要考虑性能和可扩展性的影响。 * 需要根据实际情况进行数据库连接配置和数据迁移等操作。

正文

我习惯性使用OData,它的$expand与层级查询非常好用,这个功能非常依赖于数据库的导航属性,也就是外键结构。最近想着把一个单体的系统拆分为多个小系统,首先需要处理外键依赖的问题。

多个服务各自有各自的数据库,数据库层面并不互通,也就无法使用外键约束。

我使用EF Core来描述数据库的结构,有两个实体类如下:


public class AD_Insect_Info
{
	[Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
	public int Id {get;set;}
	public string Name { get; set; }
	public virtual List<AD_Insect_Datum> Results { get; set; }
}

public class AD_Insect_Datum
{
	[Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
	public int Id { get; set; }
	public virtual AD_Insect_Info AttachDevice { get; set; }
	[NotMapped]
	public override string AttachId => AttachDevice.AttachDeviceId;
}

可以看到他们之间有一个导航属性,实现一个一对多的关系。如果系统是新系统,大可直接进行拆解,想怎么弄就怎么弄。但是对于已经有较多数据的现有系统,最好使用渐进拆分的方式。

思路:通过多次,每次只修改一点,维持对旧有系统的兼容性,并在完全拆分前保持系统高度可用,破坏性最小。

指定外键

跨数据库的访问,数据完整性不能由数据库通过外键实现,我们需要在应用层实现自己的逻辑。由于外键不存在,我们需要在数据表中有表示对外引用的字段。而对于导航属性而言,外键已经由EF Core自动建立,为了防止数据结构变化导致的问题,我们可以明确指定外键。

查询数据表结构

EF Core有默认的外键命名规则,通常是字段名+外键的字段名,对于本例,则是AttachDeviceId,保险起见,我们可以查询数据库获得外键列名称。

显式指定外键名称

导航属性的外键名字不是那么直观,我们可以使用EF Core的ForeignKey特性。

public class AD_Insect_Datum : AttachDataBase
{
	[Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
	public int Id { get; set; }
	[ForeignKey("AttachDeviceId")]
	public virtual AD_Insect_Info AttachDevice { get; set; }
	public int AttachDeviceId { get; set; }
}

这样,这个对象Id就被显式指定了。

查询替代

前一步指定了外键,但是实际上并没有对EF Core表做任何更改,原来的程序可以正常运行,我们需要在这个基础上继续改造,将使用导航属性的地方修改一下。

public virtual async Task<IActionResult> Data(string key)
{
	return Ok(_context.AD_Insect_Data.Where(w => w.AttachDevice.Name == key));
}

修改为:

public virtual async Task<IActionResult> Data(string key)
{
	var instances = _context.AD_Insect_Infos.Where(w=>w.Name == key).Select(w=> w.Id).ToList();
	return Ok(_context.AD_Insect_Data.Where(w => instances.Contains(w.AttachDeviceId)));
}

这样就避免使用导航属性依赖。

我这里也没有使用连表查询方法,因为将来需要拆分。

删除外键

由于不再使用导航属性,可以安全地删除外键。注意,可能需要补充一些业务逻辑以确保数据库中的数据完整性。

拆分DbContext

将来DbContext将不再拥有AD_Insect_Infos,因此我们需要进一步拆分。

public virtual async Task<IActionResult> Data(string key)
{
	IEnumerable<int> instances = Foreign.GetList(key);
	return Ok(_context.AD_Insect_Data.Where(w => instances.Contains(w.AttachDeviceId)));
}

public class Foreign
{
	public IEnumerable<int> GetList(string key)
	{
		return _context.AD_Insect_Infos.Where(w=>w.Name == key).Select(w=> w.Id).ToList();
	}
}

上面代码表示大致的思路,请自行处理注入依赖等问题。

然后就是熟悉的动作了,将Foreign类作为一个数据服务,只要返回的类型是IEnumerable<int>就可以了,数据的来源可以是本身,也可以是外部的服务。

与外键拆分手记相似的内容:

外键拆分手记

我习惯性使用OData,它的$expand与层级查询非常好用,这个功能非常依赖于数据库的导航属性,也就是外键结构。最近想着把一个单体的系统拆分为多个小系统,首先需要处理外键依赖的问题。 多个服务各自有各自的数据库,数据库层面并不互通,也就无法使用外键约束。 我使用EF Core来描述数据库的结构,有

[转帖] MySQL常见的存储引擎InnoDB、MyISAM的区别?

1)事务:MyISAM不支持,InnoDB支持2)锁级别:MyISAM 表级锁,InnoDB 行级锁及外键约束(MySQL表级锁有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。什么意思呢,就是说对MyISAM表进行读操作时,它不会阻塞其他用户

[转帖]Innodb存储引擎-锁(数据库锁的查看、快照读&当前读、MVCC、自增长与锁、外键与锁、行锁、并发事务的问题、阻塞、死锁、锁升级、锁的实现)

文章目录 锁lock 与latch读锁/写锁/意向锁INNODB_TRX/INNODB_LOCKS/INNODB_LOCK_WAITS一致性非锁定读(快照读)一致性锁定读(当前读)MVCC版本链Read View流程 自增长与锁外键和锁行锁类型记录锁(record lock)间隙锁(gap lock

MySQL基础8-多表查询

一、多表关系 一对多或者多对一 案例:部门与员工的关系 关系:一个部门对应多个员工,一个员工对应一个部门(不考虑跨部门的特殊情况) 实现:在多的一方建立外键,指向一的一方的主键,这里员工表是多的的一方,部门表是一的一方 多对多 案例:学生与课程的关系 关系:一个学生可以选修多门课程,一门课程也可以供

MySQL之InnoDB存储结构

InnoDB存储引擎最早由Innobase Oy公司开发(属第三方存储引擎)。从MySQL 5.5版本开始作为表的默认存储引擎。该存储引擎是第一个完整支持ACID事务的MySQL存储引擎,特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读,非常适合OLTP场景的应用使用。目前也是应用最广泛的存储引擎。

外译笔记 | 比尔盖茨:AI与智能手机和互联网一样具有革命性

这篇文章,值得关注的是,盖茨提出对人工智能如何可以减少世界上最严重的不公平现象的思考,以及我们关注的人工智能风险问题。

程序员自由创业周记#35:外包、技术选型和卖房

对待外包的态度 外包是来钱最快的方式,通过出售自己的时间和技能换取报酬,一定程度上与上班类似。创业后一直在做自己的产品,从习惯打卡软件:加一,到灵动岛软件:Island Widgets,然后Mac休息提醒软件:Nap,到现在正在开发AI作图软件:AI画图王。做自己的产品最开心的就是自由,设计、交互、

番外1.ssh连接管理器

[TOC] # 本篇前瞻 学习完go语言基础的专栏,我们究竟写出怎么样的实用工具呢?我在github上开源的[ssh连接管理器](https://github.com/Breeze0806/ssh-mgr)就是一个比较好的样例。 # 项目背景 这个项目的背景是之前我在上班时连接生产机器时只能使用“s

以小博大外小内大,Db数据库SQL优化之小数据驱动大数据

SQL优化中,有一条放之四海而皆准的既定方针,那就是:永远以小数据驱动大数据。其本质其实就是以小的数据样本作为驱动查询能够优化查询效率,在SQL中,涉及到不同表数据的连接、转移、或者合并,这些操作必须得有个数据集作为“带头”大哥,即驱动数据,而这个驱动数据最好是数据量最小的那一个。 内大外小 在讨论

JVM 堆外内存查看方法

JVM 堆外内存查看方法JVM 堆外内存查看方法 1.概述 是否曾经想过为什么Java应用程序通过众所周知的*-Xms和-Xmx调整标志消耗的内存比指定的数量大得多 ?由于各种原因和可能的优化,JVM可能会分配额外的本机内存。这些额外的分配最终可能使消耗的内存超出-Xmx* 限制。 在本教程中,我们