标签: reporting

我正在尝试为员工时间记录完成一些报告。

我们有两个专门针对这个问题的表格。员工列在Members表中，他们每天输入他们已完成工作的时间条目并存储在Time_Entry表中。

使用 SQL Fiddle 的示例设置：http ://sqlfiddle.com/#!3/e3806/7

最终的结果我要的是一个表，表示所有的Members列中的列表，然后将展示他们的总和小时，在其他列查询的日期。

问题似乎是，如果Time_Entry表中没有特定成员的行，那么该成员现在有行。我尝试了几种不同的连接类型（左、右、内、外、全外等），但似乎都没有给我想要的，这将是（基于 SQL Fiddle 中的最后一个示例）：

/*** Desired End Result ***/

Member_ID   | COUNTTime_Entry | TIMEENTRYDATE | SUMHOURS_ACTUAL | SUMHOURS_BILL
ADavis      | 0               | 11-10-2013    | 0               | 0
BTronton    | 0               | 11-10-2013    | 0               | 0
CJones      | 0               | 11-10-2013    | 0               | 0
DSmith      | 0               | 11-10-2013    | 0               | 0
EGirsch     | 1               | 11-10-2013    | 0.92 …

我们正在尝试优化数据仓库设计，该设计将支持针对多个时区的数据进行报告。例如，我们可能有一份一个月的活动（数百万行）的报告，需要显示按一天中的小时分组的活动。当然，一天中的那个小时必须是给定时区的“本地”小时。

当我们只支持 UTC 和一个本地时间时，我们的设计运行良好。UTC 和本地时间的日期和时间维度的标准设计，ID 在事实表上。但是，如果我们必须支持 100 多个时区的报告，那么这种方法似乎无法扩展。

我们的事实表会变得很宽。此外，我们必须解决 SQL 中的语法问题，即指定在任何给定的报告运行中使用哪个日期和时间 ID 进行分组。也许是一个非常大的 CASE 语句？

我已经看到一些建议，可以通过您所覆盖的 UTC 时间范围获取所有数据，然后将其返回到表示层以转换为本地并在那里聚合，但是使用 SSRS 进行的有限测试表明这将非常慢。

我也查阅了一些关于这个主题的书籍，他们似乎都说只有 UTC 和转换显示或有 UTC 和一个本地。将不胜感激任何想法和建议。

注意：此问题类似于：处理数据集市/仓库中的时区，但我无法评论该问题，因此觉得这值得自己提出问题。

更新：在Aaron 进行了一些重大更新并发布了示例代码和图表后，我选择了他的答案。我之前对他的回答的评论不再有意义，因为他们提到了答案的原始编辑。如果有必要，我会尝试回来并再次更新

我是一家小型（约 50 名员工）SaaS 公司的 SQL 开发人员（不是 DBA 或架构师）。我的任务是弄清楚如何：

1. 从我们的 100 多个 OLTP 数据库卸载运营报告
2. 允许这些报告针对来自多个客户端数据库的数据运行
3. 我们公司的定位是在未来提供更多基于分析的解决方案

我已经阅读了许多关于各种技术的文章，例如事务复制（特别是多对一/中央订阅者模型）、SQL 服务代理、日志传送、变更跟踪 (CT) 和变更数据捕获 (CDC，我的理解是这仅适用于企业），我不确定最好采用哪种路径。

我希望你们中的一些具有集成专业知识的人可能遇到过与我们类似的设置，并能够为我指明一条成功的道路或指导我找到一些有用的资源。

由于成本限制，我们的解决方案必须适用于 SQL Server 标准版。此外，解决方案必须合理以在我们的小型组织内支持/维护。

基本配置：

我们目前有 100 多个单独的客户端数据库，大多数部署在我们数据中心的 SQL 服务器上，但有些部署在我们可以远程访问的数据中心内的客户端服务器上。这些都是 SQL Server 2008 R2 数据库，但我们计划很快升级到 SQL 2016。

我们使用数据库项目和 dacpac 来确保架构在将要集成的所有客户端数据库中是相同的。但是，由于我们不会强制所有客户端同时升级到新版本，因此升级之间可能存在一些架构差异。如果客户端 A 的软件版本为 1.0 而客户端 B 的版本为 1.1，则解决方案必须足够灵活，不会中断。

操作报告目前直接从每个客户的 OLTP 数据库运行。如果我们不卸载它，我们担心这会对应用程序的性能产生影响。

高级要求：

我们的客户是医院无菌处理部门 (SPD)，他们希望获得有关他们迄今为止处理的内容、库存在哪里等的最新报告。 SPD 全天候处理库存，包括周末和节假日。由于这项工作的主要目的之一是更好地支持运营报告，我们希望数据尽可能接近实时，以继续满足客户的需求。

目前，我们在不同的数据库中有一些 SPD，它们实际上是同一医院系统的一部分。这些客户希望能够针对其系统中的所有 SPD 进行报告。

从战略上讲，我们希望能够轻松汇总所有客户的数据，以支持我们的内部分析计划。我们的期望是我们能够将收集到的运营数据用作数据集市/仓库的来源。

思念至今：

事务复制似乎会提供最“实时”的解决方案。我发现此回复特别有用，但我担心潜在的架构差异对我们不起作用：SQL Server 多对一复制

考虑到在查询处于活动状态时日志无法恢复，日志传送听起来并不理想。我要么必须把每个人都踢出去，以便日志可以恢复，否则数据将变得陈旧。我不清楚这种方法是否可以用于集中来自多个数据库的数据，因为每个传送的日志只会用于它来自的单个数据库。

使用 SQL 服务代理，如果队列无法跟上要处理的消息数量，则延迟可能无法预测。

CT 只为每个表行标识一个版本。延迟取决于我们对每个数据库处理 SSIS 包之类的东西以检索数据并将其插入中央存储库的速度。

我们是否需要考虑单独复制每个数据库，然后可能使用某种数据虚拟化技术来组合来自各种复制源的数据？

您愿意提供的任何建议或方向将不胜感激。

我继承了一个应用程序，它将许多不同类型的活动与一个站点相关联。大约有 100 种不同的活动类型，每一种都有不同的 3-10 个字段集。但是，所有活动都至少有一个日期字段（可以是日期、开始日期、结束日期、预定开始日期等的任意组合）和一个负责人字段。所有其他字段差异很大，开始日期字段不一定称为“开始日期”。

为每个活动类型制作一个子类型表将导致一个包含 100 个不同子类型表的模式，这将过于笨拙而无法处理。该问题的当前解决方案是将活动值存储为键值对。这是当前系统的一个大大简化的架构，可以理解这一点。

每个Activity有多个ActivityFields；每个 Site 有多个 Activity，SiteActivityData 表存储每个 SiteActivity 的 KVP。

这使得（基于 Web 的）应用程序非常容易编写代码，因为您真正需要做的就是遍历 SiteActivityData 中给定活动的记录，并为表单的每一行添加一个标签和输入控件。但是有很多问题：

• 诚信不好；可以在 SiteActivityData 中放置一个不属于活动类型的字段，而 DataValue 是一个 varchar 字段，因此需要不断转换数字和日期。
• 对这些数据进行报告和临时查询很困难、容易出错且速度缓慢。例如，获取结束日期在指定范围内的某种类型的所有活动的列表需要数据透视并将 varchars 转换为日期。报告作者讨厌这种模式，我不怪他们。

所以我正在寻找一种方法来存储大量几乎没有共同字段的活动，从而使报告更容易。到目前为止，我想出的是使用 XML 以伪 noSQL 格式存储活动数据：

Activity 表将包含每个活动的 XSD，从而无需 ActivityField 表。SiteActivity 将包含键值 XML，因此站点的每个活动现在都在一行中。

一个活动看起来像这样（但我还没有完全充实它）：

<SomeActivityType>
  <SomeDateField type="StartDate">2000-01-01</SomeDateField>
  <AnotherDateField type="EndDate">2011-01-01</AnotherDateField>
  <EmployeeId type="ResponsiblePerson">1234</EmployeeId>
  <SomeTextField>blah blah</SomeTextField>
  ...

好处：

• XSD 将验证 XML，捕获错误，例如在数据库级别将字符串放入数字字段中，这对于将所有内容存储在 varchar 中的旧模式来说是不可能的。
• 用于构建 Web 表单的 KVP 记录集可以很容易地使用 select ... from ActivityXML.nodes('/SomeActivityType/*') as T(r)
• XML 的 xpath 子查询可用于生成包含开始日期、结束日期等列的结果集，而不使用数据透视表，例如 select ActivityXML.value('.[@type=StartDate]', 'datetime') as StartDate, …

将数据库快照用于报告目的的性能优势是什么？

在我看来，它可能会降低性能，因为对于原始数据库中的每次写入，都必须为快照本身进行另一次写入。

我可以看到，只要您想报告当时为止的数据，就会使用快照，但这不属于性能类别。

再说一遍，有性能优势吗？

我想将表中的值抓取到同一表中不同值的两个不同列中。使用此查询作为示例（注意选择是如何在别名为 2 个不同表的同一个表上的）：

SELECT a.myVal, b.myVal 
FROM MyTable a, MyTable b
WHERE 
  a.otherVal = 100 AND
  b.otherVal = 200 AND
  a.id = b.id

当我在我的数据集上运行这样一个相对简单的查询时，它可以工作 - 只是需要很长时间。有没有更好/更聪明的方式来编写这个查询？

我正在寻找有关如何处理环境报告的建议。我们目前拥有 16 台服务器，其中包含 20 个 SQL Server 2005 实例。我们拥有 6,600 多个数据库，并且在这些实例中不断增长（每个客户 1 个数据库）。我们的大多数数据库运行的大小从 200 mb 到 7gb，其中大约 60 个数据库运行的最大大小从 11GB 到 110gb。

我们正在使用 SAN 进行存储，但在运行影响 IO 的报告时遇到了问题。

我们的一个想法是拉取 60 个更大的数据库，然后使用事务复制来复制这些数据库并在副本上运行报告。

这将使所有较小的数据库在没有较大数据库压力的情况下运行。在未来，我们相信不会再有基于我们公司目标的更大的数据库。

有什么想法吗？

我们当前的设置是生产中使用的主要数据库，带有用于 HA 的手动故障转移镜像数据库。

我还需要设置一个报告数据库。最好的方法是什么？我应该设置一个 SQL 作业来删除和创建镜像数据库的快照并每晚刷新吗？

有没有人有其他建议？

谢谢

我们从开发组那里得到了一个要求，要执行以下操作：

• 经常（每 30 分钟）将事务数据从实时数据库移到另一个数据库
• 辅助数据库将用于 Ad-Hoc 查询和报告
• 如果数据从实时数据库中删除，他们不想从这个辅助报告数据库中删除数据

我们的数据库服务器在 SQL Server 2012 企业版上。

这将确保最终用户不会查询实时数据，从而导致阻塞问题。开发人员将在不久的将来致力于获取分析数据，但他们希望快速实施一些措施以使实时数据尽可能小。

实现这一目标的建议是什么？

谢谢，

生命值

我正在尝试解决一个问题，即 SSRS 报告对于当天的初始查询很慢。我尝试使用此处描述的解决方案：

解决关于 SSRS 2008 的第一个长启动报告的问题

……无济于事。我知道这似乎是 SSRS 问题，但我不确定是否有针对此行为的其他解决方法。它使用 Microsoft 的 ServerReport.Render 方法来呈现报告并将其转储为 PDF。

来自评论的澄清：

我创建了一个类似于博客中的脚本。我在工作日开始前的下班时间运行了该脚本。我还在 PowerShell 中逐行手动运行脚本，这似乎确实缓解了这个问题；然而，这可能只是一种安慰剂，因为分配给这个问题的 QA 再次报告了缓慢。

我已经手动运行了报告，并且在初始报告查询中遇到了相同程度的缓慢。

我确实有一项每天在开始营业前运行的任务。我使用以下行创建了调度程序：

schtasks /create /tn "SSRS Recycle" /ru UserName /rl highest /np /sc daily
    /sd 08/01/2011 /st 02:00 /tr "powershell.exe -noprofile 
    -executionpolicy RemoteSigned -file c:scriptsSSRSRecycle.ps1"

路径是否区分大小写？我的脚本文件被命名为脚本。另外，路径名中是否需要斜线？