问题标签 [sql-data-warehouse]

我是 Azure 的新手，我在 Azure SQL 数据仓库的表中有这个字段：

根据我从https://docs.microsoft.com/en-us/sql/t-sql/data-types/char-and-varchar-transact-sql?view=sql-server-2017阅读的内容：

• varchar [ ( n | max ) ] 可变大小的字符串数据。使用 n 以字节为单位定义字符串大小，可以是 1 到 8,000 之间的值，或者使用 max 来指示列约束大小，最大存储空间为 2^31-1 字节 (2 GB)。

但我看到的是 8000 的大小和这种类型的错误消息：

我尝试对大小进行硬编码，但任何大于 8000 的数字都无法按照文档中的说明工作。

我还发现一些文档说应该在表创建中使用 HEAP 或 CLUSTERED INDEX 类型，但它也没有帮助

知道出了什么问题吗？

作为我项目审计的一部分，我需要找到雪花目标中存在的表的数据库名称、用户名、上次访问日期、读/写访问权限、角色名称。有人可以帮我吗？

I am looking to create a query that shows shipping number, the container ID, the tracking number, the location it was last moved to, what time it was moved, and who moved it.

Here's the issue. We recently backed up or transaction history onto another table for anything that's over 30 days old.

So I have the table transaction_history which gives me everything from today to 30 days ago, and I have the table AR_transaction_history, which gives me everything else (starting from 31 days ago.)

I need to be able to create prompts for the user to input either the container ID, tracking number, or shipping ID.

I need help joining the two tables to create 1 table with all the records. I tried union all and it does not work with my prompts. I tried an isnull statement and that didn't work either. Here is the code.

我想将一些表从一个 azure 数据仓库转移到另一个 azure 数据仓库。但主要问题是两者都在不同的天蓝色订阅下。谁能告诉我源和目标在 azure 数据工厂中都有不同的订阅是否可以工作？

使用Visual Studio 2019（已经更新到最新版本），我创建了一个新的SQL Server Database Project连接到Azure SQL Datawarehouse Database.

我导入了数据库中已经存在的所有对象(tables, stored procedure and schema)，我进行了模式比较，没有发现任何差异。

在项目属性上，我更改了目标平台设置Miscrosoft Azure SQL Data Warehouse，我切换了兼容性级别设置SQL Server 2017 (140)

解决方案的构建成功，但是当我尝试发布解决方案时出现以下消息错误

只有选中该框才能生成发布脚本Always re-create database，但我不想每次都删除并重新创建数据库

我做了很多研究，但没有一个能解决我的问题。

SQL Server Database Project任何人都知道关于on的发布是否有任何已知的限制，Azure SQL Datawarehouse Database或者是否有人知道如何解决这个问题？

谢谢

我正在为在线业务构建星型模式。关键流程之一是电子邮件通讯注册。

但是分析取决于两个过程，我无法弄清楚如何以最佳方式对其进行建模。

以下是该过程的工作原理：

• 人访问网站
• 人员填写网络表格并在我们的 CRM 中记录为联系人
• 人收到一个链接，要求他确认这是否真的是他的电子邮件
• 人单击链接并被视为已确认
• 人现在可以接收来自我们的电子邮件

注册和确认过程发生在不同的时间。大多数人在同一天点击确认链接，但我们会在注册后的几天内发送两封后续电子邮件，因此有些人可能会在几天后确认他们的电子邮件。

最重要的是，一个人可以在网站上注册多次。我们的大多数注册用户都是交换电子邮件地址以换取某种资源（如电子书）的人。

只要此人的电子邮件未在我们的系统中标记为已确认，我们就会要求此人在每次注册时进行确认。

由于我们有多个报价，因此一个人请求电子书 A、电子书 B 和电子书 C 并仅在多次注册后才确认的情况并不少见。

在事实表中，未确认的电子邮件的每个注册都标记为 ConfirmationRequested -> True。

如果此人单击任何确认请求电子邮件的确认链接，则应将其视为已确认每个注册。

我想如何分析数据

• 看看我们有多少注册
• 查看有多少注册是重新注册，有多少是 CRM 中的新联系人（新电子邮件地址）
• 查看有多少新联系人确认了他们的电子邮件地址（并成为正式订阅者）
• 查看有多少重新注册被要求确认他们的电子邮件以及有多少人这样做了
• 分析人们确认他们的电子邮件地址需要多长时间
• 分析确认率
• 按确认状态过滤联系人并分析已确认或未确认的人的共同点

我并不真正关心与注册隔离的确认。

出于我的目的，我希望有一个 ConfirmationStatus 维度，即...

• 如果此人在注册后 7 天内确认，则为“已确认”
• 如果此人尚未确认，但自注册后尚未过去 7 天，则为“待处理”
• 如果此人在 7 天内未确认，则为“未确认”（即使此人稍后确实确认）

除此之外，我通常会在周一查看这份报告，以分析前一周并将其与其他周进行比较。（我已经在一个平面表中有这个报告的工作版本，但我正在尝试学习如何构建正确的星型模式。）

这有一个额外的挑战，例如，周日注册的联系人只有不到一天的时间来确认，并且会降低确认率，如果与所有联系人都有完整 7 天的前一周相比，最近一周看起来很糟糕。确认。

因此，我计算了所有周的“注册周内确认”确认计数和比率，以允许苹果与苹果之间的比较。

这个怎么建模...

我考虑了以下选项...

选项 #1：单独的事实表 由于这些是在不同时间发生的单独过程，我了解到我应该创建单独的事实表，然后跨公共维度进行钻取。

我可以计算从注册表中请求确认的注册，然后通过联系人和日期维度计算注册后一周内的确认。

但这不允许我按确认状态过滤注册。

这就是为什么我正在考虑...

选项 2：结合注册和确认的事实表

我在想这样的事情：

事实上，我需要 ConfirmationDate 来计算报告时的“周内确认”度量（我正在使用 powerbi，这很容易）。我当然也可以创建一个维度“ConfirmedWIthinWeek”，然后根据它进行过滤，但它不会那么灵活......如果我稍后决定每天或每月查看数据怎么办？

另一个问题是它需要在过去 7 天的每个增量负载上重新处理和更新事实表。

我知道维度可以，但事实表也可以吗？

所以我的问题是

• 选项＃2是一个好的解决方案还是有更好的方法来做到这一点？
• 可以更新事实表还是不鼓励这样做？

总的来说，我的问题是：我错过了什么？

这似乎是一件很平常的事情。一个明显的例子是一个订单星，它具有 AmountOrdered、AmountPaid、AmountRefunded 的事实表列以及“Order Status”、“Paid Status”和“Refunded Status”等维度。

但是我的搜索都没有找到这个常见问题的答案。当然必须有一个问题的术语和解决方案的模式名称，以便我可以了解更多信息？

我在azure sql 数据仓库中使用以下代码

但遇到错误，因为“datediff 函数导致溢出。分隔两个日期/时间实例的日期部分的数量太大。尝试使用具有不太精确的日期部分的 datediff。”

我的要求是以毫秒为单位的差异，如果改变了，那么它将影响其他结果。

请求您提供一些帮助

上表有呼叫中心员工班次/目标详情

• 操作员ID，
• User_Name 作为操作员名称，
• Team_Id,
• 操作员所属的团队名称，
• FTE = 员工一周工作的天数。（例如：FTE = 0.8 = 6.4 小时）

每行可能会或可能不会每周更改。

我觉得这是一个缓慢变化的维度，但我也有一种奇怪的感觉，这可能是一个事实表。

在缓慢变化的场景中，维度多久变化一次？

我正在查看用于缓慢变化维度（类型 2）的 SQL Server 临时表。一些维度表更新非常频繁（每天！从这个意义上说，它们并不是真正的“缓慢变化”。严格来说，它们并不是真正的维度）。

维度每天都在变化是否很常见？

我正在使用 BigQuery 处理数据仓库项目。我们正在加载从各种大型机系统导出的每日文件。大多数表都有唯一的键，我们可以使用它来创建类型 2 历史记录，但有些表，例如分类帐/头寸表，可以有重复的行。这些文件包含每天从源系统中提取的完整数据。

我们目前能够在不知道主键的情况下为大多数表维护类型 2 历史记录，只要加载中的所有行都是唯一的，但是对于不是这种情况的表，我们会遇到挑战。

项目中的一个人建议，处理的方式是“比较重复”，意思是如果DWH表有5个相同的行，而staging表有6个相同的行，那么我们就再插入一个，如果是反过来，我们只需关闭 DWH 表中的一条记录（通过将结束日期设置为现在）。这可以通过向数据集添加额外的“子行”键来实现，如下所示：

我试图找出这是否是好的做法，但没有任何运气。我觉得这件事有些不对劲，我看不出这样做会产生什么不可预见的后果。

任何人都可以告诉我在每天处理大量分类账数据时最好的方法是什么，我们希望在 DWH 中维护某种历史记录？