PL/SQL 中包的别名或同义词答案

【问题标题】：Alias or synonym for a package in PL/SQLPL/SQL 中包的别名或同义词
【发布时间】：2013-10-07 06:49:25
【问题描述】：

我有一个系统，我将我的功能分成几个不同的包。目前我正在使用 packagename.object 的点符号调用函数和过程

我的一些包名（由于公司编码标准）相当长

我可以为包创建别名/同义词以缩短我的代码吗？

ie：代替 pkge_member_utilities.CreateMember，我可以为包创建一个同义词/别名“util”，然后在我的代码中使用 util.CreateMember

我已经阅读了 CREATE SYNONYM 的文档，但它似乎被用于立即执行，而我想在我的代码中引用同义词

再次为含糊的术语道歉，因为我来自 Java 背景

非常感谢您的宝贵时间

迈克

【问题讨论】：

看来您是故意违反公司的编码标准，不是吗？
@beherenow 我是吗？如果我给包提供正确的名称，在代码中通过别名引用它不会真的违反标准/最佳实践吗？
按照约定命名对象只是将其包装在同义词中并仅在对象浏览器中查看实际名称是没有意义的，不是吗？为什么不直接将其命名为util 并完成它呢？ ) 任何给定约定的一个要点是提供代码可读性 - 您是否通过混淆实际子程序名称并基本上在现有约定之上引入您自己的约定（即“util = pkg_member_utilites”）来增加可读性？ )
@beherenow - 我知道你现在从哪里来，完全同意。感谢您的澄清。
PL/SQL is missing import feature 在some other languages 中可用。我也认为为此使用 SQL 同义词充其量是有问题的。

标签： oracle plsql

【解决方案1】：

create public synonym util for <owner>.pkge_member_utilities;

【讨论】：

我应该把这个声明放在哪里才能在包体中使用它？
@Mike 你没有把它放在包体中。 synonym 是一个单独的数据库对象，创建它的方式与创建包的方式相同

【解决方案2】：

虽然我同意上面的 cmets，但这主要是为了打破标准。但是，有时标准是可怕的，只要有合适的单元测试，在合适的情况下，有什么害处？

create or replace package long_package_name as
  function give_me_zero return number;
end;
/

create or replace package body long_package_name as
  function give_me_zero return number is begin return 0; end;
end;
/

create or replace synonym pkg for long_package_name;

-- either works the same
select long_package_name.give_me_zero from dual;
select pkg.give_me_zero from dual;

【讨论】：

你问有什么害处？我问有什么好处？
@user272735 - 收获？可能是代码可读性。如果刚获得 EMBA 的开发经理决定所有包都需要命名为 pkg_{module#}_{customer#}，这会导致一个包用于名为 PKG_3498_U3450S6 的销售订单 API 而不是 SALES_ORDER_API。你有广泛使用 PKG_3498_U3450S6 的代码。另一个可能的收获：如果某些 dillweed 使用区分大小写的名称作为包名称，而您想对它们进行去大小写敏感呢？
我想说的是，事情变得更复杂了。例如，如果我有一个包 myschema.doingSomestuff@aDBLink 并且它有过程 myProc1、myProc2，那么在包顶部执行与 Java 导入等效的操作会很好。这意味着在那个包中我可以引用 myProc1 和 myProc2 而不用在它们前面加上 myschema.doingSomestuff@aDBLink 或者不必创建同义词。