創建數據庫對象的命名規范

創建數據庫對象時，開發人員可以選擇一種命名方法，可以選擇遵循傳統 IBM i 行為的系統命名模式 (*SYS)，也可以選擇遵循SQL 標準規則的 SQL 命名規范 (*SQL)。

DB2 for i 與其他數據庫管理系統 (DBMS) 之間的主要差別在于 DB2 for i 集成于操作系統之中。這種集成使 IBM i 用戶能夠使用自己的操作系統用戶配置文件和相關的訪問權限直接訪問 DB2 for i 數據庫。其他數據庫并未集成到操作系統之中，因此必須定義具有獨立訪問權限的特定數據庫用戶。

SQL 創建數據庫對象時使用的默認命名取決于這些 SQL DDL（數據定義語言）命令的環境。

對于所有服務器端 SQL 環境（比如用于啟動 SQL 交互會話的 STRSQL 或用來運行 SQL 語句的 RUNSQLSTM）以及 HLL（高級語言）程序（比如 RPG 或 COBOL）中的嵌入式 SQL 而言，默認命名是系統命名。

基于客戶端的 SQL 環境中使用的默認命名值則通常是 SQL 命名，例如 System i Navigator、IBM Rational Developer for Power Systems Software (RDp)、中間件（ODBC、JDBC 等）或第三方 SQL 工具。

為了避免對象權限和訪問方法匹配不當，您需要確定在您的應用程序環境中最適合使用的是系統命名還是 SQL 命名。在某些環境中，您可能需要更改默認命名，以匹配您的應用程序環境中使用的命名規范。

System i Navigator 界面

如果您希望使用 System i Navigator 界面來創建數據庫對象，那么可以按照如下方法預定義要使用的命名：

打開您的連接，右鍵單擊數據庫圖標，選擇 Preferences 任務，如 圖 1. System i Navigator – 設置首選項 所示。

Preferences 窗口提供了 3 個選項。Connection (all Systems) 選項允許您預定義要為未來的連接使用的命名規范。這項設置也將用作運行 SQL 腳本和生成 SQL 執行的未來默認命名值，但不會影響任何現有窗口。

圖 1. System i Navigator – 設置首選項

System i Navigator 的運行 SQL 腳本工具

如果您希望使用運行 SQL 腳本工具來執行一個文件內存儲的 SQL 腳本或者交互地輸入的 SQL 腳本，那么可以通過單擊 Connection 下拉菜單并選擇 JDBC Setup 任務來控制命名規范?？梢栽?Format 選項卡中設置命名規范。

圖 2. System i Navigator – 運行 SQL 腳本 - 設置命名規范

RUNSQLSTM – 運行 SQL 語句

如果您希望通過 RUNSQLSTM （運行 SQL 語句）執行存儲在源物理文件成員或者 IFS（集成文件系統）中的 SQL 語句，那么可以在 RUNSQLSTM 命令中使用 Naming 參數指定命名規范，如下例所示。使用 SQL 命名即可執行指定的 SQL 腳本。

清單 1. RUNSQLSTM 設置命名規范

RUNSQLSTM SRCFILE(MYSCHEMA/QSQLSRC) SRCMBR(MYSCRIPT) NAMING(*SQL)

HLL 程序中的嵌入式 SQL

如果您希望在 RPG 或 COBOL 等 HTLL 程序內使用嵌入式 SQL，以便處理您的表中的數據庫，或者創建新數據庫對象，那么默認命名設置將是系統命名。

如果您希望使用 SQL 命名，那么可以在編譯命令中預先定義命名規范（CRTSQLRPGI、CRTSQLCBLI 或者 CRTSQLCI，具體取決于編程模型），如下例所示：

清單 2. 創建一個使用 SQL 命名的嵌入式 SQL 程序

CRTSQLRPGI OBJ(MYPGMLIB/MYSQLPGM) SRCFILE(MYSRCLIB/QRPGLESRC) SRCMBR(MYMBR) OPTION(*SQL)

除了在編譯命令中指定命名方法之外，還可以將其包含在您的源代碼之中，只需添加一條 SET OPTION 語句即可（如下例所示）。SET OPTION 語句必須是源代碼中的第一條語句，并且包含您希望設置的所有選項。

清單 3. 設置命名規范的 SET OPTION 語句

/Free Exec SQL Set Option Commit=*NONE, Naming=*SQL DatFmt=*ISO, CloSQLCsr=*ENDACTGRP; //All other source code including embedded SQL statements /End-Free

IBM i Access for Windows ODBC 驅動程序

可以使用 IBM i Access for Windows - ODBC 管理界面或連接關鍵字，為 ODBC 連接指定命名規范。

下一張圖展示了在 ODBC 管理界面的 Server 選項卡中控制的命名規范。

圖 3. ODBC 設置

JDBC 訪問

可以通過在連接 URL 中指定 JDBC 驅動程序的連接屬性來控制 JDBC 訪問命名規范。

naming 屬性的連接屬性支持使用 sql 和 system 值來指定命名規范。默認設置為 SQL 命名。

使用系統命名時，可以使用 libraries 屬性預定義一個庫列表，如下例所示。

清單 4. JDBC 設置命名規范

conn = DriverManager.getConnection("jdbc:db2:*local: ... ... naming=system;libraries=MYLIBA,MYLIBB,MYLIBX");

IBM i Access for Windows ADO.NET 提供程序

使用 ADO.NET 時，可在建立連接時設置系統命名的命名規范和庫列表。iDB2Connection 對象連接到 DB2 for i。命名規范以連接字符串屬性的形式提供。

以下代碼展示了如何為 iDB2Connection 對象設置系統命名和庫列表：

清單 5. ADO.NET 設置命名規范

iDB2Connection conn = new iDB2Connection("DataSource=abc; userid=XXX;password=YYY; Naming=System; LibraryList=*USRLIBL,MYLIB");

SQL CLI - 調用級接口

使用 SQL CLI 函數時，命名規范是一個可以通過執行 SQLSetConnectAttr 函數設置的屬性。為了將命名規范設置為系統命名，必須將 SQL_ATTR_DBC_SYS_NAMING 常量傳遞給屬性參數，并將 SQL_TRUE 常量傳遞給屬性值參數，如下例所示。

清單 6. 使用 SQLCLI 設置連接屬性

rc = SQLSetConnectAttr(ConnHandle: SQL_ATTR_DBC_SYS_NAMING: SQL_TRUE: 4);

STRSQL – 啟動 SQL 交互會話

如果您希望更改在交互式 SQL 中運行 SQL 語句所用的命名，可執行 STRSQL CL 命令，按下功能鍵 F13=Services，并選擇選項 1（更改會話屬性）。

回頁首

架構 – 包含數據庫對象的容器

架構就是用于存儲數據庫對象的容器。在 IBM i 中，架構這個術語的用法等同于庫。

架構或庫均可使用 CRTLIB（創建庫）CL 命令或 CREATE SCHEMA SQL 語句創建。CRTLIB 命令僅創建一個空容器，SQL 語句則將自動添加一個日志、一個日志接收器和一些包含有關此架構中的所有數據庫對象的信息的目錄視圖。

使用 CRTLIB 命令創建庫時，庫的所有者可以是創建庫的用戶配置文件，也可以是組配置文件。

庫的所有者是用戶還是組配置文件取決于用戶配置文件的 OWNER 選項設置。如果 OWNER 選項設置為 *GRPPRF，則 GRPPRF 選項中指定的用戶配置文件將成為該用戶創建的所有對象的所有者，否則用戶配置文件將成為對象所有者。

下面的示例展示了如何使用 CHGUSRPRF（更改用戶配置文件）將 PGMRGRP2 用戶配置文件未來創建的所有對象的所有者設置為 PGMR 組配置文件。

清單 7. 更改用戶配置文件將所有者設置為組配置文件

CHGUSRPRF USRPRF(PGMRGRP2) GRPPRF(QPGMR) OWNER(*GRPPRF)

本文中創建的所有實例數據庫對象均由名為 PGMRGRP2 的用戶配置文件創建。這個用戶配置文件與 QPGMR 組配置文件相關聯。因此，QPGMR 組配置文件將作為 PGMRGRP2 創建的全部數據庫對象的所有者。

使用系統命名創建架構

使用 CREATE SCHEMA 語句，通過系統命名創建一個架構時，將應用以下規則：

• 架構的所有者是用戶配置文件還是組配置文件取決于用戶配置文件定義中的 OWNER 選項設置。
• 所有者擁有 *ALL 對象權限，而 *PUBLIC 對象權限以 QCRTAUT（創建默認公共權限）系統值為依據，其默認值是 *CHANGE。

使用 CRTLIB 命令或者 CREATE SCHEMA 語句通過系統命名創建架構或庫將得到相同的所有權和同樣的對象權限。

PGMRGRP2 用戶配置文件使用以下 SQL 語句、利用系統命名創建了兩個架構（PGMRUSR2 和 PGMRXXX2）：

清單 8. 架構創建示例

CREATE SCHEMA PGMRXXX2; CREATE SCHEMA PGMRUSR2;

兩個架構的所有者都是 QPGMR 組配置文件。組配置文件擁有 *ALL 對象權限，而 *PUBLIC 權限根據 QCRTAUT 系統值設置為 *CHANGE。

圖 4. 使用系統命名創建架構

可以使用 EDTOBJAUT（編輯對象權限）或 System i Navigator Permission 界面來顯示、設置或刪除對象所有者和所指派的對象權限。使用 System i Navigator 時，可以右鍵單擊一個數據庫對象并選擇 Permissions 任務來訪問該界面。

對象所有權可以使用 CHGOBJOWN（更改對象所有者）CL 命令進行更改。不存在可使用 SQL 更改對象所有者的 SQL 語句或者 System i Navigator 界面。

使用 SQL 命名創建架構

使用 SQL 命名創建架構時，規則將更加復雜：

• 如果一個用戶配置文件與已有架構同名，則架構的所有者和在此架構中 創建的所有對象的所有者均為該用戶配置文件。例如，一名開發人員為基于 Web 的新應用程序創建了一個名為 WEBERP 的架構。如果恰好有一位叫做 Weber Peter 的員工的用戶配置文件也是 WEBERP。那么 WEBERP 用戶配置文件將成為 WEBERP 架構的所有者。
• 如果沒有與架構名稱匹配的用戶配置文件名稱，那么架構的所有者就是執行 CREATE SCHEMA 語句的作業的用戶配置文件。使用 SQL 命名創建架構時，用戶配置文件定義的 OWNER 選項設置將被忽略。

所有者是惟一對架構擁有任意權限的用戶配置文件。如果其他用戶需要擁有架構的對象權限，那么所有者或具有安全管理權限 (*SECADM) 或全部對象權限 (*ALLOBJ) 的用戶配置文件可以使用 GRTOBJAUT（授予對象權限）CL 命令來授予該架構的權限。

不存在可用于為架構授予對象權限的 SQL 語句。

• 對于使用 SQL 命名創建的數據庫對象，*PUBLIC 對象授權始終設置為 *EXCLUDE。QCRTAUT 系統值將被忽略。

為了對比系統與 SQL 命名之間的差異，我們刪除了之前使用系統命名的架構，并由相同的用戶使用 SQL 命名重新創建它。

在對比兩種模式的所有權和對象權限時，我們會發現以下幾種差異：

• PGMRXXX2 架構的所有者是 PGMRGRP2，也就是架構的創建者。PGMRGRP2 用戶配置文件的所有者設置被忽略。
• 所 有者 PGMRGRP2 將獲得 *ALL 對象權限，而 *PUBLIC 對象權限則設置為 *EXCLUDE。相比之下，在使用系統命名的架構中，*PUBLIC 對象權限依賴于 QCRTAUT 系統值。因此，同屬 QPGMR 組配置文件的另外一名開發人員不允許修改架構或者在此架構內創建對象。如果企業廣泛使用組配置文件，而且任何開發人員創建的所有對象的所有者都必須成為組 配置文件，那么這種行為會造成一些問題。
• 架構 PGMRUSR2 的所有者是 PGMRUSR2，因為存在一個與此名稱相同的現有用戶配置文件。之前，在使用系統命名創建架構時，兩個架構的所有者均為 QPGMR 組配置文件。

• PGMRUSR2 架構的所有者 PGMRUSR2 將獲得 *ALL 對象權限，而 *PUBLIC 權限設置為 *EXCLUDE。即便用戶 PGMRGRP2 能夠創建架構 PGMRUSR2，該用戶也無法獲得該架構的任何權限。PGMRGRP2 無法修改架構，也無法在此架構內創建或修改任何對象。

下面的屏幕快照顯示了使用 SQL 命名創建的架構的特權（也稱為權限）。

圖 5. 使用 SQL 命名創建架構

回頁首

表、視圖和索引 – 維護數據的對象

表是在多個列和行中存儲持久用戶數據的對象。

視圖和索引是與一個表相關但不包含任何數據的數據庫對象。

使用系統命名創建表、視圖和索引。

確定所有權、應用對象權限的規則與用于創建架構的規則相匹配。所有者是對象的創建者，或者組配置文件，*PUBLIC 對象權限設置為 QCRTAUT 系統值。

在下一個示例中（圖 6. 使用系統命名創建表），表 EMPLOYEE 是在兩種不同的架構（PGMRUSR 和 PGMRXXX）中使用系統命名創建的，使用的 SQL 語句如下：

清單 9. 創建 EMPLOYEE 表

Create Table MySchema/Employee (FirstName VarChar(50) Not NULL Default '', Name VarChar(50) Not NULL Default '', Street VarChar(50) Not NULL Default '', ZipCode VarChar(15) Not NULL Default '', City VarChar(50) Not NULL Default '', Country Char(3) Not NULL Default '', Birthday Date Not NULL);

兩種架構之前都是由用戶配置文件 PGMRGRP2 使用系統命名，通過 CREATE SCHEMA 語句創建的。兩種架構的所有者均為 QPGMR 組配置文件，都基于 PGMRGRP2 用戶配置文件的 OWNER 設置。組配置文件是 PGMRUSR 架構中創建的表的所有者，即便存在 PGRMRUSR 用戶配置文件時也是如此。

所有者用戶配置文件 QPGMR 擁有 *ALL 對象權限，而 *PUBLIC 權限則根據 QCRTAUT 系統值設置為 *CHANGE。

因而，與 QPGMR 組配置文件相關聯的所有用戶都允許訪問、修改甚至是刪除 PGMRXXX 和 PGMRUSR 這兩種架構中的 EMPLOYEE 表。

圖 6. 使用系統命名創建表

使用 SQL 命名創建表、視圖和索引。

使用 SQL 命名時，會應用不同的規則：

• 如果某個用戶配置文件的名稱與在其中創建表、視圖或索引的架構的名稱相同，那么該用戶配置文件就是表的所有者。

• 如果不存在與架構名稱相同的用戶配置文件，那么所有者將是用戶配置文件或者組配置文件，具體情況取決于用戶配置文件定義中的 OWNER 選項設置。
• 使用 SQL 命名創建架構以外的數據庫對象時，用戶配置文件定義中的 OWNER 選項設置將被考慮，組配置文件將成為數據庫對象的所有者。

圖 7. 使用 SQL 命名在與用戶配置文件不匹配的架構中創建表 展示了用戶 PGMRGRP2 在架構 PGMRXXX2 中創建的 EMPLOYEE 表的權限結果。

EMPLOYEE 表的所有者是 QPGMR 組配置文件。所有者 QPGMR 的對象權限值是 *ALL，而 *PUBLIC 權限設置為 *EXCLUDE。因此，與 QPGMR 組配置文件相關的所有用戶均不允許訪問 EMPLOYEE 表，而且也不允許修改或刪除表。

圖 7. 使用 SQL 命名在與用戶配置文件不匹配的架構中創建表

在下一個示例（圖 8. 使用 SQL 命名在匹配用戶配置文件的架構中創建表）中，用戶 PGMRGRP2 嘗試在 PGMRUSR2 架構中創建 EMPLOYEE 表。

該架構之前是由用戶 PGMRGRP2 使用 SQL 命名，通過 CREATE SCHEMA 語句創建的。由于的確有一個名為 PGMRUSR2 的用戶配置文件，因此該用戶配置文件將成為架構的所有者，獲得該架構的 *ALL 對象權限，而 *PUBLIC 權限則設置為 *EXCLUDE。

CREATE TABLE 語句執行將失敗，并提供 24501 SQL 狀態值，這是因為 PGMRGRP2 未獲得 PGMRUSR2 架構的授權，即便該用戶創建了此架構也是如此。(圖 5. 使用 SQL 命名創建架構 展示了 PGMRGRP2 不具備 PGMRUSR2 架構權限的情況）。

為了允許 PGMRGRP2 使用 SQL 命名在 PGMRUSR2 架構中創建表或任何對象，用戶配置文件或者相關的 QPGMR 組配置文件必須獲得架構的顯式授權，執行 GRTOBJAUT 或 EDTOBJAUT 命令均可實現此目標。

圖 8. 使用 SQL 命名在與用戶配置文件匹配的架構中創建表

假設 QPGMR 組配置文件已顯式獲得了 PGMRUSR2 架構的權限，那么 PGMRGRP2 用戶就能夠在這個架構中創建 EMPLOYEE 表。

由于表是使用 SQL 命名創建的，所以 PGMRUSR2 是一個現有用戶配置文件，因此這個用戶配置文件將再次成為 EMPLOYEE 表的所有者，擁有 *ALL 對象權限，且 *PUBLIC 對象權限設置為 *EXCLUDE，如 圖 9. 架構特權 = 用戶配置文件和表 中所示。

在這種情況下，PGMRGRP2 用戶能夠創建表，但不允許使用表。PGMRGRP2 用戶或者 QPGMR 組配置文件必須獲得顯式授權才能訪問它們之前創建的對象。

圖 9. 架構特權 = 用戶配置文件和表

可能出現問題的情況

使用 SQL 命名為現有應用程序創建數據庫對象可能會在 IBM i 上導致意外問題。

假設現有原材料管理應用程序的所有數據庫對象均存儲在一個名為 MAWI 的庫中。這個庫是很久之前使用 CRTLIB 命令創建的。MAWI 庫的所有者是 QPGMR 組配置文件。MAWI 庫的 *PUBLIC 對象權限是 *CHANGE。

在這個系統中，所有用戶配置文件名稱都結合了姓氏的前兩個字符和名字的前兩個字符。人力資源部門的一名數據錄入員工叫做 Willy Maier，因此他的用戶配置文件是 MAWI。

如果一名開發人員使用 SQL 命名在 MAWI 庫中創建了一個新表或視圖，那么這個新表的所有者將是 Willy Maier，原因在于他的用戶配置文件與庫名稱匹配。僅有 MAWI 用戶配置文件才具有新表或者視圖的訪問權限。開發人員和其他任何用戶都沒有此權限，因為 SQL 命名默認情況下會強制性將 *PUBLIC 訪問權限設置為 *EXCLUDE。

回頁首

SQL 例程

SQL 例程就是可執行的 SQL 對象，類似于高級語言 (HLL) 程序。SQL 例程這個術語用于表示存儲過程、觸發器或者用戶定義的函數 (UDF)。

這些例程是使用 SQL 或者高級語言（例如 RPG 或 COBOL）編寫的。無論是哪種情況，存儲過程或 UDF 都是使用以下 SQL 語句之一創建的：

• CREATE PROCEDURE
• CREATE FUNCTION

SQL 例程的所有權和對象權限

對于系統命名和 SQL 命名來說，確定對象所有權和權限的規則均與用戶創建表、視圖或索引的規則相同。

例程中嵌入的 SQL 語句將根據創建例程時使用的命名規范執行，即便可能使用不同的命名模式在運行時環境中調用 SQL 例程。

例如，某個存儲過程是通過使用 SQL 命名的接口來創建的。如果從包含嵌入式 SQL、默認使用系統命名的 RPG 程序中調用該存儲過程，那么 RPG 程序中的嵌入式 SQL 語句會使用系統命名來執行，而存儲過程內的 SQL 語句會使用 SQL 命名來執行。

例程對象的所有權和訪問權限僅用于調用此例程。對象所有權和權限值可能會也可能不會應用于例程本身執行的 SQL 語句。應用于例程運行的 SQL 請求的權限 ID（或者用戶配置文件）取決于創建例程時使用的命名規范，以及例程所執行的 SQL 語句是靜態的還是動態準備的。

使用系統命名時，DB2 會利用調用例程的用戶配置文件。使用 SQL 命名執行例程內的靜態 SQL 語句時，DB2 在默認情況下會使用例程的所有者對靜態 SQL 語句執行授權處理。

默認情況下，調用例程的用戶配置文件始終應用于例程執行的動態 SQL 語句，與使用系統命名還是 SQL 命名無關。

應用于靜態和動態 SQL 語句的安全性驗證和執行的用戶配置文件可以在 SET OPTION 語句中手動控制，方法是指定 USRPRF（靜態 SQL 語句的用戶配置文件）和 DYNUSRPRF（動態 SQL 語句的用戶配置文件）選項。

USERPRF 選項可以設置為以下值之一：

• *NAMING：*USER 用于系統命名，*OWNER 用于 SQL 命名
• *OWNER：靜態 SQL 語句使用所有者的權限執行
• *USER：靜態 SQL 語句使用用戶權限執行

選項 DYNUSRPRF 可以設置為：

• *USER：系統命名和 SQL 命名的默認值。動態 SQL 語句使用用戶權限執行
• *OWNER：動態 SQL 語句使用所有者權限執行

如果您正在使用 SQL 命名，希望動態 SQL 語句由執行靜態 SQL 語句的同一個用戶配置文件執行，那么可能需要同時將這兩個選項 USRPRF 和 DYNUSRPRF 設置為 *OWNER 或 *USER。

以下 SQL 語句顯示了使用 SQL 命名創建的一個 SQL 存儲過程的刪減版源代碼。在運行時，將根據 SET OPTION 子句中指定的值，由 *OWNER 來執行過程中嵌入的所有靜態和動態 SQL 語句。

清單 10. 創建過程

Create Procedure PGMRUSR2.HSINFO (In Parm1 Integer) Dynamic Result Sets 1 Language SQL Set Option DYNUSRPRF = *OWNER, USRPRF = *NAMING Begin /* Routine code goes here */ End ;

回頁首

觸發器

觸發器是特殊類型的 SQL 例程。觸發器程序鏈接到一個表或者一個 SQL 視圖，并且通過數據庫管理器為指定事件（插入、更新或刪除）激活它。

觸發器程序的所有權與其他所有 SQL 例程的確定方式相同，但對象和執行權限是由 CREATE TRIGGER 語句單獨設置的。

*PUBLIC 對象權限將設置為 *EXCLUDE，無論使用的是系統命名還是 SQL 命名。對于使用系統命名創建的其他所有 SQL 對象，*PUBLIC 對象權限都將設置為 QCRTAUT 系統值。

下面的示例展示了使用系統命名創建的 SQL 觸發器的源代碼。

清單 11. 創建觸發器

CREATE TRIGGER PGMRUSR/TRGEMPLOYEE BEFORE INSERT ON PGMRUSR/EMPLOYEE REFERENCING NEW ROW AS N FOR EACH ROW MODE DB2ROW BEGIN ATOMIC /* Source code goes here */ END;

圖 10 展示了使用系統命名創建的這個觸發器程序的特權圖。所有者是 QPGMR 組配置文件，所有者擁有所有對象權限，而 *PUBLIC 對象權限設置為 *EXCLUDE。

圖 10. 使用系統命名創建的觸發器

如果需要使用 SQL 命名在與某個現有用戶配置文件同名的架構中創建觸發器程序，那么必須顯式為創建者授予表或視圖的權限，或者為其提供特殊權限 *ALLOBJ 或 *SECADM。觸發器程序的所有者是與架構同名的用戶，或者創建者用戶配置文件或其相關的組配置文件，具體取決于創建者的用戶配置文件定義中的 OWNER 選項設置。

下面的 圖 11. 使用 SQL 命名創建的觸發器 展示了由用戶 PGMRGRP2 使用 SQL 命名在架構 PGMRUSR2 中創建的觸發器程序的特權圖。由于 PGMRUSR2 也是一個現有用戶配置文件，因此這個用戶配置文件將成為觸發器程序的所有者。所有者 PGMRUSR2 將獲得 *ALL 對象權限，而 *PUBLIC 對象權限則設置為 *EXCLUDE。

圖 11. 使用 SQL 命名創建的觸發器

無論創建觸發器時使用了哪種命名規范，觸發器都將使用通過觸發器程序所有者采用的權限激活。

回頁首

授予/撤銷權限

無論數據庫對象是使用系統命名還是 SQL 命名創建的，都必須仔細檢查所有權和對象權限。如果默認行為不能滿足您的安全性需求，那么可以使用 GRANT 或 REVOKE SQL 語句來調整設置。

任何用戶或組配置文件的對象權限（即便是 *PUBLIC）均可使用 GRANT 語句設置。如果對象授權必須移除，則可以使用 REVOKE 語句?？梢酝瑫r使用 GRANT 和 REVOKE 語句來處理所有可訪問或執行的數據庫對象（架構和觸發器除外）。

此外還可以使用 GRTOBJAUT（授予對象權限）和 EDTOBJAUT（編輯對象權限）CL 命令來修改數據庫對象的對象權限。不過，使用 CL 命令和 SQL 語句提供權限時略有差異。

回頁首

設置會話權限

在使用 SQL 命名時，SET SESSION AUTHORIZATION 和 SET SESSION USER 語句可能會影響對象所有權和權限。

在建立一個連接之后，可以使用 SET SESSION AUTHORIZATION 或 SET SESSION 語句，將用戶配置文件切換到另外一個用戶配置文件（權限 ID），并采用該用戶配置文件的訪問權限。您已經學習了在使用 SQL 命名創建對象時如何將用戶配置文件值應用于對象所有權和授權。

回頁首

結束語

至此，您應該已經很好地了解了為何使用系統命名和 SQL 命名創建的 DB2 對象的所有權和訪問權限指派方式有所不同。

由于存在這些不同的行為，因此您應該為使用 SQL 創建的所有數據庫對象（或者至少是一個架構中的所有數據庫對象）確定一種命名規范方法。

• 如果您的目的是設計一個能夠在不同數據庫系統上運行的應用程序，那么 SQL 命名是實現最大限度的可遷移性的正確方法。
• 如果您僅使用 DB2 for i，而且必須維護較為陳舊的應用程序與多種基于 DDS 的對象和 SQL 數據庫對象，還要使用 IBM i 特有的對象權限（例如組配置文件），那么系統命名將是您更好的選擇。

現在，祝您使用系統命名或 SQL 命名規劃、設計、創建和維護數據庫對象時一帆風順。

總結

以上是生活随笔為你收集整理的系统命名与 SQL 命名之争 - 第 1 部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。