Skip to content

本页尚未翻译

本页内容仍为英文原文,源自官方文档 sql/ddl/view。中文翻译正在分批进行中。

View ​

Create, describe, list, and drop saved queries with SQL.

Applies to: Embedded ❌, Enterprise ✅

A view stores a query, not rows. Reading it runs the query against current data, so a view is never stale, and never faster than the query it wraps. It is the counterpart to a materialized view, which stores rows and is brought up to date by a refresh; both are catalog objects defined by a query, differing only in when that query runs.

The SDK methods create_view, describe_view, list_views, and drop_view submit SQL through the connection's Flight endpoint. drop_view_async returns a job of type query whose single id is the SQL query UUID. Waiting confirms catalog removal; physical cleanup can continue afterward.

CREATE VIEW ​

sql
CREATE VIEW "recent_matches" AS
SELECT t1.floats
FROM "documents" AS t1
INNER JOIN "categories" AS t2 ON t1.ints = t2.ints

The statement returns one row with UTF-8 name, query, and schema columns. query contains the stored query, including any declared column aliases, and schema contains its Arrow schema as JSON. The schema metadata keys lancedb::view::default_db and lancedb::view::default_namespace identify the defining database and namespace. The root namespace is public; nested namespace components are separated by $.

DESCRIBE VIEW "recent_matches" returns the same metadata shape. Anything the dialect supports can define one: joins, predicates, aggregates, window functions.

Reading one ​

A view is queried like a table:

sql
SELECT * FROM "recent_matches" WHERE floats > 0.5

Predicates applied to the view compose with the query inside it rather than filtering its output afterwards, so a selective filter does not pay for rows the view would have produced and then discarded.

DROP VIEW ​

sql
DROP VIEW "recent_matches"

Removes the saved query. Unlike dropping a table, no data is removed: there was none to begin with.

Listing ​

sql
SHOW VIEWS
SHOW VIEWS IN "analytics" WHERE name > 'previous_view' LIMIT 100

SHOW VIEWS returns ascending name values. The name cursor is scoped to the selected namespace.

Object commands retain their small results in shared storage even when general query-result copying is disabled, so asynchronous polling can use any query node.

Views and tables share a namespace, and both are things you can query. The catalog distinguishes them:

view namesthe views in the database
table namesthe tables
relation nameseverything queryable (both)

Use the relation listing when the question is "what can I select from," and the separate listings when the distinction matters: before dropping, for instance, since dropping a view removes only the saved query while dropping a table removes data.

Choosing between a view and a materialized view ​

ViewMaterialized view
Storesthe querythe rows
Freshnessalways currentas of the last refresh
Read costthe full query, every reada table scan
Write costnonea refresh

Reach for a view when the query is cheap, or when reading stale rows would be wrong. Reach for a materialized view when the query is expensive and the data changes less often than it is read.

The privileges are separate too: CREATE_VIEW and CREATE_MATERIALIZED_VIEW are distinct grants on a namespace, so the ability to create one does not imply the other. See Authorization.

Materialized ViewThe stored-rows counterpart.ManagementWhere views fit among the other catalog objects.