在应用程序中存储一些记录,在数据库中存储一些记录

时间:2011-12-03 17:21:32

标签: php mysql web-applications

我有一个应用程序,似乎将一些硬编码的记录存储在应用程序代码中而不是数据库中的条目,并且能够在查看时将两者合并为一个共同的结果集记录。这种方法有什么缺陷吗?

首先,除了应用程序开发人员想要的时候,它似乎更容易强制执行永远不会编辑/删除记录。其次,在某些情况下,例如安装第三方模块,可以从其配置中读取记录,而不是在数据库中执行插入(带有相关的维护问题)。

一些常见的例子:

                                       In the application        In the database
-----------------------------------    ------------------        ----------------------
customers                              (none)                    all customers
HTML templates                         default templates         user-defined templates
'control panel' interface languages    default language          additional languages
Online shop payment processors         all payment processors    (none)

所以,我认为我有三种选择,具体取决于场景:

  1. 数据库中的所有记录
  2. 应用程序中的一些记录,数据库中的一些记录
  3. 应用程序中的所有记录
  4. 似乎有两种方法可以实现它:

    1. 数据库中的所有记录:
      • 列可以标记为“可编辑”或“已锁定”
      • 否定ID可以代表锁定值,而正ID可以代表可编辑
      • 奇数ID表示已锁定,偶数ID表示可编辑...
    2. 某些记录存在于应用程序中(作为变量,数组或对象......)
    3. 有没有标准的方法来处理这种情况?我错过了一些非常明显的解决方案吗?

      我正在使用MySQL和php,如果这改变了你的答案!

3 个答案:

答案 0 :(得分:1)

通过“在应用程序中”,您是说这些记录存在于文件系统中,应用程序可以访问吗?

这完全取决于您正在构建的应用程序。有几点需要考虑,特别是在代码复杂性和性能方面。虽然我没有足够的关于您的项目的信息来建议具体细节,但这里有一些要记住的指示:

为所有内容提供两个可能的存储库会增加代码的复杂性。这意味着可读性将下降,奇怪的错误将开始出现,难以追踪。在大多数情况下,采用可能有效的最简单的解决方案符合您的最佳利益。如果你看一下大的PHP / MySQL软件包,你会发现即使代码本身有很多默认值,数据也几乎完全来自数据库。如果您无法使用最简单的解决方案(即将所有内容存储在文件中),这可能是一个合理的策略。

重型数据库参与的重大缺点是性能。您绝对应该跟踪应用程序中任何典型代码路径的所有数据库调用。如果您非常依赖大量查询,则必须使用大量缓存。跟踪发生的所有事情,并记住计算机必须满足的要求。你的工作是让计算机的任务变得尽可能简单。

如果您将模板存储在数据库中,那么另一个重要的性能损失将是缺少操作码重用和缓存。普通的Web托管环境编译一次PHP文件,然后将其字节码版本保留一段时间。这节省了后续的重新编译并大大加快了执行速度。但是如果将PHP模板代码填充到eval()语句中,则每次调用PHP时都必须重新编译此代码。

此外,如果您以这种方式使用eval()并允许用户编辑模板,则必须确保这些用户受信任 - 因为他们可以访问整个PHP环境。如果您正在使用其他路由并使用模板引擎,则可能会遇到更大的性能问题(但不会出现安全问题)。无论如何,请尽可能考虑缓存模板输出。

关于锁定机制:似乎你在这里引入了一个很大的架构问题,因为你现在必须让每个存储库(文件和数据库)理解哪些记录是对另一个的禁止。我建议你完全重新考虑这种方法,但是如果你必须这样做,我强烈建议你使用一个单独的列来标记记录(基于ID的东西听起来像是一场噩梦)。

标准方法是在数据库中保留经典的DB形状的东西(这些是用户帐户和其他非常适合表格的东西)并保持配置,所有代码和模板都在文件系统中。

答案 1 :(得分:1)

我认为在应用程序中保留一些硬编码的固定值可能是处理问题的好方法。在大多数情况下,它甚至会减少数据库服务器上的负载,因为有些并非所有值都必须通过SQL检索。

但有些情况可能会导致性能问题,主要是因为您必须使用硬编码值连接来自数据库的值。在这种情况下,将所有值存储在数据库中可能会有更好的性能,因为所有值都可以由数据库服务器优化和处理,而不是从SQL查询中获取所有值并在代码中手动连接它们。

要处理这种情况,您可以将值存储在数据库中,但插入和更新必须仅由维护或升级例程处理。如果您对不允许修改数据有更大的顾虑,可以设置维护例程以检查数据库中的值是否与代码不时相同。在这种情况下,这个数据库表很像硬编码值的“缓存”。当您不需要将固定值与数据库值连接时,您仍然可以从代码中获取它们,从而避免不必要的SQL查询(因为您确定值是相同的)。

答案 2 :(得分:0)

通常,只要您要执行数据库查询,如果要将硬编码的内容包含在工作流中,就不需要进行任何连接。您只需对硬编码数据的操作以及从数据库中提取的数据即可。如果我们谈论在应用程序中形成的对象中的信息,则尤其如此。例如,如果您希望应用程序中始终存在开发用户,我可以看到这很有用。您可以在应用程序中对此用户进行硬编码,无论何时查询数据库(例如登录用户时),都会在查询数据库之前检查硬编码用户的值。

例如:

// You would place this on the login page
$DevUser = new User(info);
$_SESSION['DevUser'] = $DevUser;

// This would go in the user authentication logic
if($_SESSION['DevUser']->GetValue(Username) == $GivenUName && $_SESSION['DevUser']->GetValue(PassHash) == $GivenPassHash)
{
    // log in user
}
else
{
    // query for user that matches given username and password hash
}

这表明不需要进行任何特殊或棘手的数据库工作。当您没有考虑它时,包含在数据库驱动的工作流程中的硬编码变量非常简单。

可能存在大量硬编码变量/对象和/或您可能希望在两组信息上执行大块逻辑的情况。在这种情况下,拥有一个包含硬编码信息的数组可能是有益的,然后您可以在执行任何逻辑之前将查询的信息添加到该数组。

对于支付处理器,我会假设您指的是使用PayPal,信用卡或其他服务等不同服务的在线支付。这将作为支付类最有意义,该支付类具有针对每种支付方法的单独功能。这样你就可以调用客户选择的任何方法。我想不出你想要处理的任何其他方式。如果您可能正在谈论客户可用的付款方式,那么这将是您的付款页面上的硬编码。

希望这会有所帮助。请记住,不要让它变得比它需要的更复杂。