Django 代码或 MySQL 触发器

发布于 2024-09-30 03:11:45 字数 258 浏览 2 评论 0原文

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

任何了解这些选项性能的人都愿意透露一些信息吗?提前致谢!

I'm making a web service with Django that uses MySQL database. Clients interface with our database through URLs, handled by Django. Right now I'm trying to create a behavior that automatically does some checking/logging whenever a certain table is modified, which naturally means MySQL triggers. However I can also do this in Django, in the request handler that does the table modification. I don't think Django has trigger support yet, so I'm not sure which is better, doing through Django code or MySQL trigger.

Anybody with knowledge on the performance of these options care to shed some light? Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

羁客 2024-10-07 03:11:45

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

  • 应用程序逻辑
    • 特定于视图的逻辑 -- 如果行为特定于单个视图,则将更改放入视图中。
    • 特定于模型的逻辑 - 如果行为特定于单个模型,则覆盖模型的 save() 方法
  • 中间件逻辑 - 如果行为涉及多个模型或需要包装现有应用程序,您可以使用 Django 的 保存前/保存后信号,以在不更改应用程序本身的情况下添加其他行为。
  • 数据库存储过程——通常是可能的,但 Django 的 ORM 不使用它们。不可跨数据库移植。
  • 数据库触发器——不能从一个数据库移植到另一个数据库(甚至不能从一个数据库版本移植到下一个数据库版本),但允许您控制多个(可能是非 Django)应用程序之间的共享行为。

就我个人而言,我更喜欢使用重写 save() 方法或使用 Django 信号。使用特定于视图的逻辑可能会让您在具有同一模型的多个视图的大型应用程序中陷入困境。

There are a lot of ways to solve the problem you've described:

  • Application Logic
    • View-specific logic -- If the behavior is specific to a single view, then put the changes in the view.
    • Model-specific logic -- If the behavior is specific to a single model, then override the save() method for the model.
  • Middleware Logic -- If the behavior relates to multiple models OR needs to wrapped around an existing application, you can use Django's pre-save/post-save signals to add additional behaviors without changing the application itself.
  • Database Stored Procedures -- Normally a possibility, but Django's ORM doesn't use them. Not portable across databases.
  • Database Triggers -- Not portable from one database to another (or even one version of a database to the next), but allow you to control shared behavior across multiple (possibly non-Django) applications.

Personally, I prefer using either overriding the save() method, or using a Django signal. Using view-specific logic can catch you out on large applications with multiple views of the same model(s).

下雨或天晴 2024-10-07 03:11:45

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

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

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

可能会有所帮助。

What you're describing sounds like "change data capture" to me.

I think the trade-offs might go like this:

  1. Django pros: Middle tier code can be shared by multiple apps; portable if database changes
  2. Django cons: Logically not part of the business transaction
  3. MySQL pros: Natural to do it in a database
  4. MySQL cons: Triggers are very database-specific; if you change vendors you have to rewrite

This might be helpful.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文