使用复杂的 SQL Server 数据库架构

Question

我有一个数据库，我必须保持与 SQL Server 2005 的兼容性，并且我一直在考虑降低复杂性和处理性能问题的方法。

我的数据库与大多数其他数据库一样，充满了数据，其中包含大量数据并且有很多查询。我有许多存储过程一直在发展（一段时间以来）以满足业务需求。这基本上没问题，但是我遇到了性能问题，而且我的查询变得越来越复杂，难以管理。

乍一看，我不认为我的数据模型有什么问题，它没有荒谬地规范化（我们已经对一些东西进行了非规范化），但我发现自己无法编写和运行那些用于供电的极快查询我的 Web 界面 AJAX 查询，因为所有的约束似乎有些随意地到处存在。

所以，我已经考虑过了，我想我想将我的数据库组织成环。让我解释一下。

• 基本上，在最内圈，你会发现最专业的 数据集。这些表是完全非规范化的，并且已经 通过聚合来自外环的数据来构建，以确保特定 查询运行速度非常快。

• 最外面的环在理想情况下是“哑”的，基本上只是一个真正的 放东西的地方不好。

• 外部和内部之间基本上是您的概念模型，这些 从其他环拉或推到内环，这是 您在哪里清理数据并确保其正确无误。

• 数据只能从外环流向内环。

• 我不想使用触发器来保持不同的环保持一致，而是我有一个服务和作业，它们会定期侦听、轮询和运行以确保最终的一致性，一刀切。

现在，我在这里寻求建议，并希望从有经验的数据库人员那里获得一些意见。我相信我可以通过这种方式从我的数据库中获得更多收益。它将使我能够解决不同阶段的复杂性和性能问题。也许我正在做的事情有一个共同的名字，或者这就是 NoSQL 运动的全部意义所在，但我真的不知道，这个想法对我有一些吸引力，但如果我在那里，我'在我犯错之前想听听...

Answer 1

虽然我基本上同意@TomTom 的回答，但我会换一种说法：您基本上已经自行开发了数据仓库（或具体来说是数据集市）的概念。买一本关于数据仓库的书是个好主意。参加有关该主题的研讨会或系列课程会更好。显然，您已经对此进行了一些认真的思考，当您了解最佳实践和已开发的不同方法时，这对您很有帮助。

Answer 2

您需要一本数据库入门书籍。严重地。将其拆分为 OLTP 和 OLAP 部分——数据仓库是有序的。摆脱存储过程。然后意识到您的“大量 odata”可能是其他人的“数据笑话”——我在一个应该扩展到大约 60tb 数据（即 60.000）的系统上工作——我们的初始硬件有 21.000 GB。

您的系统听起来像是将普通数据库 (OLTP) 与数据仓库混为一谈。拆分它们 - 这不起作用。也将它们拆分为硬件。这是完整的标准 - 一本关于数据仓库的书。