标签: materialized-views

我在Oracle 10.2.0.50数据库中有一个物化视图,如下所示:

CREATE MATERIALIZED VIEW mv_cis
   NOCACHE
   NOLOGGING
   NOCOMPRESS
   NOPARALLEL
   BUILD IMMEDIATE
   REFRESH FORCE
           ON DEMAND
           WITH PRIMARY KEY AS
   SELECT component_id, ctn, visible_tag, facility,
          SYSTEM, elev, parent, room_number,
          remarks, safety_class, seismic, quality_level
     FROM v_cis;

相当直接的东西.创建此物化视图后,它将生效并填充我期望的数据.然后我在其表中添加一个约束,如下所示:

ALTER TABLE mv_cis
   MODIFY ctn CONSTRAINT chk_cis_ctn_null NOT NULL ENABLE VALIDATE;

这按预期工作,表得到一个新的约束,并且在世界上一切都很好.

但是,我回顾一下物化视图和(使用Toad for Oracle 12)它显示无效.展望该user_mviews表显示,COMPILE_STATE它是NEED_COMPILE和STALENESS是UNDEFINED.所以我跑:

ALTER MATERIALIZED VIEW mv_cis COMPILE;

没变.奇怪的是,刷新视图仍然有效,但它让我发疯,它显示无效,并使我的测试计划失败,即使一切看起来都井然有序.那么,我错过了什么？

在Redshift FAQ下

问:Amazon Redshift的性能与数据仓库和分析的大多数传统数据库相比如何？

它说如下:

高级压缩:列式数据存储可以比基于行的数据存储压缩得多,因为类似的数据按顺序存储在磁盘上.Amazon Redshift采用多种压缩技术,相对于传统的关系数据存储,通常可以实现显着的压缩.此外,Amazon Redshift不需要索引或物化视图,因此比传统的关系数据库系统占用更少的空间.将数据加载到空表时,Amazon Redshift会自动对数据进行采样并选择最合适的压缩方案.

为什么会这样？

在当前的计划中，传入的命令通过函数应用程序处理，导致事件被发送到事件中心，然后实现视图

有人认为，与其将事件存储在表存储中，并根据事件和快照物化视图，我们应该：

只需将事件流式传输到 Azure Monitor 中的日志即可进行审核

我们可以响应命令立即对域对象进行更改，并将更改提要用作物化视图的事件源。

他甚至没有看到物化视图的优势。为什么不直接使用查询？争论是我们预计不会有很多流量。

他想通过将事件保存到 azure 监视器日志来完成整个审计日志 - 只是一个应用程序日志。相反，这些命令应该直接修改 Cosmos 中实体的表示，我们将使用来自 CosmosDB 的更改提要作为我们的域对象事件，或者我们将通过该流的订阅者创建新事件。

这实际上是一种有利的方法吗？你能想出我们不想这样做的任何理由吗？似乎我们会在这里失去一些东西。

他是说我们不再需要关心最终的一致性，因为我们会立即保持一致性。

我评估过的每个参考实现都没有按照他的建议去做。我对事件溯源/CQRS 范式的优点/缺点并不深入了解，所以我现在不知所措..目前正在疯狂研究

这是一个概念问题，因此没有太多代码示例。但是，这里有一些参考资料似乎支持我正在采取的方法。

https://medium.com/@thomasweiss_io/planet-scale-event-sourcing-with-azure-cosmos-db-48a557757c8d

https://sajeetharan.com/2019/02/03/event-sourcing-with-azure-eventhub-and-cosmosdb/

https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

我正在尝试优化使用MySQL 5.1中的视图的查询.看来即使我从视图中选择1列,它也总是进行全表扫描.这是预期的行为吗？

对于我在下面第一个查询中指定的表,视图只是SELECT"这些表中的所有列 - NOT*".

这是我从组成视图的查询中选择索引列的PromotionID时的解释输出.正如您所看到的,它与视图上的输出有很大不同.

EXPLAIN SELECT pb.PromotionID FROM PromotionBase pb INNER JOIN PromotionCart pct ON pb.PromotionID = pct.PromotionID INNER JOIN PromotionCode pc ON pb.PromotionID = pc.PromotionID WHERE pc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pc
         type: const
possible_keys: PRIMARY,fk_pc_pb
          key: PRIMARY
      key_len: 302
          ref: const
         rows: 1
        Extra:
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: pb
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using index …

从手册

CREATE MATERIALIZED VIEW 类似于 CREATE TABLE AS，不同之处在于它还会记住用于初始化视图的查询，以便以后可以根据需要刷新。

据我了解，刷新物化视图应该与 re 具有相同的效果create view as。但这不是这里发生的事情。

创建一个只有一列的表

drop table if exists t cascade;

create table t (a int);

insert into t (a) values (1);

创建物化视图

create materialized view mat_view_t as
select * from t ;

select * from mat_view_t;
 a 
---
 1

现在一列被添加到源表

alter table t add column b int;

\d t
       Table "public.t"
 Column |  Type   | Modifiers 
--------+---------+-----------
 a      | integer | 
 b      | integer | 

然后刷新物化视图

refresh …

使用Scenic gem，我构建了一个由物化视图支持的 ActiveRecord 模型

class MatviewSales < ActiveRecord::Base
  self.table_name = 'matview_sales'
  self.primary_key = :id

  belongs_to :user
  belongs_to :account
  belongs_to :account_manager, class_name: User, foreign_key: 'manager_id'

  def self.refresh
    Scenic.database.refresh_materialized_view(table_name, concurrently: true)
  end
end

我现在尝试在 RSpec 中测试这个模型，但无论我做什么，我都无法让 Postgres 用记录填充视图：

> FactoryGirl.create(:sale_item)
> MatviewSales.refresh
> MatviewSales.all
=> #<ActiveRecord::Relation []> 

如何使用测试记录填充物化视图？

我的postgresql 数据库中有一个现有的MATERIALIZED VIEW。我正在尝试为此创建 typeorm 实体。谁能告诉我怎么做。我已经浏览了typeorm View Entities 文档，但它没有我预期的那样有用。

如何检查物化视图是否存在？

我创建了一个并签入information_schema.tables，information_schema.views但我看不到它。

我应该去哪里找？

我想设置从 Maximo 7.6.1.1 到外部系统的出站集成。Maximo 和外部系统都有 Oracle 12c 数据库。

在外部系统中，我想从 Maximo WORKORDER 表中选择打开的 WO，以进行近实时数据分析。

标准集成选项似乎是：

1. 平面文件
2. XML文件
3. 接口表
4. 网络服务

我注意到物化视图通常不被认为是有效的集成选项。

例如，我可以通过 dblink 在 Maximo.WORKORDER 表上的外部系统中创建物化视图。物化视图可以通过多种不同的方式设置，包括按计划刷新、近乎实时等。

据我所知，物化视图是一种相当强大的集成技术。但是，我没有听说过任何同行为了 Maximo 集成目的而使用物化视图。

为什么物化视图不是 Maximo 集成的合适选择，是否存在技术原因？

例子：

两个数据库都需要是后期模型 Oracle dbs 才能实现物化视图，但情况并非总是如此。

我目前有一系列用于报告的物化视图视图 #1 和视图 #2。

使用PGAdmin，我想更改物化视图#1的代码（只需更改where子句，视图的结构保持不变），但物化视图#2是从物化视图#1生成的。

有没有办法推迟任何检查，以便我可以在不删除每个后续视图的情况下进行更改？