CodeFirst 添加对分区表的支持

[hd2y]

数据库对分区表的支持情况：

数据库类型	支持分区类型	版本支持情况	说明
MySQL	RANGE、KEY、HASH、LIST、COLUMNS	v5.1 开始支持，v5.7 增强	LIST、RANGE 在 v5.5 版本支持
SQL Server	RANGE	所有版本	比较特殊的 RANGE 支持，参考 PARTITION FUNCTION
Oracle	RANGE、LIST、HASH	9i版本开始有限支持	现在主要应用的版本是11g+，完全支持
PostgreSQL	RANGE、LIST、HASH	v10.x	更早的版本也可以使用 pg_pathman
达梦	RANGE、LIST、HASH	支持
神通	RANGE、LIST、HASH	支持
人大金仓	RANGE、LIST、HASH	支持
SQLite	不支持	/	/
Access	不支持	/	/
Firebird	不支持	/	/

后续补充各数据库类型创建或修改 RANGE 等分区的 SQL 脚本。

[2881099]

sqlserver 2005 就有分区了

[hd2y]

sqlserver 2005 就有分区了

哈哈，被下面这句话误导了，我还奇怪呢。

在 SQL Server 2016 (13.x) SP1 之前，SQL Server 的各版本中均不提供已分区的表和索引。

没注意上面受支持的是所有版本。

[2881099]

主要 api 不好设计，差异化太多。。就像现在 BulkCopy

ExecuteSqlBulCopy()、ExecuteMySqlBulCopy()、ExecuteDmBulCopy()、ExecutePgCopy();

[hd2y]

其实首先可以考虑支持 RANGE，其次是 LIST 以及 HASH。

我现在有个困扰是项目中不可避免在数据库中写一些视图、存储过程等处理特殊业务，现在的项目里也有数不清的陈年代码，短时间没办法重构，如果直接分表，小组里面反对意见很大，要改的东西太多了。

我们考虑用分区策略，一种是根据ID或者时间也就是 RANGE 分区，还有一些表使用状态字段 LIST 分区。

周末的时候再查查资料看一下，现在每天被各种项目折磨的头晕眼花的，这种优化都要放在后面再慢慢处理了。😔

说了很多纯吐槽了没说到重点，其实不用把各种数据库的分区表特性都支持，我考虑是提取一个通用的，可以接受的方案，处理像我这样没办法分库分表的场景。

[2881099]

分区只是数据库层面的事，程序层面看它就是单表操作。

[hd2y]

分区只是数据库层面的事，程序层面看它就是单表操作。

是的，要的也是这个效果，现在项目 Oracle 以及 SQL Server 用的多，对分区表的支持很友好，但是之前从来没考虑性能瓶颈，没有考虑过分区/分库/分表，导致现在积重难返了，只能考虑用分区这种见效快的方案了。