问这是一个好的数据库设计还是过渡？数据仓库的规范化到非规范化

EN

(目前为中等尺寸)

在讨论数据大小时，您应该比这更精确。像小/中/大这样的通用词对不同的人来说意味着不同的东西，尽管在这种情况下它可能并不重要。

将来，我们计划把这个数据库变成一个数据仓库。

您不应该将应用程序数据库转换为数据仓库--为正常的实时应用程序使用优化应用程序数据库，并将数据输入仓库数据库进行脱机分析。

然而，在数据仓库中，不完全需要规范化。

对，是这样。仓库解决方案通常以各种方式显式取消，以使某些报表更容易高效地生成(特别是通过自动化工具和相对不熟练的用户)。

比如从规范化表中提取数据并将其放入一个新的数据库中，并使用非规范化表？

一般来说，这是一条路可走。

为应用程序的主要工作流程和数据正确性(即保持正常状态以避免由于设计问题或其他错误导致的数据不一致)优化活动数据结构，并使用某种形式的ETL流程从这些应用程序数据库构建和更新(或重建)您的仓库。生产数据库中的活的、正常的形式、数据是您的真实来源，如果出了问题，您可以从这里重建仓库。仓库不应该存在于一个应用程序实例的数据库中，因为以后您可能希望将来自多个应用程序(和/或同一应用程序的多个实例)的数据组合到仓库中，而活动应用程序和大型报告任务的不同IO和锁定要求通常意味着要将这些任务保持独立，而不是争夺资源。

当然，这方面也有例外，一切都是如此。例如，您可能希望在应用程序中实时报告一些数据，例如，尽管在这种情况下，您仍然需要为数据一致性和应用程序的主要活动优化核心应用程序表，以及从该真相来源构建/更新/重建报告结构。