go ahead... be a heretic | |
PerlMonks |
[OT] When coders don't see eye to eyeby Anonymous Monk |
on Oct 28, 2006 at 05:14 UTC ( [id://581058]=perlquestion: print w/replies, xml ) | Need Help?? |
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question: Dear monks, I'm currently involved in a web project with a friend. It's the first time I'm jointly coding a website with another person. We sometimes have quite different approaches to the same problem, and we fail to see eye to eye. Here's is one and I hope to seek your advice and opinions. We are divided over the how to treat the "removal" of a post from a forum. The questionable post will still be somewhere in database, but we need a way to indicate that action was taken against it. To make things concrete, we've two MySQL tables (simplified) as follows: posts_tblpost_id author_id message deleted_flag removed_tbl post_id message deleted_by_id date Let's say we have too approaches A and B. When a message that is deemed inappropriate is removed via a button click, Approach A goes likes this: In posts_tbl, the "message" field is updated with the replacement text "Removed by USERNAME" and the "deleted_flag" column with a value of 1 (the default is 0) (Note: the username is available at the point of update, so it's updated into the message filed as part of the replacement text). In removed_tbl, the original message is inserted into the message field, together with the post_id, the date, the member id of the person carrying out the deletion. Approach A's points are: a) When displaying posts in a web page, all posts can be directly retrieved from posts_tbl, including messages that contain "Removed by USERNAME".b) Saving of processing time because there's no need for additional code to check whether a message was removed. c) Greater flexibility because different pieces of data are stored in two different tables. d) Greater expandability. When a different reason for removing the post is needed, a new column can be added to removed_tbl to store that reason. The sql to retrieve messages from posts_tbl will be straightforward without having to link to removed_tbl to retrieve the username of the person who deleted the post (assuming the other information in removed_tbl is not needed for display). The code will be simpler too. Approach B is: removed_tbl should be changed to:post_id deleted_by_id date When a removal is carried out: In posts_tbl, the "message" field remains unchanged while the "deleted_flag" column is updated with a value of 1. In removed_tbl, the necessary information is inserted (post_id, member id of the person deleting the message, date) Approach's B points are: a) The original message should not be touched in posts_tbl.b) There's duplication of data if the message field of posts_tbl is updated with the string "Removed by ...". c) There's also duplication of data because "Removed by ..." and "deleted_flag" both indicate the particular post has been removed. d) The string "Removed by ..." should be added in the code for outputting to a webpage, so that it doesn't get stored anywhere. When a different wording is needed e.g. changing "Removed by ..." to "Deleted by ...", only that the hard-coded string needs to be changed. e) posts_tbl stores all original posts, so it's easier for retrieval. Cons of Approach B: a) The sql to retrieve messages will require an additional condition to link posts_tbl to removed_tbl to retrieve the username of whoever deleted the post.b) The code will need to check for whether a post has been removed so it can output the string "Removed by ...". There are other ways for sure. But between the two outlined above, which is a better solution? It's a bit longish but I need to paint as accurate a picture as possible. Would appreciate your enlightment :) Thank you and I look foward to hearing from you :)
Back to
Seekers of Perl Wisdom
|
|