Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to implement functionality which let user share posts by other users similar to what Facebook and Google+ share button and twitter retweet.

There are 2 choices:

1) I create duplicate copy of the post and have a column which keeps track of the original post id and makes clear this is a shared post.

2) I have a separate table shared post where I save the post id which is a foreign key to post id in post table.

Talking in terms of programming basically I keep pointer to the original post in a separate table and when need to get post posted by user and also shared ones I do a left join on post and shared post table

    Post(post_id(PK), post_content, posted_by)

    SharedPost(post_id(FK to Post.post_id), sharing_user, sharedfrom(in case someone shares from non owners profile))

I am in favour of second choice but wanted to know the advice of experts out there?

One thing more posts on my webapp will be more on the lines of facebook size not tweet size.

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

It's the classic "link vs copy".

I reccomend making a duplicate copy. Although "duplicate" may not be the correct term since you are sharing a snap shot of time. It's "unique" with regard to that context.

For example if you have a history table you want to store copies of the data, not foriegn keys. With a history you are not interested in the latest values. You want the values from that moment in time. It would be incorrect to use a FK.

If a poster deletes their post, then your shared link is broken. Minus 1 to links.

What if the poster edits their post to something offensive after you share it? That would make the sharing user look bad. Minus 1 to links.

Performance. The copy is wasteful on disk space. However it does get rid of the need to maintain an index on a foreign key. It may not sound like much, but on an extremely large database that is a huge deal. With any face book caliber dataset you are going to have to break with tradition a bit to make things fast. Minus 1 to links.

What does this mean for your post sharing? It depends on what you want. Are you by design sharing a "link" or a "copy"? There are advantages and drawbacks to both designs. I'll let others talk about the pros of links.

EDIT: Please don't let my post shy you away from links. For the goals of your application, they may be what you need. The web has gotten by with links pretty well so far.

share|improve this answer
    
+1 good points. I guess it really depends on the requirements. –  CFL_Jeff Mar 26 '12 at 20:04
1  
@mike You confirmed my fears. Linking complicates query a lot.In fact I can get benefits of linking by duplicating too.If I put a column shared_post_id and create a cascade delete foreign key to original post id then deleting original post deletes shared too if I want. –  codecool Mar 27 '12 at 13:34
    
"What if the poster edits their post to something offensive after you share it? That would make the sharing user look bad" - I dont think anybody would provide a feature to change the content after you post it, and thats what facebook do, you cant change your status post after you post it....or if you post a pic, you cant edit the image and add some other image to the same post...I would recommend using linking..and I agree @codecool in case of deletion of a post –  vikas devde Mar 25 '13 at 13:54
add comment

Your intuition is correct, definitely use option 2. There is no reason to duplicate the entire post in the database each time someone shares it. Just have a separate SharedPosts table which simply maps userIDs to other users' posts, like you say.

EDIT

The above answer assumes that a post cannot be changed after the original user shared it. If it can be changed by the OP, then the users who shared it may not wish to share the updated version, so you can:

  1. delete all shares of a post if the original post gets updated, OR
  2. store each shared post as duplicates of the original, like you mentioned in your option 1

Mike's answer does a great job of explaining the benefits of storing duplicates.

share|improve this answer
    
What if the original poster deletes it's post? The shared post should die too? –  George Mar 26 '12 at 17:31
    
What if the poster edits their post to something offensive after you share it? That would make the sharing user look bad. –  mike30 Mar 26 '12 at 18:56
    
We r fine with the idea of original post getting deleted. But mike's point is valid one. @mike So what do you recommend? –  codecool Mar 26 '12 at 19:03
    
@codecool I'll reply in an answer. It's too cramped in the comment space. –  mike30 Mar 26 '12 at 19:08
add comment

I would just duplicate the original posting. This will simplify your domain layer when dealing with deletions, duplications (from another duplication) and etc.

If you duplicate the posting, marking it as a duped one (simple flag), you gain the delete, share, etc, for free, instead of creating complicated logic behind duplications.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.