应用与;数据库架构

Question

每当我设计一个数据库（当前是SQL Server）时，我总是想知道如果将来我必须迁移到另一个数据库（Oracle，MySql）是一种考虑一些重要参数的最好方法，比如命名约定（表，列包括长度），数据类型等。我经常问自己以下问题：

我应该命名我的表格，列是复数还是描述性的？ 我应该为表/列添加前缀，在名称中使用下划线或任何其他标识符吗？ 名称应该是特殊/特定的套管吗？

我试图从开发角度来看设计，即.NET（通过主要技能组合），因此是否应该存在任何存储的预处理？如果没有，那么轻松迁移的替代方案是什么？是否有任何建议的指导方针，有人可以建议记住数据库和数据库.NET设计架构在想什么？

Answer 1

从一种数据库类型转换为另一种数据库类型实际上是非常罕见的：35年来我已经完成了一次：从Oracle到SQL Server。这是一个特殊情况：在VAX上运行的一个非常旧版本的Oracle，多年来一直没有得到任何人的支持而且必须摆脱它。管理层下令（正确地说，我认为）作为我们当时使用的标准DBMS是QL Server，系统应该被转换。

MS有一个转换工具，我们使用它。我工作得很好，但由于PL / SQL与T / SQL有很大的不同，复杂的存储过程虽然有效，但是不可维护且非常慢，所以我们从头开始在T / SQL中重新编写它们 - 这需要花费很多时间。但这是唯一的问题。

我个人的方法是尽量减少对SP的使用。如果你在SP中逐行处理游标，那么在我看来 你做错了。处理RAT（一次一行）的任何东西都应该是代码;任何可以处理数据集的东西都应该在SP中。

除非你有理由认为你需要转换，否则我不会担心。如果你这样做，只要你用命名约定做出明智的事情就不应该成为问题。你遇到问题的是：

• T / SQL代码无法轻松转换为PL / SQL（不了解MySQL 语言，但我会承担问题）
• 分层查询（CTE＆＃39; s）不会翻译，必须为Oracle重写。它们不受MySQL AFAIK支持。
• 从IDENTITY列转换为Oracle序列不应该是一个大问题（或Oracle现在是否支持更接近？）不了解其他DBMS。

但正如我所说，这不是我通常所担心的事情。

Answer 2

您是否尝试使用ORM，例如Entity Framework采用代码优先方法？ 它有助于避免代码中特定于数据库的内容，同时它还提供了非常灵活的迁移机制。