关于数据库，实体框架是不可知的，这意味着它可以潜在地用于任何有 ADO.NET 提供者的数据库。话虽如此，残酷的事实是，试图访问除了 SQL Server 之外的数据库会变得非常麻烦。主要问题是:
- 唯一支持的主键生成策略是 IDENTITY 和手动，甚至 IDENTITY 在其他提供类似功能的数据库中也不起作用，比如 MySQL 和 Oracle 12c 也不支持序列。
- 实体框架的 SQL 生成引擎有时会生成特定于 SQL Server 的 SQL 片段。其中最臭名昭著的是 CROSS 和 OUTER APPLY ，它们在 2005 年之前的 SQL Server 版本中甚至都不起作用。
- EFCF 假设了 dbo 的数据库模式，这在其他数据库中是不存在的，所以我们被迫在每个实体的映射中指定一个模式。
- 一些。其他一些数据库不支持. NET 类型，例如枚举类型、Guid、数据库几何和数据库地理。
- 数据库数据类型，即使概念上相同，也有不同的名称。例如，SQL Server 中的可变长度 Unicode 字符串称为 NVARCHAR，而在 Oracle 中则称为 VARCHAR2。需要指定时要小心。
- 一些等价类型略有不同。例如，在 SQL Server 中，dateTIME 属性可以转换为同时具有日期和时间部分的 DateTime 列，但是在 Oracle 中，当转换为 DATE 列时，它将只具有日期部分。另一个例子是，DateTimeOffset 甚至在 Oracle 和其他应用中也有对等项，但在 SQL Server 2005 上没有。
- 用于并发检查的 TimestampAttribute 所隐含的 ROWVERSION 类型，或者更好地说，它的工作方式，也只存在于 SQL Server 系列中。
- 浮点或十进制类型可能有不同的精度。
- 最后但同样重要的是，不要期望数据库生成能够工作:它不会工作，这意味着你只能靠自己。
列表可以继续，但是陈述了一些问题之后，使用实体框架来定位其他数据库当然是可能的。拥有相同的代码基础几乎肯定是行不通的。我将为您留下一些跨数据库项目的指南:
- 不要使用数据库初始化器，总是自己生成数据库。
- 请务必只使用“安全”的基本类型，如字符串、数字、字节数组和日期/时间。
- 请务必为每个属性指定物理列名。
- 请务必为每个实体指定物理名称和模式。
- 请务必使用手动分配的标识符。
- 不要为属性指定数据库类型名称。
有关第三方实体框架提供商的最新列表，请查看:http://msdn.microsoft.com/en-us/data/dd363565.aspx。