fenway

Actually, the idea is to "start", as you call it, with the table that has records that will always be there, and then left join the tables that may not have matching rows. In your case, you should start with cinemas, then simply left join to the many-to-many table with an ON clause that covers the FK and the user_uid in question. If there is no matching row, it's unassigned -- and it's quite easy to order by that.

It looked an awful lot like a duplicate of this topic -- obviously, I forgot to send a "duplicate post" warning. Correct me if I'm wrong.

Sounds like a syntax error... hard to say.

FIND_IN_SET() will work too under limited circumstances.

Like this: SELECT * FROM `users_cinemas` LEFT JOIN `users`ON`users`.`id`=`users_cinemas`.`user_id` LEFT JOIN `cinemas`ON `cinemas`.`id`=`users_cinemas`.`cinema_id`

Well, technically this belongs in the php forum, but if you've ordered the result set correctly, they will already be in the desired order. All you'll need to do is "notice" when the section changes. I can move this topic to the php board if you'd prefer.

I disagree -- why not a simple join?

You get to decide how mysql interprets out-of-date values based on sql_mode -- if it's strict, it will barf.

OK -- well, if that join returns the expected result, you're just left with application code to adjust the layout per "section".

"Focusing light" is not a current scientific theory -- it's not going anywhere. And yes, while polishing a mirror to 1 angstrom is a "technical limitation", it's almost not going anywhere. Like I said, it's a practical hard limit, not a theoretical one.

You're written a query with an error -- find it.

The problem with that is two-fold -- first, if you list is long, it can get truncated without your knowledge; second, if you ever want other fields back, you're screwed.

Still no good -- you'll need a left join.

Can you post the join you've written, and we can take it from there/

the better way is to join the tables properly in mysql, and then have the application code sort out the rest.

Well, that way you'll never get unassigned ones.

That if statement belongs in your application code, not the database -- "all values" means no where clause.

Given sufficient magnification you would be able to see anything regardless of size. Just because a piece of technology doesn't exist doesn't mean it cannot exist. Yes, of course, and I wasn't stating otherwise. I was just saying that at current we don't posses the the technology. Actually, there is a practical hard limit -- magnification requires a lens to bring the image into focus, and that lens has to be smooth, or the resulting image will be fuzzy. And you can't polish a lens to be infinitely smooth -- in fact, it's pratically impossible to focus x-rays at all, which have a wavelength on the order of magnitude of atomic resolution. In my other life, I did years of graduate training to work around this exact problem -- it's a royal pain in the butt.

What's "everything"? Why manually?

Solved? How?

That's quite the hack -- I wouldn't be happy with that in my code. Simply don't pass the date if it's not a date.

Echo the actual queries.

And you're certain that the old DB was working correctly before?

Besides, you decide what to do with the variables passed by the form.

select q.*, a.* from questions as q left join answers as a on (a.answer_questionID = q.question_id)