为什么像Postgresql和Mysql这样的开源数据库没有加密的存储过程？
是因为他们天生的开源哲学吗？
加密存储过程有哪些令人信服的理由？
答案 0 :(得分：6)
虽然我确定加密的存储过程是一个简单的PostgreSQL编程问题（MySQL和存储过程没有很长的历史），PgSQL的自定义语言支持，我不明白为什么会这样有用。他们需要在某些时候解密才能执行它们，因此管理数据库/数据库服务器的任何人都能够以足够的技巧获得未加密的sp。 DBA已经可以看到所有数据，所有关系，似乎使SP代码混淆无意义。
答案 1 :(得分：4)
如果这是一个非常酷的功能（我从未使用它，也不需要它），我建议你在备受推荐的邮件列表中注册一个新的功能请求。
PostgreSQL的： http://www.postgresql.org/community/lists/
MySQL的： http://lists.mysql.com/
答案 2 :(得分：4)
正确是因为没有人需要它。
答案 3 :(得分：4)
因为加密的存储过程是一个非常糟糕的主意。
业务编程不应该以DBA为中心，DBA只能访问整个应用程序代码，这些代码是用SQL编写的，并在数据库中存储，加密。那种方式就是疯狂。
答案 4 :(得分：2)
我想最重要的原因是开源数据库是由非常聪明的人编写的。谁知道，加密程序实际上并没有保护你免受某些流氓管理员访问未加密的来源。
在专有软件世界中，人们倾向于认为“加密将解决问题”。但是，当您考虑到数据库源是开放的这一事实时，这意味着加密必须以非常智能的方式完成，并且在所有情况下都不起作用。
基本上 - 如果您想保护您的数据免受“磁盘被盗” - 您可以使用硬盘加密。如果要保护备份 - 加密备份。但是，如果你想保护数据库免受“过于好奇”的管理员 - 聘请律师，而不是试图（或多或少）不可能的方式隐藏数据。
答案 5 :(得分：1)
回答“加密存储过程的令人信服的理由？”问题我已经看到这在应用程序在存储过程中使用相当复杂的专有逻辑并且应用程序托管在客户数据库系统上时使用。
我知道这不是一个完美的解决方案，但它会阻止扯掉代码或阻止客户DBA改变他们不应该接触的内容的琐碎尝试。
答案 6 :(得分：1)
当我以前为InterBase提供支持时，这个问题会不时出现。客户想要此功能的原因是为了保护他们在开发商业软件应用程序时对“知识产权”（即源代码）的投资。
当然，您可以限制对C ++，Java或Delphi等编译语言的源代码的访问。客户可以对编译的代码进行逆向工程并学习算法，但这与访问源代码不同。他们不通过反编译获得了大量信息。
但是，如果您在触发器和存储过程的主体中实现应用程序的某些部分，那么购买该软件产品的任何客户都可以读取这些内容。可能存在隐藏或加密此代码的方法，但它不能是不可逆转的加密，否则数据库引擎将无法运行代码。
InterBase在BLOB字段中存储了触发器/ proc源的副本，并在另一个BLOB中存储了相同例程的编译版本。因此，您可以将包含源的BLOB字段清空，并保留已编译的代码。但这仅与运送已编译的应用程序代码一样有效;它仍然可以由具有足够技能和动力的海盗进行逆向工程。
我不知道在MySQL或PostgreSQL中是否可以使用NULL-out-the-source-BLOB技巧。
底线是：
值得注意的是，这是一个人为的要求。我从来没有听说过因为触发器中的可读代码而导致他们的软件IP被盗的人。存储过程。反正没有必要。盗版者可以使用其他方式复制您的软件。
答案 7 :(得分：1)
这是imho，一种加密存储过程/视图的好方案。我工作的公司写了一个数据库驱动的应用程序。我们在sql server或运行SQL Express的工作站上为客户端网络提供数据库（对于用户较少的小型客户端）。存储过程和视图用于审核客户端提供给我们的数据。为了使客户的DBA或IT人员不仅仅是剥离我们或窃取专有算法，我们对存储过程和视图进行加密。我们在我们的版本控制软件（即Visual Source Safe）中维护原始的纯文本脚本，以便我们的支持团队可以访问以查看过程或视图的编码方式。我希望一些开源引擎支持它，这样我们就可以摆脱SQL Express的限制。
答案 8 :(得分：1)
（RE：粗体文字）我不认为这是对的。如果你曾经看过ACT！联系人管理他们将MSSQL Express安装为一个单独的实例并使用私人用户名＆amp; SQL的密码然后是db。因此，有一些方法可以不与您的客户共享数据库。
不要发动宗教战争，但像MSSQL这样的数据库服务器具有proc加密功能。我们的想法是，如果您是ISV，您可以使用加密过程部署您的解决方案以保护您的IP。作为一名DBA，你无法解密这些过程。
我的2美分