应用程序和数据库架构

Question

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

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

我试图从开发的角度来解决设计问题，即 .NET（按主要技能集），因此应该有任何存储的 preocedures 吗？如果不是，那么简单迁移的替代方法是什么？是否有任何推荐的指导方针，有人可以建议同时牢记数据库和 .NET 设计架构？

Answer 1

从一种数据库类型转换到另一种数据库类型确实非常罕见：35 年来我做过一次：从 Oracle 到 SQL Server。那是一个特殊的情况：在 VAX 上运行的一个非常旧的 Oracle 版本多年来一直没有得到任何人的支持，因此必须摆脱它。管理层规定（我认为是正确的）作为我们当时使用的标准 DBMS 是 QL Server，系统应该进行转换。

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

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

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

• T/SQL 代码不容易转换为 PL/SQL（不知道 MySQL 语言，但我会假设有问题）
• 分层查询 (CTE) 无法转换，必须为 Oracle 重新编写。 MySQL AFAIK 不支持它们。
• 从 IDENTITY 列转换为 Oracle 序列应该不是什么大问题（或者 Oracle 现在是否支持更接近的东西？）不了解其他 DBMS。

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

Answer 2

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