【问题标题】:Django code or MySQL triggersDjango 代码或 MySQL 触发器
【发布时间】:2010-10-31 00:27:57
【问题描述】:

我正在使用使用 MySQL 数据库的 Django 创建一个 Web 服务。客户端通过 URL 与我们的数据库交互,由 Django 处理。现在,我正在尝试创建一种行为,该行为可以在修改某个表时自动进行一些检查/记录,这自然意味着 MySQL 触发器。但是,我也可以在 Django 中执行表修改的请求处理程序中执行此操作。我认为 Django 还没有触发器支持,所以我不确定哪个更好,通过 Django 代码或 MySQL 触发器。

任何了解这些选项的性能的人都想了解一下吗?提前致谢!

【问题讨论】:

    标签: mysql django triggers


    【解决方案1】:

    有很多方法可以解决您描述的问题:

    • 应用逻辑
      • 特定于视图的逻辑 -- 如果行为特定于单个视图,则将更改放入视图中。
      • 特定于模型的逻辑 -- 如果行为特定于单个模型,则 override the save() method 用于该模型。
    • 中间件逻辑 -- 如果行为涉及多个模型或需要包裹现有应用程序,您可以使用 Django 的 pre-save/post-save signals 添加其他行为,而无需更改应用程序本身。
    • 数据库存储过程 -- 通常有可能,但 Django 的 ORM 不使用它们。不能跨数据库移植。
    • 数据库触发器 -- 不能从一个数据库移植到另一个数据库(甚至不能将一个数据库版本移植到另一个数据库),但允许您控制多个(可能是非 Django)应用程序之间的共享行为。李>

    就个人而言,我更喜欢使用覆盖 save() 方法或使用 Django 信号。使用特定于视图的逻辑可以让您在具有相同模型的多个视图的大型应用程序中脱颖而出。

    【讨论】:

    • 在我自己的应用程序中,我总是这样做,因为代码以易于理解的格式与模型一起结束。信号非常适合挂钩来自第三方/django 核心事件的事件。
    【解决方案2】:

    对我来说,您所描述的内容听起来像是“更改数据捕获”。

    我认为权衡可能是这样的:

    1. Django 优点:中间层代码可以被多个应用程序共享;如果数据库发生变化,可移植
    2. Django 缺点:逻辑上不是业务交易的一部分
    3. MySQL 专家:很自然地在数据库中进行操作
    4. MySQL 缺点:触发器非常特定于数据库;如果您更改供应商,则必须重写

    This 可能会有所帮助。

    【讨论】:

      猜你喜欢
      • 2018-08-05
      • 2015-06-15
      • 2020-04-04
      • 1970-01-01
      • 2021-07-02
      • 1970-01-01
      • 2017-06-23
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多