临时表快速指南

Question

我有一个结构化的数据库和软件来处理它，我想根据一个简单的模板版本设置一个演示版。我正在阅读临时桌上的一些资源，但我有疑问。

克隆＆＃34;临时＆＃34;的最佳方法是什么？数据库，同时保持一个干净的数据库列表？

根据我所见，有两种方法可以做到这一点 - 在会话结束时终止的临时本地版本，以及存储在数据库中的表，直到客户端删除或我

我想我更喜欢第二种选择，因为我希望能够看到他们用它做什么。但是，我不想添加大量的丢弃数据库并使我的系统混乱。

我如何 a）在30天之后安排删除和 b）如果可能的话，将这些全部保存在一个伞下，或者换句话说，是否存在一种方法可以将它们排除在我的主要数据库列表之外并自行分组。

我考虑过拥有一个数据库，然后使用用户的唯一ID和“faux索引”来提供信息。所以它看起来像1,2,3而不是556,557,558来解决B.除了添加 date 和 protected 之外，我不确定如何解决A问题。列和每天运行的脚本，如果超过30天而删除并且不受保护。

我为开放式问题道歉，但我发现的资源有点含糊不清。

Answer 1

在您的DBMS知道它们的意义上，这些不是真正的临时表。你正在寻找的是一种方法来对数据库进行演示复制，可能还有一个简化的数据集。它与您的数据库的任何其他非生产副本没有什么不同。

1. 请勿在生产数据库服务器上执行此操作。
2. 不要在生产数据库服务器上执行此操作。
3. 编写数据库架构的脚本。根据您使用的DBMS，这可能非常简单。如果您的系统有一个良好的开发/部署/维护过程，那么这应该已经存在。
4. 使用上一步中生成的脚本在非生产服务器上创建数据库。使用易于识别的命名约定，例如使用demo启动数据库名称。
5. 将所需数据加载到表格中。
6. 在此新数据库中指出您的应用程序的演示版本（在非生产服务器上运行）。
7. 创建一个脚本/进程/作业，查看您的数据库服务器并删除符合您的演示数据库命名约定的任何数据库，并且是在30多天前创建的。

如果没有关于您的实际环境的详细信息，人们就无法提供具体示例/示例代码/说明。

---

如果您无法为这些演示运行第二个独立的数据库服务器，那么您将不得不使用您的生产服务器。 这仍然是一个坏主意，因为潜在的安全风险和对生产数据库（受限资源）的性能影响。

• 为每个演示创建数据库的完整副本（或至少是架构，具有缩减的数据集）。
• 为每个演示数据库创建一组唯一的凭据。此帐户应该只能访问其演示数据库。
• 配置应用程序的演示实例以连接到演示数据库

这就是为什么我要为单独的数据库进行如此努力的原因：如果您继续在数据库中复制“演示”表，则每次执行新演示时都必须更新应用程序代码以指向这些表。一旦你开始这样做，你的演示就会冒很大的风险 - 你不断变化的代码不再是你在生产中运行的应用程序了。如果你错过了其中一个变化，你最多会得到意想不到的结果，最糟糕的情况是你的生产数据会被破坏。