如何使用同一用户设置多个 Oracle 数据库（模式）？

Question

我们公司继承了一些在 C# Visual Studio 2010、Windows 7 和 Oracle 11g 上运行的软件。经过一番努力，我们让软件运行起来，并建立了一个稳定的数据库（模式）。

我们现在开始将一些数据从旧系统迁移到这个“新”系统。但是，我不想弄乱我们的工作模式，因为我预计我们的数据导入需要进行一些反复试验。

我想做以下事情： 假设我们现有的模式称为 PROD。我想创建一个名为 TEST 的第二个模式，我们可以将其用于导入的数据。然后，在 C# 代码中，我可以在两个数据库模式之间切换时切换数据源的名称。问题是此连接的用户名和密码出现在代码中分散的许多地方。为了避免每次在“数据库环境”之间切换时都必须在多个位置更改用户凭据，我想创建一个用户来访问 PROD 和 TEST。

但是，how to grant user privilege on specific schema? 表示这是不可能的。 Correct way to give users access to additional schemas in Oracle 建议了一种在对象级别授予访问权限的方法，但这还不够：我基本上希望一个用户可以访问两个相同的模式（PROD 和 TEST）。完成此操作后，我想开始修改 TEST 以开始我们的数据导入。

我也尝试在不同的端口上将 TEST 创建为单独的 Oracle 数据库安装，但是当尝试在这个新实例上创建我的用户时，我仍然遇到用户已经存在的冲突（因为它是在原始数据库安装）。

我的用户已经存在并且可以访问 PROD。我如何让他也可以访问 TEST？或者如何解决更普遍的问题，即在使用 Oracle 的应用程序中定义 PROD 和 TEST 数据库？

在 MySQL 中这将是微不足道的，但我不知道如何在 Oracle 中执行此操作。我对 Oracle 很陌生。

Answer 1

授予权限的问题有already been answered。

现在，作为一个整体来回答您的问题：我是否正确地阅读了您想要更新数据库架构，但您想要将其与另一个架构保存在同一个数据库中，并在看似生产数据库的情况下运行两者？如果是这样，请再读一遍，让它深陷其中的危险性。

当从一个“架构”迁移到另一个“架构”时，作为软件更新，创建新数据库并迁移数据会更安全。这为您提供了很多机会，因为您可以在调整脚本时炸毁新数据库。

如果您希望软件中的摩擦尽可能小，您需要做几件事：

1. 从决定在多个地方硬编码连接信息的白痴那里重构代码。您需要将字符串放在一个位置，并确保将数据访问层 (DAL) 代码提取到其自己的类中。
2. 考虑创建不依赖于数据库模式的域对象。我认为这是强制性的，但是您可以不这样做就逃脱。我仍然会创建域对象，即使它们与 PROD 架构表匹配，因为如果您从一个架构移动到另一个架构，则不应使用数据构造。
3. 为您的数据访问层 (DAL) 创建接口
4. 使用接口将当前数据架构通过当前 DAL 映射到域对象。
5. 使用接口将新架构通过新 DAL 映射到域对象。
6. 创建工厂（或使用提供者模式）以确定您将使用哪个 DAL 对象（这使得应用程序可配置为旧的或新的“模式”

Answer 2

我假设您有一个架构 PROD 和一个 DBUSER，它们对此架构中的对象拥有一些特权。
DBUSER 的名称和密码在整个应用程序中都是硬编码的。
您已经创建了一个新架构 TEST，它看起来与 PROD 相同（包括对 DBUSER 的授权）。
无论应用程序执行什么操作，您都希望它：

UPDATE some_table set ...

它将更新TEST 中的some_table 表，而不是PROD。
我的建议是使用和更改SYNONYMS，即-
当您想在PROD 中更新some_table 时，请执行以下操作：

CREATE OR REPLACE PUBLIC SYNONYM some_table for prod.some_table;

当您想在TEST 中更新some_table 时，请执行以下操作：

CREATE OR REPLACE PUBLIC SYNONYM some_table for test.some_table;

Answer 3

在 C# 代码中未正确处理与 Oracle 的连接，这就是造成困难的原因。

如果数据访问层按照 Gregory 的建议单独定义，或者如果 A.B 的回答指出在 SQL 语句中使用更通用的命名约定，那么在两个数据库之间切换会简单得多。

由于我们的任务目前不涉及对代码进行任何更改/重构，我正在使用备份和恢复方法：

我创建了工作数据库的备份。然后我对数据库进行必要的测试和更改。如果我需要恢复到工作数据库，我会再次创建“测试”数据库的备份并恢复原始工作数据库，在恢复的情况下使用适当的标志替换现有表。这使我能够在“工作”数据库和“测试”数据库之间来回切换。

这并不理想，因为它确实需要一些时间来执行备份和恢复，但可以在不影响 C# 代码的情况下工作，并且能够在“测试”数据库上进行工作而不影响正在工作的数据库。由于这是“测试”数据库开始工作之前的临时场景，因此这是我将遵循的方法。

正如其他答案所指出的那样 - 修复/重构/概括连接代码需要更通用 - 我相信这是最好的方法，我不立即这样做的唯一原因是因为我们还没有强制更改代码。