CREATE VIEW
適用於: Databricks SQL Databricks Runtime
根據 SQL 查詢的結果集,建構沒有實體數據的虛擬數據表。
ALTER VIEW
和 DROP VIEW
只會變更元數據。
語法
CREATE [ OR REPLACE ] [ TEMPORARY ] VIEW [ IF NOT EXISTS ] view_name
[ column_list ]
[ schema_binding |
COMMENT view_comment |
TBLPROPERTIES clause [...]
AS query
schema_binding
WITH SCHEMA { BINDING | COMPENSATION | [ TYPE ] EVOLUTION }
column_list
( { column_alias [ COMMENT column_comment ] } [, ...] )
參數
或 REPLACE
如果已有相同名稱的檢視存在,則會加以取代。 若要取代現有的檢視,您必須是其擁有者。
取代現有的檢視並不會保留原始檢視上授與的許可權。 使用 ALTER VIEW 來保留許可權。
TEMPORARY
只有建立暫存檢視的會話才會顯示,而且會在會話結束時卸除。
全域暫存
適用於: Databricks Runtime
全域暫存檢視會系結至系統保留的暫存架構
global_temp
。IF NOT EXISTS
只有在檢視不存在時,才會建立檢視。 如果這個名稱的檢視已經存在,
CREATE VIEW
則會忽略 語句。您最多可以指定
IF NOT EXISTS
或OR REPLACE
中的一個。-
新建立的檢視的名稱。 暫存檢視的名稱不得限定。 完整檢視名稱必須唯一。
在 中
hive_metastore
建立的檢視只能包含英數位元 ASCII 字元和底線(INVALID_SCHEMA_OR_RELATION_NAME)。 schema_binding
適用於: Databricks Runtime 15.3 和更新版本
選擇性地指定檢視如何因基礎物件定義中的變更而適應查詢架構的變更。
暫存檢視或具體化檢視不支持這個子句。
WITH SCHEMA BINDING
如果查詢資料列清單變更,但下列條件除外,檢視會變成無效:
- 數據行清單包含 star 子句,而且還有其他數據行。 會忽略這些額外的數據行。
- 一或多個數據行的類型會以允許它們使用隱含轉換規則安全地轉換成原始數據行類型的方式變更。
此為預設行為。
WITH SCHEMA COMPENSATION
如果查詢資料列清單變更,但下列條件除外,檢視會變成無效:
- 數據行清單包含 star 子句,而且還有其他數據行。 會忽略這些額外的數據行。
- 一個或多個數據行的類型會以允許它們使用明確的 ANSI 轉換規則轉換成原始數據行類型的方式變更。
使用架構類型演進
當 SQL 編譯程式偵測到這類變更以響應檢視的參考時,檢視會將查詢資料行清單中類型的任何變更採用到自己的定義中。
使用架構演進
- 如果檢視不包含明確的
column_list
,此模式的行為就像WITH SCHEMA TYPE EVOLUTION
,也會採用數據行名稱的變更,或加入和卸除的數據行。 - 如果無法再剖析查詢,或選擇性檢視不再符合選取清單中的表達式
query
數目,檢視column_list
才會變成無效。
- 如果檢視不包含明確的
column_list
選擇性地在檢視的查詢結果中標記資料行。 如果您提供資料行清單,資料行別名的數目必須符合查詢中的運算式數目。 如果沒有指定數據行清單的別名衍生自檢視主體。
-
數據行別名必須是唯一的。
column_comment
描述數據行別名的選擇性
STRING
常值。
-
view_comment
提供檢視層級批注的選擇性
STRING
常值。-
選擇性地設定一個或多個使用者定義的屬性。
AS 查詢
從基底資料表或其他檢視中建構檢視的查詢。
範例
-- Create or replace view for `experienced_employee` with comments.
> CREATE OR REPLACE VIEW experienced_employee
(id COMMENT 'Unique identification number', Name)
COMMENT 'View for experienced employees'
AS SELECT id, name
FROM all_employee
WHERE working_years > 5;
-- Create a temporary view `subscribed_movies`.
> CREATE TEMPORARY VIEW subscribed_movies
AS SELECT mo.member_id, mb.full_name, mo.movie_title
FROM movies AS mo
INNER JOIN members AS mb
ON mo.member_id = mb.id;
-- Create a view with schema binding (default)
> CREATE TABLE emp(name STRING, income INT);
> CREATE VIEW emp_v WITH SCHEMA BINDING AS SELECT * FROM emp;
– The view ignores adding a column to the base table
> ALTER TABLE emp ADD COLUMN bonus SMALLINT;
> SELECT * FROM emp_v;
name income
---- ------
-- The view tolerates narrowing the underlying type
> CREATE OR REPLACE TABLE emp(name STRING, income SMALLINT, bonus SMALLINT);
> SELECT typeof(income) FROM emp_v;
INTEGER
– The view does not tolerate widening the underlying type
CREATE OR REPLACE TABLE emp(name STRING, income BIGINT, bonus SMALLINT);
> SELECT typeof(income) FROM emp_v;
Error
– Create a view with SCHEMA COMPENSATION
> CREATE TABLE emp(name STRING, income SMALLINT, bonus SMALLINT);
> CREATE VIEW emp_v WITH SCHEMA COMPENSATION AS SELECT * FROM emp;
-- The view tolerates widening the underlying type but keeps its own signature fixed
CREATE OR REPLACE TABLE emp(name STRING, income INTEGER, bonus INTEGER);
> SELECT typeof(income) FROM emp_v;
INTEGER
-- The view does not tolerate dropping a needed column
ALTER TABLE emp DROP COLUMN bonus;
> SELECT * FROM emp_v;
Error
– Create a view with SCHEMA EVOLUTION
> CREATE TABLE emp(name STRING, income SMALLINT);
> CREATE VIEW emp_v WITH SCHEMA EVOLUTION AS SELECT * FROM emp;
-- The view picks up additional columns
> ALTER TABLE emp ADD COLUMN bonus SMALLINT
> SELECT * FROM emp_v;
name income bonus
---- ------ -----
-- The view picks up renamed columns as well
> ALTER TABLE emp RENAME COLUMN income TO salary SMALLINT;
> SELECT * FROM emp_v;
name salary bonus
---- ------ -----
-- The view picks up changes to column types and dropped columns
> CREATE OR REPLACE TABLE emp(name STRING, salary BIGINT);
> SELECT *, typeof(salary)AS salary_type FROM emp_v;
name salary
---- ------