fenway

What, exactly, the query you're worried about?

Why 12 columns of teams?

"SELECT e.event,e.time,e.img,e.vid,e.status,e.added, c.contact FROM $tab[contacts] AS c INNER JOIN $tab[events] AS e ON ( e.user = c.contact ) WHERE c.user='$id' ORDER BY e.time"

If SQL isn't in existence, then the $sql variable won't be useful for the query -- which is exactly what it's an ideal choice. You should name variables based on what they contain, not based on what they're used for.

That's PHP code -- not SQL queries -- I mean the actual statement that the server will execute.

@ebmigue: How so? That will do precisely what the OP requested -- find all products that have 2 matching attributes.

Just use all_games for now.

Across tables? I suppose you could use the information_schema to determine which tables contain a given field -- but why on earth would you want to do this?

TLDR -- what's the current problem?

That's php code, not a mysql query. Also, why not just use a JOIN?

The row sampling link I gave you is precisely what you're looking for....

Show us raw queries and error messages, not just the latter.

Since each project is functionally distinct, it makes logical sense to keep them distinct at the database level as well -- so 6 DBs. And as long as the mysql users have acccess to both DBs, and they're on the same machine, another connection is not a big deal. And like I said earlier, concerns about scaling are premature.

SELECT p.* FROM Products AS p CROSS JOIN ProdAts AS a1 CROSS JOIN ProdAts AS a2 WHERE ( a1.attribute = '23' AND a1.product = p.id ) AND ( a2.attribute = '45' AND a2.product = p.id )

Ah, I see -- you'll need to use a GROUP BY to find the set you want, and then join back. LIMIT 1 was an easy workaround that limits functionality.

I meant in terms of scalability... this need not concern you at this stage, you'll just get lost in subjective opinions -- every case is different. Go with InnoDB, and don't use separate databases if you want to share anything. If anything, you can store the users in their own table, and use project prefixes -- or, if you want, separate project DBs and a users DB.

Huh?

"select distinct email, date and group by email" really should be "select email, date and group by email, date". Don't use DISTINCT -- it's evil.

See here..

Yes, but we're talking about variable NAMES, not variable IDENTIFIERS -- so it's only beneficial to the human in question. And it matters even if you're not working on a team -- going back into 5-year-old code and trying to guess what a variable holds is all but impossible. A simple convention will save you hours.

@abamaca -- post your query.

Over 500? How did this random list of IDs get generated?

Try the CSV engine type.

Those sizes are screaming for another table.

Sorry, I don't follow.