또는 다른 말로 표현하면, 모든 모델에서 사용하지 않을 이유가 있습니까?is_paranoid를 레일즈에 내장해야합니까?
일부 배경 : is_paranoid이 행을 삭제하기보다는 deleted_at 타임 스탬프를 설정 destroy에 호출을 (그리고 find이 deleted_at null 이외의에 행을 제외 호출) 보석이다.
이 기능이 매우 유용하여 모든 모델에 포함되기 시작했습니다. 하드 삭제 기록은 너무 무서운 것입니다. 이것이 나쁜 이유가 있습니까? Rails에서이 기능을 기본적으로 사용하도록 설정해야합니까?
루비는 자신의 코드를 두려워하는 겁쟁이가 아닙니다!
대부분의 경우 정말로 레코드를 완전히 삭제하고 싶습니다. 다른 두 모델 간의 관계를 포함하는 테이블을 고려하십시오. deleted_at을 사용하고 싶지 않은 경우에는 분명한 경우입니다.
또 다른 한 가지는 데이터베이스 디자인에 대한 접근 방식이 다소 루비 (rubyish)라는 것입니다. 이 deleted_At 항목을 모두 처리해야하는 번거 로움 때문에 테이블에 복잡한 검색어를 쓸 때만 finds 이상이어야합니다. 그리고 애플리케이션의 DB가 많은 공간을 차지할 때 멋지고 반짝이는 루비 코드를 해킹 된 SQL 쿼리로 대체해야합니다. 이 열을 버리면 좋겠지 만 이미 deleted_at 로직을 사용하고 있으므로 앱의 더 큰 부분을 다시 작성해야합니다. 잡았다.
마지막으로 사실 삭제가 사라지면 자연 스럽습니다. 그리고 모델링의 요점은 모델이 기계가 읽을 수있는 용어로 표현하려고 시도한다는 것입니다. 기본적으로 레코드를 삭제하면 영구히 전달됩니다. 그리고 이유는 deleted_at이 자연스러운 것일 수 있습니다. 나중에 레코드를 복원하거나 유사한 레코드가 원래 레코드와 혼동되지 않도록해야합니다 (사용자 테이블은 사용하려는 장소 일 가능성이 큽니다). 그러나 대부분의 모델에서는 단지 편집증 일뿐입니다.
내가 말할려고하는 것은 사람들이 일반적으로 기대하는 게 아니에요과 경우가 있기 때문에 그것의 암시 적 사용 오류 경향이 아니라 어디 때문에 삭제 기록을 복원 할 수있는 타당성이 명시 적으로 표현 의도해야한다는 것입니다 (created_at 컬럼을 유지하는 것과는 달리) 작은 오버 헤드를 추가합니다.
물론 레코드 삭제를 되돌리려는 경우가 있습니다 (특히 중요한 데이터를 실수로 삭제하면 불필요한 지출이 발생하는 경우). 하지만이를 활용하려면 애플리케이션을 수정하고 양식을 추가해야하므로 다른 행을 모델 클래스에 추가하는 것이 문제가되지 않습니다. 삭제 된 데이터를 저장하는 다른 방법도 있습니다.
IMHO는 모든 모델에 대해 불필요한 기능이며 필요할 때만 켜야하며 모델에 안전을 추가하는이 방법은 특정 모델에 적용 할 수 있습니다. 그리고 이는 이 아니라 기본적으로을 의미합니다.
(이 과거는 railsninja의 가치있는 발언의 영향을 받았습니다).
@Pavel Shved
뭐라 구요? Ruby는 코드를 두려워하는 겁쟁이를위한 것이 아닙니다. 이것은 내가 들었던 가장 우스운 물건 중의 1 개 일 수 있었다. 물론 조인 테이블에서 레코드를 삭제하려고하지만, 조인 모델에 대해 여러 가지가있을 수 있습니다.
비즈니스 응용 프로그램에서는 종종 실수를 저 지르지 않는 것이 좋으며 사용자는 실수를합니다.
많은 답변, 파벨은 일종의 드리블입니다. 필요한 곳에서 SQL을 사용하는 것은 부끄러운 일이 아니며, deleted_at를 사용하면이 거대한 리펙터가 어떻게 발생합니까?
@Horace 저는 is_paranoid가 핵심에 있어야한다고 생각하지 않습니다. 모든 사람들이 그것을 필요로하지는 않습니다. 그것은 환상적인 보석이지만, 나는 내 작업 애플 리케이션에서 그것을 사용하고 훌륭한 작품. 나는 또한 내가 필요하지 않을 때 SQL에 의지하도록 강요하지 않았으며, 내 존재로 인해 큰 리팩터링을 볼 수 없다는 것을 확실히 확신한다. 필요할 때 사용할 수 있지만 보석이어야합니다.
아, "비즈니스". 그 말을 듣고 바로 아이처럼 느껴져야하고 즉시 내 대답을 삭제해야합니까? :-) 나의 요점은 : (1) "나는 두렵다"는 결정을 내리는 이유가 아닙니다. (2) is_paranoid를 절대 원하지 않는 경우가 있습니다. (3) Horace *는 아마도 SQL 작성이 수치스럽지 않고 아마도 * 그가 * 이것을 할 필요가 없을 것이라고 생각할 것입니다. 어디에서나 is_paranoid를 사용하는 것이 활용되지 않을지라도 SQL을 쓰는 것을 더 어렵게 만듭니다. –
is_paranoid가 핵심이 아니어야한다는 것에 동의합니다. 당신의 대답은 좋지 않습니다. 그리고 누가 당신이 기록을 확실히 삭제해야한다고 말합니까? 그것은 완전히 상황에 맞는 것입니다. 나는 마치 아이처럼 느껴지려고했지만, 마치 당신이 하나처럼 행동 하긴했지만. 내 요점은 "비즈니스"코드와 데이터가 당신의 것이 아니라 때로는 미안보다 더 안전합니다. 너무 많은 사람들을 잘못 인도하지 않기를 바랍니다. – nitecoder
좋아, 너는 어느 정도 요점을 짓고, 나는 내 게시물에 설명을 추가 할 것이다. –
이것은 말도 안됩니다. 내 대답에 대응. – nitecoder