标签: view

服务器 SERVER_A 有一些数据。

服务器SERVER_B将A定义为链接服务器，并定义了一些数据视图。查询是这样的：

CREATE view myview as
select * from 
openquery ( SERVER_A, select .... )

服务器 SERVER_C 将 B 定义为链接服务器。

我拥有对 SERVER_C 的完全访问权限，我可以要求对 SERVER_B 进行一些更改，但不能要求对 SERVER_A 进行一些更改。我的所有应用程序都将访问服务器 SERVER_C，并需要来自 SERVER_A 的数据。SERVER_B 上的视图非常复杂，它们会在返回任何内容之前导致超时。

我认为为了提高这些查询的性能，我需要将 SERVER_B 上的视图转换为“索引视图”。要为视图建立索引，我必须创建聚集索引。

问题：

1）我应该在哪里定义聚集索引？它应该在 SERVER_B 上，还是我可以以某种方式在 SERVER_C 上定义它？

2) 即使未使用该视图，在 SERVER_B 上使用索引视图是否会以任何方式影响 SERVER_A 的性能？

我在我们的数据库中有一个非常重要的表，它被一系列应用程序使用，它附有规则、触发器和您可以想象的所有依赖项。现在我想修改表而不会对依赖项造成任何问题。我以前成功地执行了以下操作，但在一个不太复杂的情况下：

alter table reconciliations rename to matches;
create view reconciliations as select * from matches;

这实现的是我现在可以修改新的“匹配”表，例如添加一列或多行，这些列或行不需要在“对帐”视图中显示（通过添加 where 子句来过滤它们）。

我使用的是 Postgres 9.5，因此视图可以自动更新。初步测试表明，这没有直接问题，所以我问这个问题是为了知道我应该寻找什么样的问题。性能不是大问题。

我有两个表：

1. 提款：account_id+amount
2. 奖品：account_id+amount

我想计算每个 的余额account，可能在VIEW.

我可以有两个查询：

SELECT account_id, SUM(amount) FROM prizes GROUP BY account_id

这给了我每个帐户的总奖金，以及：

SELECT account_id, SUM(amount) FROM withdrawals GROUP BY account_id

这给了我这些账户的所有提款。

现在，我想减去它们以返回我帐户的余额。创建这样的视图的最有效方法是什么？

我需要知道我被授予仅 SELECT 访问权限的第三方数据库中每个视图的行数。以下脚本适用于表，但不适用于视图：

SELECT      SCHEMA_NAME(A.schema_id) + '.' +
        --A.Name, SUM(B.rows) AS 'RowCount'  Use AVG instead of SUM
          A.Name, AVG(B.rows) AS 'RowCount'
FROM        sys.objects A
INNER JOIN sys.partitions B ON A.object_id = B.object_id
WHERE       A.type = 'U'
GROUP BY    A.schema_id, A.Name
Order by AVG(B.rows) desc
GO

我在网上查看过，但所有建议要么仅适用于表，要么要求我创建表或过程（我无法使用此级别的权限来执行此操作），要么要求我单独计算每个视图的行数，这是不可行的对于包含大量此类视图的数据库。

有谁对一个脚本有什么想法，该脚本可以计算数据库中所有视图中的所有行，而不需要 CREATE 或 EXECUTE 权限？

我有几个表，我想以与Python Pandas Concatenate类似的方式合并。我不想复制信息，因为它相当大。我想有一个VIEW喜欢的行为。让我用一个假的例子来说明，据我所知是行不通的，只是为了正确解释我想要实现的目标。

假设我有这两个表：

CREATE TABLE table_1 (
    [a] [bigint] NOT NULL,
    [b] [bigint] NOT NULL,
    [c] [varchar] (32) NULL,
    [d] [bigint] NULL,
)
GO

CREATE TABLE table_2 (
    [a] [bigint] NOT NULL,
    [b] [bigint] NOT NULL,
    [c] [varchar] (32) NULL,
    [e] [varchar](256) NULL,
)
GO

哪里a, b, c是等价的，但保存不同的数据。 d存在于table_1但不存在table_2和e存在于table_2但不存在table_1。

表不保存任何公共数据。也就是说，JOIN任何字段上的 a 都会带来零结果。

我希望能够执行以下操作（或等效的操作。我知道我所展示的内容不可行）：

CREATE VIEW MyUnion FROM(
SELECT …

我注意到，对于由我们的组织和我们的一些 ERA 软件提供商制作的 Crystal Reports，他们倾向于使用物理表作为他们报告的数据集，而不是使用视图或存储过程来收集数据。偶尔我看到报告使用存储过程，然后使用物理表而不是临时表来存储和操作数据集。在这些情况下，报告输出通常以类似rpt_ap_vendors或类似的表格形式存在，并且在不使用时可能没有数据，也可能没有数据。

这些总是按需生成报告的情况，因此这不是可以生成一次并多次提供报告的情况，并且没有多个报告/存储过程同时访问此数据。

像这样的报告使用物理表有什么理由？这样做是否有逻辑、技术或性能相关的原因？在生成报告时，我个人一直使用带有临时表或更好的派生表的视图和存储过程，以避免涉及清除/删除临时表的额外磁盘读取。

我目前正在 SaaS BI 产品中创建多租户数据架构。

该产品使用共享数据库和共享架构，但具有租户视图过滤器和租户数据加密（此处的灵感来源：http : //msdn.microsoft.com/en-us/library/aa479086.aspx）

创建视图过滤器时，我可以执行以下两项操作：

CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()

CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_ID()

使用 SID() 我正在使用如下所示的安全标识符：

0x3425F1595A67774ABF485CDC30285443

使用 ID() 我正在使用看起来像这样的普通标识符：

265

哪一个绝对最好用，为什么？:) 我希望两者都是绝对独特的，并且永远不会在新的用户登录中重复使用

我有一个疑问：

select qid,ansid,ans from table1 where askerid='something'

此查询可以检索许多行。但我想一次只显示 50 行，然后如果用户单击more，则应检索接下来的 50 行。我想到了这样的查询：

select qid,ansid,ans 
from table1 
where askerid='something' 
limit 100
minus 
select qid,ansid,ans 
from table1 
where askerid='something' 
limit 50

我想知道这是否是一个良好的查询性能和替代查询，其性能优于上述查询。

我正在将 SQL Server 2000 迁移到 SQL Server 2008。我有很多看法。我如何检查每个视图是否有 order by 子句？

谢谢。

在 SQL Server 2008 R2 中，我们使用可更新视图来更新varchar(max)列。当我们用文本更新列然后检查字符数时，它显示的长度为 8000 个字符，即使更新包含更多的字符。

视图可以接收更新的字符数是否有某种限制？

好的，我正在与应用程序开发团队合作解决这个问题，他们认为他们找到了解决方法，因此他们放弃了用作测试用例的代码。我会尽力给出大致的想法。更新语句类似于：

UPDATE vorders
set [description] = '<br> This is some text about the order </br>' 
    + CHAR(34) + 'This is more text' + CHAR(34) + 'and on it goes'
where orderid = 12345

然后我们将通过运行以下查询来检查放入该字段的字符的长度

SELECT LEN([description])
  FROM vorders
 WHERE orderid = 12345

应用程序人员发现，如果他们删除 + CHAR(34) + 部分代码，则长度将达到 8700 个字符。使用 + CHAR(34) + 部分代码将文本截断为 8000 个字符。这让我怀疑这是某种隐式转换；但是，我们发现在 + CHAR(34) + 中的一两个就位时不会发生截断。最初的声明大约有 30 个。

知道是什么原因导致了这个问题，我对此一无所知。