Page History

...

Use Cases

Views (http://issues.apache.org/jira/browse/HIVE-972^{Image Removed}) are a standard DBMS feature and their uses are well understood. A typical use case might be to create an interface layer with a consistent entity/attribute naming scheme on top of an existing set of inconsistently named tables, without having to cause disruption due to direct modification of the tables. More advanced use cases would involve predefined filters, joins, aggregations, etc for simplifying query construction by end users, as well as sharing common definitions within ETL pipelines.

...

• tables: this is mandatory if we want DROP TABLE to be able to correctly CASCADE/RESTRICT to a referencing view
• other views: same as tables
• columns: this is optional (useful for lineage inspection, but not required for implementing SQL features)
• temporary functions: we should disallow these at view creation unless we also want a concept of temporary view (or if it's OK for the referencing view to become invalid whenever the volatile function registry gets cleared)
• any other objects? (e.g. udt's coming in as part of http://issues.apache.org/jira/browse/HIVE-779^{Image Removed})

(Note that MySQL doesn't actually implement CASCADE/RESTRICT: it just ignores the keyword and drops the table unconditionally, leaving the view dangling.)

...