table을 어떻게 설계했냐에 따라 다르겠죠..?

이력테이블 보관주기에 따라 delete가능하겠지만

update를 허용하면 이력테이블의 의미는 없을겁니다.

발생되는 데이터는 내역, 변경되는 데이터는 이력입니다.
하지만 이 기준은 이미 이력인지? 내역인지가 정해진 상태에서의 구별 기준이 아닐까? 생각합니다.
특정 대상을 이력으로 관리할지? 내역으로 관리할지를 정하는 과정에서는 이 기준은 큰 도움이 안되는듯 합니다.
예를 들어 사원의 부서 변경에 대해
단순히 부서가 변경되었다고 볼 수도 있지만, 부서 변경이라는 이벤트가 발생했다라고 생각할 수도 있겟지요.
 - "부서변경이력" 으로 관리할지
 - "이동발령내역" 으로 관리할지는
업무 요건에 따라 선택하셔야 할 경우가 많습니다.
아래 참조 링크를 보시면 똑같은 보안카드 변경에 대한 사항을 3가지 모델(내역, 이력, 내역+이력)로 다르게 구현한 예가 있습니다.
http://wiki.gurubee.net/pages/viewpage.action?pageId=28116559

이미 발생한 데이터는 수정이 안되는 것이 원칙이지만
잘못 발생된 데이터를 정정해야 하는 경우가 있을 것입니다.
내역이라면 어플리케이션 화면단에서 사용자가 직접 수정이 가능하지만
이력은 내역이 수정되면서 자동으로 쌓이는 개념이라 화면에서의 수정은 불가능하죠.
관리자가 따로 직접 SQL 명령어로 수정해 줘야 합니다.