Questions tagged «reporting»

2
SQL连接查询以显示一个表中不存在行的行
我正在尝试完成一些有关员工时间记录的报告。 我们有两个专门针对此问题的表格。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 …

3
寻找有关如何将100多个客户数据库中的数据集成到集中式报告数据库中的建议
我是一家小型SaaS公司(约50名员工)的SQL开发人员(不是DBA或架构师)。我的任务是弄清楚如何: 从我们100多个OLTP数据库中卸载运营报告 允许这些报告针对来自多个客户端数据库的数据运行 定位我们的公司以在将来提供更多基于分析的解决方案 我已经阅读了许多有关各种技术的文章,例如事务复制(特别是多对一/中央订户模型),SQL服务代理,日志传送,变更跟踪(CT)和变更数据捕获(CDC),我的理解是这仅适用于企业),我不确定最好采用哪种方法。 我希望一些具有集成专业知识的人可能会遇到与我们类似的设置,并且能够指出成功的道路或将我引向一些有帮助的资源。 由于成本限制,我们的解决方案必须在SQL Server Standard Edition中运行。另外,解决方案必须合理,才能在我们的小型组织内提供支持/维护。 基本配置: 目前,我们有100多个单独的客户端数据库,大多数部署在我们数据中心的SQL服务器上,但是有些部署在我们数据中心内的客户端服务器上,我们可以远程访问这些数据库。这些都是SQL Server 2008 R2数据库,但是我们计划很快升级到SQL 2016。 我们使用数据库项目和dacpacs来确保所有要集成的客户端数据库中的架构都是相同的。但是,由于我们不强制所有客户端同时升级到新版本,因此升级之间可能会存在一些架构差异。如果客户端A在软件版本1.0上并且客户端B在软件版本1.1上,则解决方案必须足够灵活,以免损坏。 当前,操作报告直接从每个客户端的OLTP数据库运行。如果我们不卸载应用程序,则会担心它会对应用程序性能产生影响。 高级要求: 我们的客户是医院无菌处理部门(SPD),他们需要有关其到目前为止所处理的内容,库存在何处等的最新报告。SPD每天(包括周末和节假日)的过程库存。由于这项工作的主要目的之一是更好地支持运营报告,因此我们希望数据尽可能接近实时,以继续满足客户的需求。 目前,我们在单独的数据库中有一些SPD,这些数据库实际上是同一医院系统的一部分。这些客户希望能够针对其系统中的所有SPD进行报告。 从战略上讲,我们希望能够轻松汇总所有客户的数据以支持我们的内部分析计划。我们的期望是,我们将能够使用收集到的运营数据作为数据集市/仓库的来源。 思念至今: 事务复制似乎将提供最“实时”的解决方案。我发现此响应特别有用,但我担心由于存在架构差异的可能性,因此对我们不起作用:SQL Server多对一复制 鉴于查询活动时日志无法还原,日志传送听起来并不理想。我要么将所有人踢出去,以便可以恢复日志,否则数据将变得过时。我不清楚该方法是否可用于集中多个数据库中的数据,因为每个出厂的日志仅适用于它来自的单个数据库。 使用SQL Service Broker,如果队列无法跟上要处理的消息数量,则延迟可能是不可预测的。 CT仅为每个表行标识一个版本。延迟时间取决于我们对每个数据库处理诸如SSIS包之类的东西以检索数据并将其插入中央存储库的速度。 我们是否需要考虑分别复制每个数据库,然后使用某种数据虚拟化技术来组合来自各种复制源的数据? 您愿意提供的任何建议或指示将不胜感激。

2
数据仓库设计,用于针对多个时区的数据进行报告
我们正在尝试优化数据仓库设计,以支持针对许多时区的数据进行报告。例如,我们可能有一个关于一个月活动的报告(数百万行),该报告需要显示按一天中的小时分组的活动。当然,一天中的那个小时必须是给定时区的“本地”小时。 当我们仅支持UTC和一个本地时间时,我们的设计效果很好。事实表上的UTC和本地时间的日期和时间维度的标准设计。但是,如果我们必须支持100多个时区的报告,则该方法似乎无法扩展。 我们的事实表将变得非常广泛。另外,我们还必须解决SQL中的语法问题,即指定在报告的任何给定运行中使用哪个日期和时间ID进行分组。也许是一个非常大的CASE语句? 我已经看到了一些建议,可以按您覆盖的UTC时间范围获取所有数据,然后将其返回到表示层以转换为本地并在那里进行汇总,但是使用SSRS进行的有限测试表明这将非常慢。 我也参考了一些有关该主题的书籍,它们似乎都说只有UTC并可以进行转换,或者只有UTC和一个本地语言。将不胜感激任何想法和建议。 注意:此问题类似于:在数据集市/仓库中处理时区,但是我无法对此问题发表评论,因此感到这是值得的。 更新:在 Aaron进行了一些重大更新并发布了示例代码和图表之后,我选择了Aaron的答案。我先前对他的答案的评论不再有意义,因为它们涉及答案的原始编辑。如果有必要,我会尝试再次更新此内容

1
有效地存储键值对的集合,这些键值对具有完全不同的键
我继承了一个将许多不同类型的活动与站点相关联的应用程序。大约有100种不同的活动类型,每一种都有3-10个字段的不同集合。但是,所有活动至少都有一个日期字段(可以是日期,开始日期,结束日期,预定开始日期等的任意组合)和一个负责人字段。所有其他字段的差异很大,开始日期字段不一定称为“开始日期”。 为每种活动类型创建一个子类型表将导致具有100个不同子类型表的模式,这太麻烦了以至于无法处理。该问题的当前解决方案是将活动值存储为键值对。这是当前系统的一个大大简化的架构,可以用来说明要点。 每个活动都有多个ActivityField;每个站点都有多个活动,并且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, ActivityXML.value('.[@type=EndDate]', 'datetime') as EndDate from SiteActivity where... 这似乎是个好主意吗?我想不出其他方式来存储大量不同的属性集。我的另一个想法是保留现有模式,并将其转换为更容易在数据仓库中查询的内容,但是我以前从未设计过星型模式,也不知道从哪里开始。 附加问题:如果我使用定义XSD中具有日期数据类型的标记xs:date,SQL Server会将其索引为日期值吗?我担心如果我按日期查询,它将需要将日期字符串转换为日期值并浪费使用索引的任何机会。

2
使用数据库快照进行报告的优势
使用数据库快照进行报告的性能优势是什么? 从我的角度来看,这可能会降低性能,因为原始数据库中的每次写入都必须对快照本身进行另一次写入。 我可以看到,无论何时要报告数据,您都将使用快照,但这并不属于性能类别。 再说一次,是否有性能优势?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.