모델 관계가 필요한 경우 오류를 어떻게 보호합니까?

Question

응용 프로그램을 성공적으로 작동시키기 위해 서로에 의존하는 많은 데이터베이스 관계가있는 응용 프로그램이 있습니다. 응용 프로그램의 힌지는 일정이라는 모델이지만 스케줄은 블록, 직원, 작업장 및 할당을 당기는 것입니다 (그 외에도 모든 블록은 데이터베이스에서 과제를 가져옵니다). 하루 종일 직원 일정을 조립하십시오.

앱을 만들 때 모든 것이 데이터베이스에 저장되기 전에 모든 조각이 제자리에 있어야하는 유효성 검사에 많은 중점을 두었습니다. 이것은 지금까지 환상적으로 해결되었으며, 앱은 거의 6 개월 동안 생방송 및 두근 거렸으며, 한 달에 약 15 만 명의 요청이 딸꾹질이나 오류없이 제공되었습니다. 지난주까지.

지난주 누군가가 일정을 변경하는 동안 데이터베이스가 잘못된 것처럼 보이고 할당이 누락 된 상태에서 데이터베이스에 일정이 저장되었습니다. 협회는 모든 관점에서 호출되기 때문에이 일정이 데이터베이스에서 호출 될 때마다 응용 프로그램은 NIL을 호출하기 위해 Nomethod 오류를 던집니다.

내가 진술하는 방식으로 응용 프로그램을 설계 할 때 데이터베이스/유효성 검사 측면에서 가능한 실패를 방지합니까? 그렇다면 어떻게 프로그래밍 적으로 그것에 대해 방어합니까? 모든 관계를 확인하여 시야에 보내기 전에 그것이 아닌지 확인합니까?

나는이 질문이 일반성에있어서 awash라는 것을 알고 있으며, 내가 의미하는 바에 더 구체적 일 수 있다면, 의견에 알려주십시오.

Answer 1

추가하는 것이 좋습니다 데이터베이스 강화 외국 주요 제약 조건 그리고 중요한 운영 그룹을 트랜잭션으로 포장합니다.

어딘가에 일정과 할당 사이에 외국 키가있는 경우 데이터베이스 강화 외국 키 제약 조건으로 인해 잘못된 삽입물이 방지 될 수 있습니다. 또한 트랜잭션에서 특정 작업을 랩핑하면 삽입/업데이트/삭제의 전체 스트림이 발생하거나 실패하여 깨끗한 상태로 되돌아 갈 수 있습니다.

Answer 2

유효성 검사 외에도 다른 답변에서 언급 한 바와 같이 일부 데이터베이스 제약 조건을 추가하면 고아를 찾는 데이터베이스를 주기적으로 스윕하는 백그라운드 작업을 실행할 수도 있습니다.

하나를 찾으면 정리하거나 (가능하면) 삭제하거나 삭제하거나 비활성화를 표시하고 이메일을 보내서 나중에 볼 수 있습니다. 데이터의 양과 특성에 따라 1 분에 한 번, 한 시간, 하루에 한 번 ...

이렇게하면, 당신이 가지고있는 모든 보호 수단에도 불구하고 나쁜 데이터가 들어 오면 나중에보다 빨리 알게 될 것입니다.

Answer 3

나는 이것에 대한 비 전통적인 지혜를 주장 할 것이다. 설명하는 제약은 데이터베이스에 속하지 않으며 OO 코드에 속합니다. 그리고 "데이터베이스가 잘못되었다"는 것은 사실이 아니며, 응용 프로그램이 부적절하게 검증 된 데이터를 삽입 한 것은 의심의 여지없이 사실입니다.

데이터베이스가 이러한 수표의 부담을 전달하기 시작하면 비즈니스 규칙을 스키마에 넣습니다. 최소한, 이것은 단위 테스트를 작성하기가 훨씬 더 어려워집니다 (아마도 처음에는 이것을 잡았을 것입니다. 그러나 이제 다른 테스트를 추가 할 수있는 기회입니다.)

이상적으로는 RDBMS를 다른 일반 데이터 저장소로 교체 할 수 있어야하며 여전히 모든 기능적 논리가 적절한 다른 장소에서 적절하게 활성화되고 변경되지 않았습니다. UI는 데이터베이스 예외를 직접 다루는 데 훨씬 덜 대화하지 않아야합니다.

원하는 경우 추가 데이터베이스 제약 조건을 추가 할 수 있지만 백업으로 엄격하게 여야합니다. 보시다시피, 데이터베이스 구조 오류 처리는 우아하게 (특히 UI가 관련된 경우) 훨씬 더 어렵다.

Answer 4

앱이 작동하기 위해서는 사실이어야 할 것이 있다면, 그것이 정말로 assert()S를위한 것입니다. 나는 거의 루비를 사용한 적이 없지만 그 개념이 있어야한다고 생각합니다. 코드 전체의 다양한 장소에서 전제 조건을 시행하는 데 사용하십시오. 외부 (사용자) 입력을 소독하고 검증하는 것과 결합 된 것은 당신을 보호하기에 충분해야합니다. 체크인 이후에 문제가 발생하면 앱이 의롭게 충돌 할 수 있다고 생각합니다 (물론 통제 된 방식으로).

당신이 겪고있는 문제가 데이터베이스의 버그라는 것을 의심합니다. 유효성 검사에 간과 한 에지 케이스가있을 가능성이 높습니다.