[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-21。"],[],[],null,["# Views overview\n\n| **PostgreSQL interface note:** Views are supported in PostgreSQL-dialect databases with some difference from open source PostgreSQL. In Spanner, views are read-only. Views can't be the target of an `INSERT`, `UPDATE`, or `DELETE` statement.\n\n\u003cbr /\u003e\n\nThis document introduces and describes Spanner views.\n\nOverview\n--------\n\nA *view* is a virtual table defined by a SQL query. When you create a view, you\nspecify the SQL query it represents. Once you have created a view, you can\nexecute queries that refer to the view as though it were a table.\n\nWhen a query that refers to a view is executed, Spanner creates\nthe virtual table by executing the query defined in the view, and that virtual\ntable's content is used by the referring query.\n\nBecause the query defining a view is executed every time a query referring to\nthe view is executed, views are sometimes called logical views or\ndynamic views to distinguish them from SQL materialized views, which store\nthe results of the query defining the view as an actual table in data storage.\n\nIn Spanner, you can create a view as either an *invoker's rights\nview* or a *definer's rights view*. They are the two types of security models\ncontrolling access to a view for users.\n\nBenefits of views\n-----------------\n\nViews offer several benefits over including the queries they define in the\napplication logic.\n\n- **Views can provide logical data-modeling to applications.**\n\n Sometimes the choices that make sense for physical data-modeling on\n Spanner are not the best abstraction for applications reading\n that data. A view can present an alternate table schema that is a more\n appropriate abstraction for applications.\n- **Views centralize query definitions and so simplify maintenance.**\n\n By creating views for widely used or complex queries, you can factor query\n text out of applications and centralize it. Doing so makes keeping query text\n up-to-date across applications much simpler and permits revision and tuning of\n queries without requiring application code to change.\n- **Views provide stability across schema changes.**\n\n Because the query that defines a view is stored in the database schema instead\n of in application logic, Spanner can and does ensure that\n schema changes to the objects (tables, columns and so on) the query refers to\n do not invalidate the query.\n\nCommon use cases\n----------------\n\nUse views when your Spanner database includes highly privileged\ndata that shouldn't be exposed to all database users or if you want to\nencapsulate your data.\n\nIf your view doesn't need additional security functionality and all invokers\nof the view have access to all schema objects that the view references, create\nan invoker's rights view.\n\nIf you want to create a view where not all invokers have access to all schema\nobjects that the view references, create a definer's rights view. Definer's\nrights views are better protected and have more restrictions because the\ndatabase admin can provide fewer users with privileges on the tables and\ncolumns referenced in the view. Definer's rights views are useful when a user\nneeds a way to securely access a relevant subset of a Spanner\ndatabase. For example, you might want to create a definer's rights view for the\nfollowing data:\n\n- Personal account data (e.g., application customer).\n- Role specific data (e.g., HR personnel, sales associate).\n- Location specific data.\n\nInvoker's rights views\n----------------------\n\nIf a view has invoker's rights, it means that when a user, the invoker, executes\na query against the view, Spanner checks the user's privileges\non the view and on all the schema objects that the view references. The user\nmust have privileges on all schema objects to query the view.\n\nDefiner's rights views\n----------------------\n\nA definer's rights view adds additional security functionality to the view. It\nprovides different privileges on the view and the underlying schema objects.\nLike for invoker's rights views, users must have database-level permissions to\ncreate definer's rights views. The main difference is that when a database role\nqueries a definer's rights view, Spanner verifies that\nthe role has access to the view itself (and only the view). Therefore,\neven if the user who queries the view doesn't have access to all the underlying\nschema objects, they can access the view and see its contents. Definer's rights\nviews give users access to fresh data, limited to the rows defined in the view.\n\nSpanner Identity and Access Management (IAM) permissions are granted at the\ndatabase level. Use [fine-grained access control](/spanner/docs/fgac-about)\nalongside definer's rights view, otherwise the definer's rights view doesn't add\nany additional access control. This is because if the user has read permissions\non the database, they have read permissions on all schema objects in the\ndatabase. After you configure fine-grained access control on your database,\nfine-grained access control users with the `SELECT` privilege on the view and\nusers with database-level permissions on the database can query the view. The\ndifference is that the fine-grained access control user doesn't need privileges\non the underlying objects.\n\nLimitations of views\n--------------------\n\nViews have limitations compared to actual tables that make them inappropriate\nfor certain use cases.\n\n- **Views are read-only. They cannot be used to add, update or delete data.**\n\n You cannot use views in DML statements (`INSERT`, `UPDATE`, `DELETE`).\n- **The query that defines a view cannot use query parameters.**\n\n- **Views cannot be indexed.**\n\n- **References to views cannot use [table hints](/spanner/docs/reference/standard-sql/query-syntax#table-hints).**\n\n However, the query that defines a view can include table hints on the tables\n it refers to.\n- **Views are not supported by the\n [Read](/spanner/docs/reference/rpc/google.spanner.v1#google.spanner.v1.Spanner.Read)\n API.**\n\n- **Definer's rights views are not supported with Spanner\n [Data Boost](/spanner/docs/databoost/databoost-overview).**\n\n Running a query that contains a definer's rights view in Data Boost results in\n an error.\n- **The recommended [query mode](/spanner/docs/reference/rest/v1/QueryMode) for\n accessing a definer's rights view is `NORMAL` mode.**\n\n Users who don't have access to the underlying schema objects of a definer's\n rights view receive an error when querying in a query mode other than normal.\n- **It's possible for a user to create a carefully crafted query that causes\n Spanner to throw an error that shows or reveals the existence\n of data that is not available in the definer's rights view.**\n\n For example, assume there is the following view QualifiedStudentScores which\n returns scores of students who qualify for a course. The criteria for\n qualifying is based on the level and exam score of the student. If the\n student's level is equal or lower than six, the score matters, and the student\n has to get at least 50 points on the exam to qualify. Otherwise, for levels\n equal or greater than six, the student qualifies by default. \n\n CREATE VIEW QualifiedStudentScores\n SQL SECURITY DEFINER AS\n SELECT\n s.Name,\n s.Level,\n sc.Score\n FROM Students AS s\n JOIN Scores AS sc ON sc.StudentId = s.StudentId\n WHERE\n (CASE\n WHEN (s.Level \u003c 6) OR (s.Level \u003e= 6 AND sc.Score \u003e= 50)\n THEN 'QUALIFIED';\n ELSE 'FAILED';\n END) = 'QUALIFIED';\n\n A user can run a query in the form of\n `SELECT * FROM QualifiedStudentScores s WHERE s.Level = 7 AND 1/(s.Score - 20) = 1;`.\n This query might fail with a division by zero error if there is a student in\n level 7 who got a score of 20 points, even though the view limits data to 50\n points and above for that level.\n\nQuery performance when using views\n----------------------------------\n\nA query that refers to a view performs comparably to that same query with its\nview reference replaced by the view's definition.\n\nQuotas and limits that apply to views\n-------------------------------------\n\n- The [Quotas \\& limits](/spanner/quotas#views) page lists quota and limit\n information specifically for views.\n\n- Using a view in a query can affect that query's conformance to\n [query limits](/spanner/quotas#tables) because the view's definition\n becomes part of the query.\n\nCost impact\n-----------\n\nUsing views has a very small impact on the cost of an instance:\n\n- Using views has no impact on the compute capacity needs of an\n instance, as compared to embedding their defined query text in queries that\n refer to them.\n\n- Using views has very small impact on the database storage of an instance\n because the table generated by executing a view's query definition is not\n saved to persistent database storage.\n\nWhat's next\n-----------\n\n- Learn how to [Create and manage views](/spanner/docs/create-manage-views)."]]