Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: [OT] When coders don't see eye to eye

by dws (Chancellor)
on Oct 29, 2006 at 05:23 UTC ( #581129=note: print w/replies, xml ) Need Help??

in reply to [OT] When coders don't see eye to eye

If you were to add a use case that allowed for the removal of a "deleted" indication, Approach A would require that you read a tuple from the remove_tbl, delete that tuple, then use the data from the tuple to update the posts_tbl. Approach B requires a single delete.

If you were to decide on changing the wording of the "removed by" message, Approach A would require a moderate amount of work and data rewriting. Approach B requires a single change in code.

The Cons you list for Approach B are minor. Assuming the right index, the outer join to get a post and any remove data won't be an issue unless you're seriously high traffic.

I have trouble imagining circumstances where I'd even consider A as an option.

  • Comment on Re: [OT] When coders don't see eye to eye

Replies are listed 'Best First'.
Re^2: [OT] When coders don't see eye to eye
by Errto (Vicar) on Oct 30, 2006 at 04:16 UTC
    I have trouble imagining circumstances where I'd even consider A as an option.
    I agree in general approach B is better, but I think there are circumstances where it's not. In particular, for a more complex application where there are lots of places that touch this data, and you want the vast majority of them to ignore those marked as deleted, it might be easier to have the deleted entries not be in the main table at all (which I realize now is different from what the OP posted) but rather in a sort of duplicate table off to the side used only for administrative/reference purposes.
      Only if the majority of your posts will be deleted. Which I assume won't be the case. If you have lots of posts, and lots of code querying them, you want access to them as fast as possible. The access will be faster if the database can cache more. Databases cache by page. If a row is retrieved, the entire page the row will be in is fetch from disk, and kept in cache. The smaller your row, the more rows can fit in a database. The amount of pages that can be cached is limited by the environment. So, if you have more rows per page, then you have more cached rows for a given fixed number of pages that can be cached.

      In other words, approach A wastes memory. And that can hurt performance. (Of course, it may not. Unless you measure you won't know. And maybe the difference in performance is insignificant. And even if A has better performance, it has to make a huge difference before I choose such a dirty design - it's feels worse than running without strict and warnings).

      I wouldn't even have a 'deleted' column in the post_tbl table. This information can be deduced from the post having an entry in the removed_tbl table.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://581129]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (4)
As of 2017-05-28 03:34 GMT
Find Nodes?
    Voting Booth?