fenway

Dare I ask why you're letting users create copies of a database?

That's as easy and adding/remove the appropriate rows from the lookup table. That's easier to handle if your application.

In general, the storage engines of MySQL are designed for just that -- storage -- and anything even remotely useful requires black magic.

Why not simple include count(b) as an aliased expression?

It really depends on how many levels deep you're storing, how large the table is going to be, and how often it's going to be changed, and it what ways.

Ultimately, the most robust way is to effectively duplicate the row with every change -- how you decide to manage the duplication is up to you. Of course, as I mentioned earlier, maintaining a relational DB with versioning is a very Hard problem, and working around it requires a variety of assumptions and limitations, based on your particular scenario

Adding what?

Yes, that's the proper procedure.

SELECT game_datetime, home_team_temp, visiting_team_temp , CONCAT(h.mascot, ' ', h.city) AS home_team, hl.logo_url AS home_logo_url , CONCAT(v.mascot, ' ', v.city) AS visiting_team, vl.logo_url AS visiting_logo_url FROM schedules INNER JOIN teams AS h ON ( h.id = schedules.home_team_id ) INNER JOIN logos AS hl ON ( hl.id = schedules.home_team_id ) INNER JOIN teams AS v ( h.id = schedules.visiting_team_id ) INNER JOIN logos AS hl ON ( hl.id = schedules.visiting_team_id )

Not literally dump -- var_dump() the output.

Do you have the front-end? the back-end? is something broken? is this a design question?

In the general case, these simple implementations are nowhere near sufficient -- this assumes that nothing every references the blog table.

This is a full-text search request -- not great for joins, and not great in general.

No, you can't do that -- dare I ask why you want to?

You need to use the former query as a sub-query of the latter.

I am so very confused -- why not simply join the team table twice, one for home, once for away/

Dump $get_info, see what happens.

I don't understand which side of the script you're asking for help with.

This topic has been moved to PHP Coding Help. http://www.phpfreaks.com/forums/index.php?topic=315853.0

You're talking about a proper full-text search, then?

That's wonderful -- how about posting your solution, too?

You can cheat temporarily with STR_TO_DATE(), but that's a hack.

I see NO possible_keys.

Not sure that a year table is appropriate at all. But the "value" of your interface fields should be the yID.

Dare I ask why published becomes unpublished? Theoretically, this can be achieved with an UPDATE trigger -- but I don't think you can update the same table/record yet.