数据库系统体系结构讨论

Question

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

我正在为拥有超过ca的数据库系统的公司工作。过去的10年。

让我试着来形容它在做什么，它是如何实现的：

该系统分为3支不同的球队处理的3个主要部分。

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

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

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

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

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

任何意见赞赏。

感谢 丹尼尔

Answer 1

从你说的话的声音，你有三个步骤。

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

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

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

Answer 2

为什么地球上你想现有的工作复杂的存储特效（可进行了性能优化）转换为LINQ（或我误解你）？因为你个人不喜欢t-sql？不是一个很好的理由。他们太慢了吗？然后他们可以调整（这是你真的不想尝试在LINQ中做的事情）。使用SSIS可以使流程变得更好，但是像SSIS一样复杂，重写流程需要时间，我不确定你是否真的能够获得任何收益。

“我莫名其妙地在这里失去了链接到面向对象的编程...”关系数据库不是面向对象的，如果你试图像对待他们不能表现良好。学习在访问数据库时不要考虑对象集。您一次只能从一个用户的思维模式中插入一条记录，但这不是处理大量数据传输的心态。对于这些类型的东西，使用数据库来处理问题比以面向对象的方式进行处理要好。一旦你有大量的数据和大量的报告，人们对性能的兴趣就会比过去你习惯的一些工具对性能不太好。无论您是否喜欢T-SQL，它都是SQL Server的本地语言，并且数据库已针对其使用进行了优化。

Answer 3

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

当前进程被组合 - 数据被加载并在Focus语言和聚焦（多个）数据库管理，然后报告（和历史数据被保留）

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

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

我不会做任何复杂系统的任何重新设计没有一个明确的战略，对现有系统的良好的库存和大量预算的时间和金钱的计划。之前已经在这里

Answer 4

最好的建议，是先学习如何SQL的作品，并在现有的架构的情况下做这件事，开始听起来像一个很好的方式开始（因为你所描述听起来没有什么非理性面对它。）

无论抽象你试图在上面铺设（LINQ，Biztalk的，等等）最终都解析为纯SQL。几乎总是会增加开销和复杂性。

您的面向对象范例不可转让。任何关于抽象的建议都需要基于对SQL后果的牢固掌握来坚定地保证。

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

Answer 5

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

Answer 6

你很难用别的方法来挫败BCP和SQL的性能。如果更新例程由于循环遍历表而变得很长并且臃肿，那么我确定我可以看到为什么你想要去.NET。但是你可能会想通过弄清楚如何将它们改写成很好并且基于SET来提高性能。 BCP不会被打败。当我使用SQL Server 2000时，BCP通常比DTS更快。一般情况下（由于所有数据类型检查）SSIS似乎比DTS慢。如果你杀了性能，毫无疑问，人们会来找你。尽管如此，如果你正在做大量的逐行复杂计算，将其优化为CLR存储过程或者甚至是从SQL Server调用来执行处理的.NET应用程序可能会导致加速。当然，如果你是行处理，并且你设法重写查询来进行集合处理，你可能会得到更快的速度。但取决于.NET可能对计算有多复杂。

现在，如果前端的变化可以立即更新和传播数据，那么你可能要改变的东西。这样，只要一行被更改，就可以重新计算并更新所有的客户端。但是，如果很多行被更改或者数据库只是巨大的，那么你会杀死性能。如果操作需要大批量完成，那么目前正在进行的操作方式可能是最好的。

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

下面是一个例子，我经常看到加载数据仓库

假设一些行表装载有来自源

选择更改的行从源到临时表
数据查看是否有任何列，其事情发生了变化
如果是终止现有的行（或它克隆到一些历史表）
插入/更新新行

我经常看到一个O f每个表的查询，唯一的变化是表/列名称和可能引用的关键字列。您可以很容易地从SQL Server中获得列定义和密钥定义，然后创建一个.NET程序来创建INSERT/SELECT/ETC。在最糟糕的情况下，您可能需要在TABLE_NAME中存储某种类型的表，COLUMN_NAME表示重要的列。然后，您不需要围绕复杂的ETL过程和20或200个更新查询来打包头，只需要将头绕在UPDATE和一个查询上即可。任何对事情完成方式的改变都可以完成一次并应用于所有查询。

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