fenway

Echo the actual queries -- and make sure you actually have matching rows.

Depends if you want to show courses without any modules.

It is correct, if it's configured correctly.

What do folders have to do with mysql?

That's not an INTEGER field -- that's a DECIMAL field.

There is something strange with your collations -- not sure from where you're issuing that query. In general, though, it's preferable to stick to ASCII-based table names & column names.

Yeah, I hear you -- I have little patience for those who won't even attempt to help themselves, or better yet, won't heed your advice.

There is nothing "automatic" -- you map the fields to an existing table as you see fit.

Everything is possible -- LOAD DATA works well, assuming you have a real Excel file with known delimeters.

I don't see why you want to do that.

In the DB is a convenience, but if you're just on a single server, there are few benefits to not having them on the filesystem itself (outside the webroot, of course).

Keeping them in a single table prevents you from having multiple values for each "primary record" -- e.g. address, company, contact, etc.

Well, you have 3 subqueries -- which one is causing the error? Switch to COUNT(*) and you'll see.

You can use the "WITH ROLLUP" modifier to GROUP BY if you'd like.

What do you mean "they can all be null"? What can be null?

You don't need your PK to be "completely unique" -- just unique for each table. If you want e-mail addresses to be unique (but you don't), you can add a UNIQUE index -- that has nothing to do with the PK. Yes, defining a FK automatically creates an index, though personally, I prefer to do that explicitly, so that nothing "silent" happens. I'm sure I missed a few questions.

Sorry, I'm not following.

The only reason to have separate DBs is if your data have nothing to do with each other -- ever -- e.g. separate clients.

Well, you're missing a GROUP BY column -- based on something like invoice_number, perhaps? But then * is useless.

Maybe someone messed up a recent backup restoration?

Oh, it's far from preferable -- it's just cleaner than CASE when NULL is known.

Prove that your variable is making it to your script.

If you know that only one of the two columns will be not-NULL, you can use COALESCE().

Well, that depends on what kind of "updates" you're talking about.

Since it might be possible to leave a table "locked" inadvertently, it might be preferable to use a flag on the row to indicate it's "mid-update".