在 Delphi 中,我应该在循环内使用多个数据库插入还是使用存储过程?

发布于 2024-12-03 01:55:32 字数 183 浏览 2 评论 0原文

我正在寻找处理这种情况的最佳方法。我想在数据库表中存储摊销计划。每行包含日期、当前余额、付款、本金、利息和新余额。对于典型的 30 年期抵押贷款,这将是 360 行或数据库插入。

我应该使用 Delphi 在循环内进行计算并为每个结果进行插入,还是应该在存储过程内执行这些计算?

这将是单用户、本地计算机、桌面应用程序。

I'm looking for the best way to handle this situation. I want to store an amortization schedule inside a databse table. Each row contains the date, current balance, payment, pricipal, interest, and new balance. For a typical 30 year mortgage this would be 360 rows or database inserts.

Should I do the calculations inside a loop using Delphi and do an insert for each result or should I perform these calculations inside a stored procedure?

This would be a single user, local machine, desktop application.

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

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

发布评论

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

评论(4

花辞树 2024-12-10 01:55:33

准备好的查询和存储过程在性能方面具有可比性。作为一名应用程序开发人员,我非常讨厌存储过程,因为它们将逻辑从应用程序内部(我可以找到它)移动到在查看源代码时不可见的其他地方。让我们面对现实吧,如果应用程序有效,没有人会用不同的语言重新开发它。

因此,如果您喜欢数据库和 SQL 并且对此感到满意,那么存储过程就可以了。但是,如果您主要是应用程序开发人员,我看不出使用存储过程比从代码执行查询有任何好处。

Prepared queries and stored procedures are comparable performance-wise. As an application developer I detest stored procedures with a passion because they move logic from inside the application, where I can find it, to somewhere else not visible when looking through the source code. And let's face it, nobody is going to redevelop an application in a different language if it works.

So, if your thing is databases and SQL and you are comfortable with that, then stored procedures are fine. However, if you are primarily an application developer, I cannot see any benefit of using stored procedures over having the queries executed from code.

浅语花开 2024-12-10 01:55:33

我会在存储过程中执行操作。这样,就可以在数据所属的数据库中处理数据。

此外,通过将所有与数据相关的操作保留在数据库中,如果将来您选择切换语言,您可以省去再次编码的麻烦。

I would do the operations in the stored procedure. That way working with data is in the database where it belongs.

Also, by keeping all data related operations in the database you save yourself the hassle of coding it again if sometime in the future you choose to switch language.

芸娘子的小脾气 2024-12-10 01:55:33

如果您碰巧使用 AnyDAC,它支持所有支持的数据库的 ArrayDML。我认为这是一个很棒的功能。这是商业软件,但却是一项非常好的投资。 (我与他们没有任何关系,除了作为一个非常满意的客户。)

请参阅 使用数组 DML 实现非常高性能

If you happen to use AnyDAC, it supports ArrayDML for all their supported databases. I think this is one nifty feature. This is commercial software, but a very good investment. (I'm not associated to them in any way, except as a very satisfied customer.)

See Very High Performance using the Array DML

迟月 2024-12-10 01:55:33

如果您的数据库是本地的,并且您不打算有一天将其变成客户端/服务器,那么从性能角度来看可能没有什么区别。很大程度上取决于您使用的数据库。
有些具有“数组 DML”,它允许您在一次数据库往返中执行所有 360 次插入,基本上,您可以填充数组绑定变量并执行单个插入,而不是执行 360 次插入。无论如何,最糟糕的方法是使用不带绑定变量的 n 插入。
如果数据库不编译它(有些可能只使用 P 代码),则编译和优化的 Delphi 代码可能比解释的存储过程代码更快。
从设计的角度来看,将数据逻辑放入数据库中,通过存储过程发布某种API(可能禁止其他方式修改数据)可以确保对数据有更强的控制。

If your database is local and you don't plant to make it client/server one day there could be little difference from a performance perspective. Much depends on what database you use.
Some have "array DML" which would allow you to perform all the 360 inserts in one database round-trip, basically instead of doing 360 inserts you fill array bind variables and perform a single insert. The worst way would anyway be using n inserts without bind variables.
Compiled and optimized Delphi code may be somewhat faster than a interpreted stored procedure code, if the database doesn't compile it (some may just use P-Code).
From a design perspective, putting the data logic inside the DB publishing a sort of API via stored procedures (may forbidding other ways to modify data) may ensure a stronger control over data.

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