대출 개시 시스템을위한 훌륭한 스키마 설계는 무엇입니까?

Question

나는 대출 상품 매개 변수에 따라 대출을 생성하고 대출의 상환 일정을 그릴 수있는 대출 개시 시스템을 설계하고있다. 또한 벌금, 수수료 등을 추가 할 수 있어야합니다. 대출 일정 변경이 가능해야합니다. 또한 신속한보고를 위해 대출 일정이 필요합니다.

대출 테이블, 대출 제품 테이블, 지불 일정 테이블 및 대출 내역 테이블 등이 있습니다.이 스키마를 너무 많이 변경하지 않도록 미리 설계 할 수있는 방법을 이해할 수 없습니다.

ruby, rails3 및 datamapper에서이 작업을 수행하고 있습니다.

Answer 1

가장 밀접하게 지정된 응용 프로그램을 제외하고 나는별로 변하지 않는 스키마를 디자인 할 수 있는지 확신하지 못합니다. 당신이 할 수있는 것은 변화가 일어나는 것을 허용하는 부서지기 쉬운 스키마가 아닌 스키마를 만드는 것입니다. 대부분 그 부분을 의미합니다.

1. 당신이 오늘날의 요구 사항
2. 표준화를 충족 할 필요가 알고있는 데이터 만 포함합니다.
3. 자동 테스트를 작성하십시오.

첫 번째 규칙은 프로그래머가 코드 팽창을 피하기 위해 사용하는 규칙 인 "가장 간단한 작업은 할 수 있습니다"또는 "필요하지 않을 것"과 유사합니다. 더 작은 코드 기반과 같이 더 작은 스키마는 변경하려는 노력이 덜 필요합니다. 두 번째 (정규화)는 코드를 더 저렴하게 변경하는 데 사용되는 또 다른 규칙 인 "한 번만"으로 알려진 "직접 반복하지 마십시오 (DRY) 원칙"과 유사합니다. 세 번째 규칙 (테스트)은 프로그래머가 모든 것을 깨뜨리는 것에 대해 걱정할 필요없이 리팩토링을 가능하게 만드는 방법입니다. 테스트에서는 스키마를 사용하는 코드를 테스트하는 것뿐만 아니라 스키마 자체를 테스트하는 것을 의미합니다 (트리거, 규칙, 계단식 삭제, &). c. 테스트 할 수 있으며 요구 사항 변화에 따라 테스트를 변경하는 것이 더 쉽습니다.

데이터베이스 세계에서 이러한 규칙을 위반할 수있는 변명이 있습니다. 규칙 1 (가장 단순한 일/YAGNI)을 어기는 이유는 데이터가 처음부터 수집하기가 쉽고 나중에 필요할 것으로 판단 할 경우 수집하기가 어렵거나 불가능하기 때문입니다. 아직도이 변명에 굴복하기 전에 두 번 생각하십시오. 거의 언제나 열이나 테이블을 추가하여 발생하는 데이터 격차로 너무 많은 소란을 겪지 않고도 처리 할 수 ​​있습니다. 그러나 내일 만 필요할 수도있는 데이터를 포함 시키면 스키마를 변경할 때마다 비용을 지불하게됩니다. 당신이 필요로하는 것을 포함하는 데이터의 각 비트는 아무런 유익이없는 비용이었습니다. 아마도 더 중요한 것은 추가 데이터가 성능에 심각한 영향을 줄 수 있기 때문입니다. 메모리에 저장할 수있는 레코드 수가 줄어들 기 때문입니다. 디스크에서 읽을 때 데이터베이스가 좋은 성능을 발휘하는 데 많은 어려움을 겪지 만 최상의 성능은 충분한 메모리 (또는 충분한 데이터가 부족하여)로 인해 작업 세트 전체 또는 대부분이 RAM에 저장됩니다.

규칙 2 (정규화)를 위반하는 이유는 성능입니다. "데이터웨어 하우스"응용 프로그램은 많은 테이블 조인으로 인해 데이터베이스가 느리고 괴팍하게되는 경우 비정규 화가 필요할 수 있습니다. 비정규 화되기 전에는 비정규 화하기 전에 필요하다고 확신하고 싶습니다. 두 번 이상 존재하는 데이터는 스키마를 변경하기 어렵게 만들고 & 업데이트를 삽입 할 때 더 많은 작업을 위해 쿼리 속도를 줄입니다.

규칙 3 (테스트)을 위반 한 것에 대해 변명의 여지가 없거나, 좋지는 않지만 적어도 하나는 존재하지 않는다는 의미는 아닙니다.

마틴 파울러 (Martin Fowler)는 "Evolutionary Database Design"이라고 씁니다. 스콧 앰버 (Scott Amber)와 프라 모드 사다 랄레 (Pramod Sadalage)는 Refactoring Databases에 관한 책을 가지고 있습니다. a summary/cheat sheet of the book's refactorings을 참조하십시오.