系统命名与 SQL 命名之争 - 第 1 部分
创建数据库对象时，开发人员可以选择一种命名方法，可以选择遵循传统 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 界面来创建数据库对象，那么可以按照如下方法预定义要使用的命名：
打开您的连接，右键单击数据库图标，选择 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 语句）执行存储在源物理文件成员或者 IFS（集成文件系统）中的 SQL 语句，那么可以在 RUNSQLSTM 命令中使用 Naming 参数指定命名规范，如下例所示。使用 SQL 命名即可执行指定的 SQL 脚本。
清单 1. RUNSQLSTM 设置命名规范
RUNSQLSTM SRCFILE(MYSCHEMA/QSQLSRC) SRCMBR(MYSCRIPT) NAMING(*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 设置
可以通过在连接 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 函数时，命名规范是一个可以通过执行 SQLSetConnectAttr 函数设置的属性。为了将命名规范设置为系统命名，必须将 SQL_ATTR_DBC_SYS_NAMING 常量传递给属性参数，并将 SQL_TRUE 常量传递给属性值参数，如下例所示。
清单 6. 使用 SQLCLI 设置连接属性
rc = SQLSetConnectAttr(ConnHandle: SQL_ATTR_DBC_SYS_NAMING: SQL_TRUE: 4); |
如果您希望更改在交互式 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 命名创建架构时，规则将更加复杂：
- 如果一个用户配置文件与已有架构同名，则架构的所有者和在此架构中 创建的所有对象的所有者均为该用户配置文件。例如，一名开发人员为基于 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 命名时，会应用不同的规则：
- 如果某个用户配置文件的名称与在其中创建表、视图或索引的架构的名称相同，那么该用户配置文件就是表的所有者。
- 如果不存在与架构名称相同的用户配置文件，那么所有者将是用户配置文件或者组配置文件，具体情况取决于用户配置文件定义中的 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 对象，类似于高级语言 (HLL) 程序。SQL 例程这个术语用于表示存储过程、触发器或者用户定义的函数 (UDF)。
这些例程是使用 SQL 或者高级语言（例如 RPG 或 COBOL）编写的。无论是哪种情况，存储过程或 UDF 都是使用以下 SQL 语句之一创建的：
- CREATE PROCEDURE
- CREATE FUNCTION
对于系统命名和 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 语句。可以同时使用 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 命名规划、设计、创建和维护数据库对象时一帆风顺。
