我目前正在设计vb.net中的应用程序以使用访问后端数据库。我一直在努力想办法减少数据冗余 我在下面有一个示例场景：
让我们想象一下，为了示例目的，我有一个客户表，需要突出显示WI的所有客户并给他们发信。客户表会 包含与客户关联的所有客户和属性（名称，地址等），因此我们将查询表中状态为“WI”的位置。然后我们会 获取该数据的结果，并将其附加到带有“完成”指示符的表中（因此，从“客户”到“WI_LETTERS”表）。
让我们假设需要进行一些处理，所以当它完成时，将该表中的字段标记为“完成”，然后允许打印字母 邮件合并。 （从'WI_LETTERS'中选择指示符=完成）。
该项目现已完成并完成。但是，让我们说，每个奇怪的一年（2013年）我们也会向表中的每个人发送一个通知状态为“WI”的通知。我们现在查询了 当年份为奇数且客户的状态为“WI”时，客户表。然后将该数据附加到名为“通知”的表中，并带有完成指示符 它标记为完整。
这似乎使数据“基于任务”，因为数据完全基于手头的任务。但是，这不是多余的数据吗？这种设置意味着那里
可以是多个帐户的一种交易类型（甚至是年复一年到同一帐户的多次），但不应该是多个交易的一个帐户？
这个设计如何变得更好？
答案 0 :(得分：1)
您当然不希望开始为执行的每个任务创建新表。如果您需要跟踪的信息（以及这些表中的列）在不同的信息之间存在很大差异，您可能希望为不同的 类型任务创建几个不同的表任务类型，但这些表应该用于该特定类型的所有任务。您可以在这些表中维护一个字段，以标识每条记录适用的单个任务（例如，Marketing campaign mailouts的[campaign_id]，或[mail_batch_id]或类似）。
< / LI>您肯定不想开始创建像[WI_letters]这样的新表，这些表由State（或任何客户端属性）隔离。您已在[Customers]表中拥有客户状态，因此[Letters]表中您需要的唯一客户相关属性是[CustomerID]。如果您经常希望在威斯康星州查看“客户信函”列表，那么您始终可以创建一个名为[WI_Letters]的已保存的Query（在其他数据库系统中通常称为View），看起来像
SELECT * FROM Letters INNER JOIN Customers ON Customers.CustomerID = Letters.CustomerID Customers.State =“WI”