MySQL SELECT SUM(Column) and SELECT * Cardinality violation: 1241 Operand should contain 1 column(s)

Question

Trying to write statement where in single statement select all ( * ) and sum one column from the same database and the same table, depending on conditions.

Wrote such statement (based on this Multiple select statements in Single query )

SELECT ( SELECT SUM(Amount) FROM 2_1_journal), ( SELECT * FROM 2_1_journal WHERE TransactionPartnerName = ? )

I understand that SELECT SUM(Amount) FROM 2_1_journal will sum all values in column Amount (not based on codition).

But at first want to understand what is correct statement

With above statement get error SQLSTATE[21000]: Cardinality violation: 1241 Operand should contain 1 column(s)

Can not understand error message. From advice here MySQL - Operand should contain 1 column(s) understand that subquery SELECT * FROM 2_1_journal WHERE TransactionPartnerName = ? must select only one column?

Tried to change statement to this SELECT ( SELECT * FROM 2_1_journal WHERE TransactionPartnerName = ? ), ( SELECT SUM(Amount) FROM 2_1_journal) , but get the same error...

What would be correct statement?

Answer 1

SELECT *, (SELECT SUM(Amount) FROM 2_1_journal)
  FROM 2_1_journal
 WHERE TransactionPartnerName = ?

This selects sums up Amount from the entire table and "appends" all rows where TransactionPartnerName is the parameter you bind in the client code.

If you want to limit the sum to the same criteria as the rows you select, just include it:

SELECT *, (SELECT SUM(Amount) FROM 2_1_journal WHERE TransactionPartnerName = ?)
  FROM 2_1_journal
 WHERE TransactionPartnerName = ?

A whole different thing: table names like 2_1_journal are strong indicators of a broken database design. If you can redo it, you should look into how to normalize the database properly. It is most likely pay back many times over.

With regard to normalization (added later):

Since the current design uses keys in table names (such as the 2 and 1 in 2_1_journal ), I'll quickly illustrate how I think you can vastly improve that design. Lets say that the table 2_1_journal has the following data (I'm just guessing here because the tables haven't been described anywhere yet):

title | posted     | content
------+------------+-----------------
Yes!  | 2013-01-01 | This is just a test
2nd   | 2013-01-02 | Another test

This stuff belongs to user 2 in company 1 . But hey! If you look at the rows, the fact that this data belongs to user 2 in company 1 is nowhere to be found.

The problem is that this design violates one of the most basic principles of database design: don't use keys in object (here: table) names. A clear indication that something is very wrong is if you have to create new tables if something new is added. In this case, adding a new user or a new company requires adding new tables.

This issue is easilly fixed. Create one table named journal . Next, use the same columns, but add another two:

company | user | title | posted     | content
--------+------+-------+------------+-----------------
      1 |    2 | Yes!  | 2013-01-01 | This is just a test
      1 |    2 | 2nd   | 2013-01-02 | Another test

Doing it like this means:

• You never add or modify tables unless the application changes.
• Doing joins across companies or users (and anything else that used to be part of the table naming scheme is now possible with a single, fairly simple select statement).
• Enforcing integrity is easy - if you upgrade the application and want to change the tables, the changes doesn't have to be repeated for each company and user. More importantly, this lowers the risk of having the application get out of sync with the tables in the database (such as adding the field comments to all x_y_journal tables, but forgetting 5313_4324_journal causing the application to break only when user 5313 logs in. This is the kind of problem you don't want to deal with.

I am not writing this because it is a matter of personal taste. Databases are just designed to handle tables that are laid out as I describe above. The design where you use object keys as part of table names has a host of other problems associated with it that are very hard to deal with.