|Problems? Is your data what you think it is?|
[OT] When coders don't see eye to eyeby Anonymous Monk
|on Oct 28, 2006 at 05:14 UTC||Need Help??|
Anonymous Monk has asked for the
wisdom of the Perl Monks concerning the following question:
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_tbl
post_id author_id message deleted_flag
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 :)