SELECT *, (SELECT SUM(Amount) FROM 2_1_journal)
FROM 2_1_journal
WHERE TransactionPartnerName = ?
Amount
这会从整个表中选择总和并“附加”所有行,其中TransactionPartnerName
是您在客户端代码中绑定的参数。
如果您想将总和限制为与您选择的行相同的条件,只需包含它:
SELECT *, (SELECT SUM(Amount) FROM 2_1_journal WHERE TransactionPartnerName = ?)
FROM 2_1_journal
WHERE TransactionPartnerName = ?
完全不同的事情:像这样的表名2_1_journal
是数据库设计损坏的有力指标。如果可以重做,则应研究如何正确规范化数据库。它很可能会多次偿还。
关于标准化(稍后添加):
由于当前设计在表名中使用键(例如 the2
和1
in 2_1_journal
),我将快速说明我认为您可以如何极大地改进该设计。假设该表2_1_journal
具有以下数据(我只是在这里猜测,因为尚未在任何地方描述这些表):
title | posted | content
------+------------+-----------------
Yes! | 2013-01-01 | This is just a test
2nd | 2013-01-02 | Another test
这东西属于2
公司用户1
。但是,嘿!如果您查看这些行,则找不到该数据属于2
公司用户的事实。1
问题是这种设计违反了数据库设计的最基本原则之一:不要在对象(这里:表)名称中使用键。一个非常错误的明确迹象是,如果添加了新表,则必须创建新表。在这种情况下,添加新用户或新公司需要添加新表。
这个问题很容易解决。创建一个名为journal
. 接下来,使用相同的列,但添加另外两个:
company | user | title | posted | content
--------+------+-------+------------+-----------------
1 | 2 | Yes! | 2013-01-01 | This is just a test
1 | 2 | 2nd | 2013-01-02 | Another test
这样做意味着:
- 除非应用程序发生更改,否则您永远不会添加或修改表。
- 跨公司或用户进行连接(以及以前属于表命名方案的任何其他内容,现在都可以通过一个相当简单的 select 语句来实现)。
- 执行完整性很容易 - 如果您升级应用程序并想要更改表,则不必为每个公司和用户重复更改。更重要的是,这降低了应用程序与数据库中的表不同步的风险(例如将字段添加
comments
到所有x_y_journal
表中,但忘记了仅在用户登录时5313_4324_journal
导致应用程序中断。这是一种问题你不想处理。5313
我不写这个,因为这是个人品味的问题。数据库只是为了处理我上面描述的布局的表而设计的。将对象键用作表名的一部分的设计有许多与之相关的其他问题,这些问题非常难以处理。