>Yes, my apps delete rows and with gusto and no, they are never logged!
>
>Guess what?
>
>There has never, ever, ever been a case where that produced an adverse business effect for the client and there have been hundreds, if not thousands of cases where the absence of that useless refuse has sped things up markedly.
>
>Might there have been a case?
>
>Yes, and I might have won the Masters, but neither has happened and, based on observations of reality, neither is likely to happen.

This is a bad practice, period. It's myopic and the expressed attitude here is full of hubris.

"Based on observations?" Have you ever dealt with incremental extracts in an ETL environment, where the source system decided to delete rows? Ever stop to consider that little world you and your client live in, might get bigger some day when they either buy someone (or get bought, or get sold, etc.), and have a whole new data enterprise?

Difference between a professional and "all others" - adhering to good practices even when it doesn't seem like there's any reason. You shouldn't delete rows in an OLTP/production system. Period.

Bad practices account for tons of lost hours. I just recently learned that a DBA was changing rows manually without any update triggers to update the timestamp. Cost my team several hours. I've seen that one about five times in the last 10 years. Five times too many.

Marking rows for deletion (or logging them) should not slow things down "markedly". If it does, there are bigger problems.

In certain industries (health care being one), deleting is not only a "four letter word", it's also possibly against regulations.

My entire point for jumping in - was using the Socratic method. People were talking about pressures to do things against the law - there's a more subtle side to that. Hate to paraphrase Richard Nixon, but I'm going to - on the question of deleting rows..."You could do it - but it would be wrong"