Friend Requests II: Who Has the Most Friends

For a requests table with requester_id and accepter_id, create one participant stream containing requester IDs and another containing accepter IDs, combine them with UNION ALL, then group by id and count rows. UNION ALL is important: a person appearing in separate request roles should contribute twice as appropriate, while UNION could accidentally remove duplicates. Select the id or ids with the greatest count; clarify tie behavior and whether self-requests or duplicate request rows are possible. If the table represents accepted friendships rather than directed requests, the same normalization counts each endpoint once per edge. In SQL terms, the work is dominated by scanning and grouping N request rows, generally O(N) expected with hash aggregation or O(N log N) with sort aggregation, and memory depends on distinct users. Test users appearing only as requester, only as accepter, equal leaders, and an empty table. Do not join the table to itself, which multiplies combinations without need.