可能有一个名字。请适当地重新称名

Question

我正在评估构建一组持久用户输入的通用数据库表的想法。然后将有一个辅助流程来启动工作流程并处理输入。

这个想法是保存初始用户输入的概念与处理分开，并将其放入特定应用程序的结构化模式中。

一个例子可能是某种工作申请或有开放式问题的测验。如果没有人为的分类，原始答案对我们来说对于汇总报告来说并不是非常有价值。但是，我们确实希望将原始输入存储为历史记录。

我们可能还希望用户能够部分填写一些信息并将其保留，直到他返回。

在我们拥有所有数据之前，可能无法将所有输入处理到我们可以将其放入特定于应用程序的数据模式的位置。

两个初步问题：

1. 假设这个概念有一个名字，它是什么？
2. 这是一种合理的方法吗？为什么或为什么不呢？

更新

这是陈述这个想法的另一种方式。用户按顺序填充DTO中的字段。我（我想）我想将DTO保存到磁盘，即使处于部分完成状态。一旦用户完成填充字段，我想拉出DTO并将其处理为结构化保存到代表特定DTO的表中。但是，我不能保存部分完整或（更糟）暂时不正确的输入集，因为某些输入实际上不应存储为结构化记录的一部分。

我的想法是创建一些通用方法来保存任何类型的DTO，然后根据需要将它们拉出来以便在特定应用中进行处理。因此，这个通用DTO表可能会在新帐户设置向导中回答的问题旁边存储与客户满意度调查相关的数据。

Answer 1

你说：

  

我的想法是创建一些通用的方法来保存任何类型的DTO，然后根据需要将它们拉出来在特定的应用程序中进行处理。

我认为你是一个关闭的程度。我认为整个数据库正在履行你想要一组有限的表来执行的角色。您可以创建某种复杂的存储架构，它不会以任何方式表示数据，然后（从DBMS的角度来看，缓慢而痛苦地）合并并呈现数据视图......但我建议这是过度设计的解决方案。

我编写了几个应用程序，由于自定义用户要求，应用程序的（有时很重要的）部分是动态的 - 由用户构建，从架构到业务规则。通过执行诸如CREATE TABLE和ALTER TABLE之类的语句来制造存储模式的那些令人惊讶地是最容易维护的。它们还允许用户以非常直接的预期方式创建报告。

Answer 2

您可能正在谈论工作流程。您可能需要查看Windows Workflow。

工作流的概念是它们反映了现实生活的过程。也就是说，您完成了一个文档，但在批准之前该文档是不完整的。在您的情况下，这将是“输入数据”但未分类，因此它存储在数据库中（脱水），并为需要处理该问题的任何人发送标记。只要有必要，它就可以在这种状态下持续存在。一旦有人能够处理它，工作流程将再次启动（补充水分）并继续执行下一步。

以下是有关工作流程的一些问题：

这个问题：“Is it better to have one big workflow or several smaller specific ones?”清除了工作流程的一些使用方式，并突出了它的一些问题。

约翰·桑德斯（John Saunders）对this question中的工作流程有很好的细分。

Answer 3

听起来你最初以规范化的形式存储数据（通用），一旦你拥有了完整的集合，你就会对它进行非规范化（结构化模式）。