如果我们暂时不考虑将演示数据放入实时系统中的一分钟的是非(这是一个单独的讨论！)，我们被要求将一些演示数据存储在实时系统中，这样就可以可靠地演示它们，而无需进行任何操作。烟雾+镜子的外观(例如，我们要使用相同的登录页面)

既然我确定这是一个挑战，那么很多其他人一定会对我感兴趣，因为我想知道人们设计了哪些方法来分离这些数据，以免妨碍他们在系统上进行日常操作？

正如我在上面提到的，我知道这可能不是最佳实践。 :-)

解决方案

相反，我们可以将数据隔离到一个新数据库中，而只是重定向连接字符串(它们不是硬编码的，对吗？对吗？)以指向演示数据库。这样，实时数据不会受到污染，并且代码看起来相同。实际上，我们以这种方式执行了一个三层部署系统，在该系统中，我们进行本地开发，部署到每隔几个月就有实时数据快照的QC环境中，然后在测试完成时部署到实时环境中。

我经常在某些类型的实时系统上看到它。
例如，超市中的销售点系统：收银员接受生产销售点终端的培训。

关键是要仔细识别测试或者培训数据。我不会说有任何明确的最佳实践可以在特定于应用程序的数据库中建模。

我们确实必须仔细定义测试/培训方案涵盖的范围。例如，我们不希望培训/测试事务显示在生产报告中(但我们可能希望能够使用此数据创建报告以用于培训/测试目的)。

FWIW，我们正在研究使用Oracle的行级安全性/虚拟专用数据库功能将演示数据与其余数据分开。

完全不同意乔。 Oracle有一个工具可以执行此操作，而与实现无关。在我阅读答案之前，我要说的是VPD ...但这可能会对生产产生影响。

记住查询中的每个表都从

SELECT * FROM tableA

到

SELECT * FROM (SELECT * FROM tableA WHERE Data_quality = 'PROD' <or however you do it>

每个表的策略是...

因此，假设测试数据必须跨越每个表，则每个表都必须具有策略，并且每个表都将被过滤，然后SQL才能开始工作。

我们甚至可以向用户隐藏该列。如果这样做，我们将需要编写一些灵巧的策略。我们必须根据插入数据的方式来创建该值，并将该列公开给某些管理员帐户以进行维护。