tags:

views:

171

answers:

2

I have a social networking site where users update their moods, profiles and add photos.

I'm currently logging all updates in a table called "update_log" with the following structure:

update_id int (auto), 
userid int, 
update_type int (1=profile, 2=photo, 3=mood)
pictureid int
mood_a int
mood_b int
mood_c int
update_time int

Profile update record: (auto), 1, 1, 0, 0, 0, 0, 1239003781

Photo update record: (auto), 1, 2, 11544, 0, 0, 0, 1239003781

Mood update record: (auto), 1, 3, 0, 1, 490, 70, 1239003781

For the photo record, there's a corresponding table userphotos which holds the caption and filename/location data

For moods, there is a mood lookup table that holds the mood descriptions (i.e., I'm lazy =\ )

What I need to do is query this data to show on a user's profile page, it will show this feed for any of their favorite users for the last x hours of activity.

The problem I'm running into is that if a user uploads five photos over the course of a half hour or something, I just want that to be one line in the feed, not an entry for each photo upload.

Same goes for profile updates.

I need to query the data so the user will see something like this:

user x updated their mood! (I'm tired) on Apr 4, 2009 10:35 pm
user y uploaded x new photos on April 4, 2009 10:20 pm
user x updated their profile on April 4, 2009 10:15 pm

How do I group the photo updates into one record returned in a query based on all records being within let's say an hour of each other?

Is there a way to do this with one query?

Thanks!

+2  A: 
Frank Crook
Yeah, I got that part it's grouping all photo uploads or profile updates within an hour of each other that's presenting some difficulty.
Tom
Hmmm, interesting. I'd really like to avoid anymore overhead i.e., adding a new table but it's worth thinking about. I was thinking more like a union query where the first is for profile, second photos and third mood. Where the 2nd would do some grouping and return the top update id in the ph grp
Tom
So which do you think is costlier? Group tables or just querying the data "raw" and parsing the results in PHP? I thought there must be some way to do it with a MySQL query i.e., a union query w/1 for profile upd, 1 for photos, 1 for moods but it sounds like you don't think that's possible
Tom
Parsing data in PHP is almost always costlier than storing data in a database. That said, I don't know enough about your table structure to make any union suggestions.
Frank Crook
If these types of updates are separate types (eg: you can update a mood without a photo), and one of those results can be null, then your photo record should contain the primary key of the update_log, not the other way around. This allows you to have several photos in a single update.
Frank Crook
As far as the union queries, they would all involve the same table, the update_log. 1st one would return profile updates within an hour of each other, 2nd would group photo updates, 3rd mood updates and yes, all updates are separate.
Tom
I guess my point of view is your code should either be very flexible, for development purposes, or very fast. The flexible option is going to be using PHP. The fast option is storing the data in the database. Such a complex union structure is not as fast as storage, nor as flexible as PHP.
Frank Crook
Well, I have to group profile updates along with photo updates so it looks like I'm going to have to do it in PHP which is going to be complex.
Tom
A: 

Have you considered trying to do this with PHP rather than SQL queries? It might be less complex to query the results you need (All updates between these times) and then use PHP to compare the timestamps in order to determine how they should be grouped.

Ryan Van Antwerp
I haven't thought about that yet. So you're saying get back everything within say, 24 hours, and parse the data in PHP by looping through the results? What would have more overhead, that or a MySQL query that does most of the work?
Tom
That's exactly what I mean; compare the timestamps and group accordingly. I'm no expert in overhead but I'd guess MySQL queries are faster. As stated in one of the comments above, parsing in PHP will probably be significantly easier at the expense of slower page loads (depending on amount of data)
Ryan Van Antwerp