I have to combine these two mySQL queries into one. I duplicated a solution and used it on a join table. I am querying a join table that has two columns (labeled “to_” and “from_”). Both ‘to_’ and ‘from_’ hold an id number for the same table. I need to combine these queries in such a way that I get results based on: [(‘from_’ + ‘to_’) > 3], where ‘from_’ and ‘to_’ have the same value (i.e., they refer to the same id).
$query = "select * from nodes where nodeID in (
select to_ from joinTable group by to_ having count(*) > 3
)";
...
$query = "select * from nodes where nodeID in (
select from_ from joinTable group by from_ having count(*) > 3
)";
Acknowledgement: I’m using a query based very closely on a solution ‘Mr E’ helped me with earlier.
You can try (see important notice at the last paragraph regarding to_ and from_ matching requirements):
Or
Using Mr E‘s test data:
It will work, half-way, by issuing:
which will then yield:
and by running in full:
Basically, join the table with itself and then generate an N:N list of matching records from both tables where to_ and from_ match (whether or not on the same row), then work with a single column and aggregate its values for the final COUNT(*).
And, most importantly, why have I lowered the number on the HAVING COUNT(*) from 3 to 2? The N:N relationship will issue N1 * N2 records (where N1 is the count of matching records on the first table and N2 on the second). So if the lower bound is three, we can only have over 3 records on these two tables by having one record in one of them and then 3 on the other (in whatever order) or 2 in one and 2 on the other (and then up from there) – otherwise there will be no matches on the to_ and from_ fields and this is something I am not sure about – whether the OP wants only records whose values appear on both fields or if having a COUNT(*) from a single side would suffice. If the latter is the case, however, I don’t see any other option apart from separating the queries to deal with each column individually, as some people already have posted since that’s an isolated sum we’re dealing with. This will be slow if running against large tables.