如今，数据库是任何基于 Web 的应用程序的关键组成部分，它们使网站能够提供各种动态内容。由于数据库中可能会存储非常敏感或机密的信息，因此您应该认真考虑保护您的数据库。
为了检索或存储任何信息，您需要连接到数据库，发送一个合法的查询，获取结果，然后关闭连接。如今，这种交互中常用的查询语言是结构化查询语言 (SQL)。了解攻击者如何 篡改 SQL 查询。
如您所想，PHP 本身无法保护您的数据库。以下部分旨在介绍在 PHP 脚本中访问和操作数据库的基本知识。
请记住这条简单的规则：纵深防御。您采取的措施来提高数据库保护的越多，攻击者成功暴露或滥用任何存储信息的可能性就越小。良好的数据库架构和应用程序设计可以解决您最担心的问题。
关于将业务逻辑卸载到数据库引擎支持的视图和查询，我尽可能避免这样做，只在这样做可以极大地提高效率和用户响应时间时才这样做。
例如，在我所在的地方，有数据库人员和应用程序人员。尝试对现有应用程序进行分析很容易变成一场毫无结果的搜索。
应该尽可能使数据库与应用程序保持分离，以便可以轻松地用其他数据库或数据库提供商替换它，而设置新数据库的人员只需付出最少的认知努力。如果功能已卸载到数据库，则需要进行额外的测试以确保触发器和视图的正确执行，并且它们按预期工作。
此外，将所有业务逻辑与应用程序保持在一起，允许所有功能和文档在一个地方可读，这在对现有应用程序进行后续分析时非常宝贵。最糟糕的情况是功能分散在各个地方。
将所有内容与应用程序保持在一起意味着由一组人员负责，在我的情况下，是应用程序人员。减少了来回的请求。请记住，任何时候都有人员参与进来，例如要求 DBA 为您创建视图或触发器，该 DBA 必须对其工作承担责任，无论要求是什么，都会导致更多的官僚主义和管理复杂性。关于将逻辑放在哪里，最好不要对这一点采取教条式的态度。将逻辑放在数据库中可能有一些安全优势，但它也有其他安全陷阱（例如，在某些环境中，存储过程中的 SQL 注入可能是可能的）。同样，它也可能有一些可移植性优势和劣势。
真正的问题是你想问自己想要什么可移植性。如果您将其放在数据库中，它将更容易将用不同开发环境编写的程序集成在一起，同时将安全陷阱降至最低。如果您将其放在应用程序中，那么您必须在中间件级别创建接口。两种方法都是可行的。另一方面，如果您正在编写您希望在 MS SQL 商店和 Oracle 商店中部署的软件，那么您必须编写可移植的 SQL（避免陷阱）并将逻辑放在应用程序中。
当我们开始重写 LedgerSMB 代码库时，我们决定将逻辑移到数据库中，因为这将更容易将安全措施移植到非常不安全的代码库（通过不信任应用程序），并且因为我们希望支持除 Perl 之外的其他语言。几年后，这正在结出硕果，事实上我正在阅读手册，因为我正在用 PHP 编写集成库。我不是一个 PHP 高手（自从 PHP 4.x 以来就没有用 PHP 编程过），但我可以编写模块，让其他人编写代码来安全地与 LedgerSMB 的数据库逻辑进行交互。您可以将存储过程视为在应用程序之间共享的命名查询，或者视为数据库的 API。但同样，这种方法并不普遍适用。
如果在不同数据库之间移植不是主要需求，那么我认为最好的方法是在 SQL 查询中尽可能多地做，并将这些查询放在数据库中。几百行 SQL 代码可以替换几千行 Perl 或 PHP 代码，并且在本质上更容易调试。当然，这并不适合所有人。下面的帖子充其量只是极端的 POV。
假设您希望更改数据库供应商，与假设您可能希望将 PHP 代码移植到 Java 等语言一样没有道理。无论哪种情况，您的业务规则在哪里都只是一个运气问题。
即使您的业务规则位于您的应用程序中，SQL 也不可移植。例如，Oracle 的外部联接和透视查询可能与其他供应商的软件中的查询看起来完全不同（特别是从 8i 或更低版本）。仅此一项就意味着更改数据库供应商需要在数据库或应用程序中对您的业务规则进行工作。
将您的规则放在数据库中，并保持应用程序中的 SQL 代码简单，至少可以将工作保留在数据库中，如果您需要更改数据库供应商。如果您在 PHP 中有这些规则，您将不得不更改两者。