blocks|key|1193903|text|虽然我确信加密的存储过程至少在PostgreSQL中是一个简单的编程问题(MySQL和存储过程在一起的历史并不长)，但有了PgSQL的自定义语言支持，我看不出这有什么用。它们将需要在某个时刻被解密以执行它们，因此管理数据库/数据库服务器的任何人都将能够以足够的技能获得未加密的sp。DBA已经可以看到所有的数据、所有的关系，这似乎使得混淆SP代码变得毫无意义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1193904|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

While I'm sure encrypted stored procs are a simple matter of programming in PostgreSQL at least (MySQL and stored procs do not have a long history together), with PgSQL's custom languages support, I don't see why this would be useful. They would need to be decrypted at some point to execute them so anyone who administers the database/database server would be able to, with sufficient skill, be able to get the unencrypted sp. The DBA can already see all the data, all the relationships, seemingly making obfuscating the SP code pointless.

blocks|key|670236|text|如果这真的是一个很酷的功能(我从来没有用过，也不需要它)，我建议你在推荐的邮件列表中注册一个新的功能请求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|670237|Postgresql：http://www.postgresql.org/community/lists/|offset|length|670238|MySQL：http://lists.mysql.com/|670239|entityMap|0|LINK|mutability|MUTABLE|url|http://www.postgresql.org/community/lists/|1|http://lists.mysql.com/^0|0|B|16|0|0|6|N|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

if this is a really cool feature (I have never used it, nor needed it), I suggest you register a new feature request in the repected mailing lists.

Postgresql:
<a href="http://www.postgresql.org/community/lists/" rel="nofollow noreferrer">http://www.postgresql.org/community/lists/</a>

MySQL:
<a href="http://lists.mysql.com/" rel="nofollow noreferrer">http://lists.mysql.com/</a>

blocks|key|1201333|text|这是正确的，因为没有人需要它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1201334|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Properly because nobody has had a need for it.

blocks|key|3889802|text|因为加密的存储过程显然不是一个好主意。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3889803|业务编程不应该以DBA为中心，因为DBA对整个应用程序代码具有独家访问权限，这些代码是用SQL编写的，并存储在数据库中，并经过加密。这条路就是疯狂的。|3889804|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Because encrypted stored procedures are a distinctly bad idea.

Business programming should not be centered around the DBA who has sole access to the entirety of the application code, which is written in SQL and stored, encrypted, in the database. That way lies madness.

blocks|key|670481|text|我想最重要的原因是开源数据库是由非常聪明的人编写的。谁知道，加密这个过程实际上并不能保护你免受一些流氓管理员访问它的未加密源代码的影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|670482|在专有软件世界里，人们倾向于认为“加密就能解决问题”。但是，当你考虑到你的数据库源代码是开放的，这意味着加密必须以一种非常智能的方式来完成，并且并不是在所有情况下都有效。|670483|基本上-如果你想保护你的数据不被“磁盘被盗”-你可以使用硬盘加密。如果要保护备份，请对备份进行加密。但是，如果你想保护数据库免受“太好奇”的管理员雇佣的律师的影响，而不是试图去考虑(或多或少)隐藏数据的不可能的方法。|670484|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I guess the most important reason is that open source databases are written by really smart people. Who know, that encrypting the procedure doesn't actually protect you from some rogue admin getting access to unencrypted source of it.

In proprietary software world, people tend to think that "encrypting will solve the problem". But when you'll consider the fact that your source of database is open, it means that encrypting has to be done in a really smart way, and doesn't work in all cases.

Basically - if you'd want to protect your data against "disk being stolen" - you can use hard disk encryption. If you want to protect backups - encrypt backups. But if you want to protect the database against "too curious" admin - hire lawyers, and not try to think about (more or less) impossible ways to hide the data.

blocks|key|1201492|text|回答“加密存储的proc的令人信服的理由？”我见过当应用程序在存储过程中使用相当复杂的专有逻辑，并且应用程序驻留在客户数据库系统上时，就会使用这种方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1201493|我知道这不是一个完美的解决方案，但它阻止了窃取代码或阻止客户端DBA更改他们不应该接触的东西的琐碎尝试。|1201494|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

To answer the "compelling reasons to encrypt the stored procs?" question I've seen this used when an application uses fairly complex proprietary logic in the stored procedures and the application is hosted on a customers database system.

I am aware that this is not a perfect solution but it stops trivial attempts to rip off the code or prevent the clients DBA from altering stuff they shouldn't be touching.

blocks|key|670439|text|当我过去为InterBase提供支持时，这个问题会时不时地出现。客户需要此功能的原因是为了保护他们在开发商业软件应用程序时对“知识产权”--即源代码--的投资。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|670440|当然，您可以限制对C%2B%2B、Java或Delphi等编译语言的源代码的访问。客户可以对编译后的代码进行反向工程，并了解您的算法，但这与访问源代码不同。有很多信息不是通过反编译获得的。|670441|但是，如果您在触发器和存储过程的主体中实现应用程序的某些部分，则购买该软件产品的任何客户都可以读取这些触发器和存储过程。也许有办法隐藏或加密这些代码，但它不能是不可逆的加密，否则数据库引擎将无法运行这些代码。|670442|InterBase将触发器/过程源代码的副本存储在BLOB字段中，并将相同例程的编译版本存储在另一个BLOB中。因此，您可以将包含源代码的BLOB字段设为空，而保留编译后的代码。但这只与发布已编译的应用程序代码一样有效；它仍然可以由具有足够技能和动机的盗版者进行逆向工程。|670443|我不知道在MySQL或PostgreSQL中是否可以使用NULL-out-+the+-source-BLOB技巧。|670444|底线是：|670445|在您将数据库中的数据或元数据交给客户之后，没有办法绝对限制对这些数据或元数据的访问。|670446|值得注意的是，这是一个人为的要求。我从来没有听说过有人因为触发器和存储过程中有可读代码而被窃取了他们的软件IP。无论如何，这是没有必要的。盗版者可以使用其他方法复制您的软件。|670447|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

When I used to provide support for InterBase, this question would come up from time to time. The reason customers wanted this feature is to protect their investment of "intellectual property" -- i.e. source code -- when they develop commercial software applications. 

Of course you can restrict access to the source code of a compiled language like C++, Java, or Delphi. A customer can reverse-engineer compiled code and learn something of your algorithms, but that's not the same as having access to the source code. There's a lot of information they don't get by decompiling.

But if you implement parts of your application in the bodies of triggers and stored procedures, these remain readable by any customer who buys the software product. There might be ways to obscure or encrypt this code, but it cannot be irreversible encryption, or else the database engine wouldn't be able to run the code.

InterBase stored a copy of the trigger/proc source in a BLOB field, and a compiled version of the same routine in another BLOB. So you could NULL out the BLOB field containing the source, and leave the compiled code. But this is only as effective as shipping compiled application code; it can still be reverse-engineered by a pirate with enough skill and motivation.

I don't know if the NULL-out-the-source-BLOB trick is possible in MySQL or PostgreSQL.

The bottom line is:

<h2>There is no way to absolutely restrict access to data or metadata in a database after you hand it over to a customer.</h2>

And it's worth noting that this is an artificial requirement. I've never heard of anyone who had their software IP stolen due to having readable code in triggers &amp; stored procedures. It's not necessary anyway. A pirate can use other means to duplicate your software.

blocks|key|670525|text|imho，这是一个加密存储过程/视图的好场景。我工作的公司写了一个数据库驱动的应用程序。我们将数据库放置在客户端网络上的sql服务器或运行SQL+Express的工作站上(适用于用户较少的较小客户端)。存储过程和视图用于审计客户端提供给我们的数据。为了防止客户的DBA或IT人员简单地窃取或窃取专有算法，我们对存储过程和视图进行了加密。我们在我们的版本控制软件(即Visual+Source+Safe)中维护原始的纯文本脚本，以便我们的支持团队可以查看过程或视图是如何编码的。我希望一些开源引擎支持它，这样我们就可以摆脱SQL+Express的限制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|670526|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Here is, imho, a good scenario for encrypting stored procedures/views. The company I work for writes a database driven app. We house the database on the client network on a sql server or a workstation running SQL Express (for smaller clients with less users). The stored procedures and views are used to audit data given to us by the client. In effort to keep the client's DBA or IT staff from simply ripping us off or stealing the proprietary algorithms, we encrypt the stored procedures and views. We maintain the original, plaintext scripts in our version control software (ie Visual Source Safe) so that a support team from our end has access to see how the procedure or view is coded. I wish some of the Open Source engines supported it so we could move away from the limitations of SQL Express.

blocks|key|3890140|text|(RE:粗体文本)我认为这是不太正确的。如果你曾经看过ACT！联系管理他们将MSSQL+Express安装为单独的实例，并对SQL和数据库使用私有用户名和密码。因此，有一些方法可以不与您的客户共享数据库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3890141|不是要挑起宗教战争，但像MSSQL这样的db服务器有proc加密功能。其想法是，如果您是ISV，您可以使用加密procs部署您的解决方案来保护您的IP。作为DBA，您无法解密这些过程。|3890142|我的2分|3890143|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

(RE: bold text) I don't think this is quite right. If you have ever looked at ACT! contact management they install MSSQL Express as a separate instance and use a private username &amp; password for SQL and then the db. So there are ways of not sharing the database with your clients.

Not to start a religious war, but db servers like MSSQL has proc encryption capabilities. The idea being, if you are an ISV you can deploy your solution with encrypted procs to protect your IP. As a DBA you cannot unencrypt these procs.

My 2 cents

Why opensource database like Postgresql and Mysql don't have encrypted stored proc?

Is it because of their innate open source philosophy?

What are the compelling reasons to encrypt the stored procs?

Why opensource database like Postgresql and Mysql don't have encrypted stored proc?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

为什么像Postgresql和Mysql这样的开源数据库没有加密的存储进程？是不是因为他们天生的开源哲学？加密存储过程的令人信服的理由是什么？

问为什么像Postgresql和Mysql这样的开源数据库没有加密的存储进程？
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么像Postgresql和Mysql这样的开源数据库没有加密的存储进程？EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么像Postgresql和Mysql这样的开源数据库没有加密的存储进程？
EN