数据库系统架构讨论

Question

我想开始讨论数据库系统的实现。

我正在为一家拥有数据库系统的公司工作。过去十年。

让我试着描述它正在做什么以及它是如何实现的：

系统分为3个主要部分，由3个不同的团队处理。

1. 项： Entry团队负责为系统创建GUI。在后台是一个巨大的MS SQL数据库（大约100个表），GUI是使用.NET创建的。有不同的GUI应用程序，每个应用程序都有许多不同的选项卡来填充相应的表。如果是将新列添加到数据库中，将此列手动添加到GUI应用程序。

2. 数据流： 数据流团队的目的是进行数据计算并为报告团队准备数据。这是通过多个级别完成的。让我尝试更详细地解释一下这个过程：Dataflow团队使用Entry数据库中的数据通过Transactional-Replication复制到另一个服务器和另一个数据库（此数据包含来自所有客户端的信息）。然后每小时一次，自编写的应用程序检查输入表中的已更改行（使用ChangedDate列），然后为每个输出表调用存储过程，使用输入表的1-N计算新数据。之后，再次使用Transaction-Replication将数据复制到另一台服务器上的另一个数据库。这里调用另一个存储过程来计算其他新的输出表。使用SQL作业启动此存储过程。从那里数据被分成不同的数据库，每个数据库都是客户特定的。使用.NET bulkcopy命令（在客户端上过滤）使用另一个自编写的应用程序完成此复制。这些客户特定数据库通过另一个自编应用程序复制到其他服务器上的不同客户端特定报告数据库，该应用程序将报告数据库与客户特定数据库进行比较以计算数据差异。只复制数据差异（因为报告数据库以前在客户端服务器上运行）。 整个过程由另一个自编的应用程序编排，以控制例如如果在启动作业之前完成事务复制以调用存储过程等...此外，还在此处编排了不同客户端之间的同步。该过程可以通过自编的监控工具以图形方式显示，该工具看起来非常复杂，您可以想象...... 记录所有这些组件的状态，并可以由另一个自编写的应用程序查看。 如果添加了新列或表，则必须手动更改所有这些组件。 对于部署，安装说明使用MS Word编写。 （大约10人在这个团队中工作）

3. 报告： 报告团队创建了自己的.NET平台，允许客户通过GUI创建自定义报告。报告可通过网络访问。

最大的表有大约100万行。所以，我希望我没有忘记任何重要的事情。

嗯，我想讨论的是其他人如何实现这种情况，我无法想象每家公司都会编写自己的自定义应用程序。 实际上允许在数据库上快速计算的可能性（使用T-SQL旁边）。我在某种程度上错过了我以前从我的老公司那里习惯的面向对象编程的链接，但是我们从来没有处理过这么多的数据，也许是为了快速计算这就是这样做的方式...或者它是否可能使用例如LINQ或BizTalk Server创建算法和计算，甚至可能以图形方式？问题是如何将现有的米长存储过程转换为新格式... 将来我们希望使用数据仓库，但这需要一段时间，因此可能有一个单独的步骤来简化流程。

感谢任何评论。

由于 丹尼尔

Answer 1

为什么你想将现有的工作复杂存储过程（可以通过性能调整）转换为LINQ（或者我误解了你）？因为你个人不喜欢t-sql？不是一个足够好的理由。他们太慢了吗？然后可以调整它们（这是你真的不想在LINQ中尝试做的事情）。使用SSIS可以更好地完成这个过程，但是像SSIS一样复杂以及重写过程需要的时间，我不确定你真的会通过这样做获得任何东西。

“我在某种程度上错过了面向对象编程的链接......”关系数据库不是面向对象的，如果你试图像对待它们一样对它们表现不佳。学习在访问数据库时考虑集合而不是对象。您一次只能插入一个记录，从一个用户的心态出发，但这不是处理大量数据传输所需的思维方式。对于这些类型的事物，使用数据库来处理问题比以面向对象的方式做事更好。一旦您拥有大量数据和大量报告，人们对性能的兴趣远远超过过去使用某些可能对性能不太好的工具时的习惯。无论您是否喜欢T-SQL，它都是SQL Server的本地语言，并且数据库已根据其使用进行了优化。

Answer 2

以前最好的建议是首先要先了解SQL的工作原理，然后在现有架构的上下文中进行操作听起来像是一个很好的开始方式（因为你所描述的一切都听起来不合理面对它。）

无论你试图放在哪个抽象（LINQ，Biztalk，等等），最终都会解析为纯SQL。而且几乎总是会增加开销和复杂性。

您的OO范例不可转让。基于您对SQL后果的牢固把握，任何有关抽象的建议都需要牢固地防范。

需要一段时间，但无论是专业还是个人，都值得了解。

Answer 3

我目前正在重新设计一个复杂的系统，该系统正从Focus（数据库和语言）转移到数据仓库（单独的团队）和处理（我的团队）和报告（单独的团队）。

结合当前流程 - 在Focus语言和Focus数据库中加载和管理数据，然后报告（并保留历史数据）

在新流程中，DW已加载，然后我们的流程开始。我们的进程完全用SQL编码，百万行事实表（一个月）相对较小。我们有一些Feed，每月数据为2500万行。有一些统计表生成超过2亿行（一个月）。处理可能每个月需要几个小时，端到端。我们使用表来存储中间结果，并确保索引策略适合于处理。除了由于标量UDF性能极差而从数据库实现的SSIS流程之外，整个系统实现为一系列T-SQl SP。

我们还有一个类似于您正在讨论的流程监控系统，并且在表中具有依赖关系，以确保每个流程仅在满足所有先决条件时运行。我最近嫁接了MSAGL，以图形方式显示并与.NET Windows应用程序中的流程（之前我使用graphviz生成静态图像）进行交互。因此，新系统具有更清晰的依赖性信息以及关于过程性能的良好信息，因此可以将精力集中在最慢的性能瓶颈上。

如果没有明确的策略，现有系统的良好库存以及大量的时间和金钱预算，我不会计划对任何复杂系统进行任何重新设计。

Answer 4

从你所说的话来看，你有三个步骤。

1. 输入数据
2. 分析数据
3. 报告数据

第一步和第三步需要由“用户”完成。因此，每个相应的团队需要一个GUI来完成手头的任务，否则，他们将直接在SQL Server上工作，并且需要大量的SQL知识。对于这些项目，我认为您的组织采用的方法没有任何问题，您正在构建一个自定义系统来报告手头的数据。在这方面可能值得考虑的唯一项目是公共团队和所用技术之间的标准化。

你的中间步骤似乎有点冗长，有许多活动部件。但是，我已经在一些大型报告系统上工作，这是真正解决它的唯一方法。不了解您的组织和操作的确切性质。

Answer 5

通过“快速计算”，您必须意味着“快速检索”数据仓库（包括关系数据仓库和其他数据仓库）在数学方面都很快，因为答案是事先预先计算的。 SQL，除非你使用的是CLR存储过程，否则在数学方面通常会相当慢。

Answer 6

你很难用其他任何东西来击败BCP和SQL的性能。如果更新例程很长并且因为它们循环遍历表而变得臃肿，那么我确定可以看到为什么要转到.NET。但是你可能会通过弄清楚如何将它们全部重写并基于SET来提高性能。 BCP不会被打败。当我使用SQL Server 2000时，BCP通常比DTS快。一般而言SSIS（由于所有数据类型检查）似乎比DTS慢。如果你杀了表演，毫无疑问人们会来找你。如果您正在进行大量逐行复杂计算，那么将其优化为CLR存储过程甚至是从SQL Server调用以进行处理的.NET应用程序，可能会加快速度。当然，如果你是行处理，并且你设法重写查询来进行设置处理，你可能会获得更大的加速。但是根据计算的复杂程度，.NET可能有所帮助。

现在，如果前端更改可以立即更新和传播数据，那么您可能希望将内容更改为.NET，以便一旦更改行，就可以重新计算并更新所有客户端。但是，如果更改了很多行，或者数据库只是巨大的，那么你将会扼杀性能。如果操作需要批量完成，那么可能当前正在进行的方式是最好的。

我唯一可能的是，可能有很多重复的SQL看起来完全相同，除了表名和/或列名。如果是这样，你可以使用.NET结合SQL-SMO（或DMO，如果使用SQL Server 2000）来代码生成它。

这是我经常看到加载数据仓库的一个例子

假设某些行表加载了来自源

的数据

从源中选择已更改的行到临时表中 看看是否有任何重要的列被更改了 如果这样终止现有行（或将其克隆到某个历史表中）
插入/更新新行

我经常在每个表中看到其中一个查询，唯一的变化是表/列名称，也可能是对键列的引用。您可以轻松地从SQL Server中获取列定义和键定义，然后创建一个.NET程序来创建INSERT / SELECT / ETC。在最糟糕的情况下，您可能只需要存储某些类型的表，其中包含TABLE_NAME，COLUMN_NAME用于重要的列。然后，您不必围绕复杂的ETL过程和20或200个更新查询，而只需要围绕UPDATE和一个查询。对事情的完成方式的任何改变都可以完成一次并应用于所有查询。

特别是我的猜测是，如果您尚未将此技术应用于各个客户端数据库。除数据库/服务器名称外，所有查询/批量复制脚本可能相同或几乎相同。所以你可以根据CLIENTs表或其他东西自动生成它们......