정말 말문이 막힙니다. 두 번째 제출이 다시 거부되었습니다. 그 이유는 "기술적인 논의에 관한 내용입니다. 다른 사람들과 더 나은 기술 교류를 위해 이 문제에 대한 귀하의 생각을 간략하게 이야기하는 것이 좋습니다." 레이아웃 때문에 처음이라면 인정하겠습니다. Q&A 포스팅이 왜 이렇게 어려운가요? 좋아요, 필요에 따라 조금만 표현해 보세요. 정말 모르겠다면 무작위로 구성해야 할까요? 홈페이지 팀의 취지는 좋은 것이라고 생각하지만, 신입사원 입장에서는 이 때문에 포기될 가능성이 높습니다. 마지막으로 이 포럼을 더 이상 사용하지 않겠습니다. 질문하기가 정말 어렵습니다.
다음은 원문이며, 마지막에 제 생각을 일부 첨부하겠습니다.
여기 처음 왔습니다. 처음으로 레이아웃이 너무 지저분해서 검토에 실패했습니다. 나중에 이에 대한 마크다운 구문을 배웠습니다. 더 이상 고민하지 말고 본문으로 들어가겠습니다.
대형 상장 공기업은 여러 도, 시에 지점을 두고 있으며, 전국 지점 및 자회사의 업무 프로세스와 재무 데이터를 통일적으로 관리하기 위해 관리 플랫폼을 개발하여 각 도, 시에 배포했습니다. 다양한 도시의 기존 분산형 금융 시스템 및 비즈니스 관리 시스템을 대체하려면 실제 상황에 따른 2차 개발이 필요합니다.
프런트엔드는angularJs, bootstrap,html을 사용하고, 백엔드는 springMVC, MyBatis를 사용하고, 데이터베이스는 Oracle과 Mysql을 사용하고, rpc 프레임워크는 dubbo를 사용하고, 등록 센터는 Zookeeper를 사용하고, 캐시는 Redis를 사용합니다. + 클러스터. 전체 시스템에는 여러 비즈니스 모듈이 포함되어 있으며, 주로 "프로젝트 관리", "계약 관리", "조달 관리", "판매 관리" 및 "회계 관리"의 5개 모듈이 포함됩니다.
기존 비즈니스를 기반으로 100개 이상의 보고서를 작성하세요. 보고 모듈에는 독립적인 데이터베이스와 애플리케이션이 있습니다.
모든 보고서에 사용할 큰 테이블은 어떻게 구성하나요?
업무 부분을 명확히 이해하는 것이 가장 기본이지만, 각 모듈은 인터페이스를 통해 서비스를 호출합니다.
분산 데이터베이스에서 대량의 데이터를 추출하는 방법은 무엇입니까?
각 모듈에는 자체 데이터베이스가 있으며 일부는 Oracle을 사용하고 일부는 MySQL을 사용하며 데이터 볼륨 수준은 수천만을 초과합니다.
데이터를 동기화하는 더 합리적인 방법은 무엇입니까? 어떤 기술로?
증분 동기화는 어렵습니다. 증분 데이터가 누락되지 않도록 하는 좋은 방법은 없습니다. 전체 데이터인 경우 매번 데이터의 양이 너무 많습니다. 또한 보고서를 표시하고 데이터를 내보낼 때 성능을 어떻게 보장할 수 있습니까?
이런 큰 프로젝트는 처음이라 정말 헷갈립니다. 명확하게 표현되지 않을 수 있습니다. 추가할 내용이 있으면 메시지를 남겨주세요. 포럼에 계신 선배님들께서 제게 조언을 해주시면 좋겠습니다. 정말 감사하겠습니다.
ps:
마크다운에는 아직도 잘 이해되지 않는 부분이 많습니다. 예를 들어 정렬된 목록과 정렬되지 않은 목록이 중첩되면 검은색 점이 비어 있는 이유는 무엇인가요?
왜 순서가 지정되지 않은 목록 줄 바꿈은 현재 행에만 유효하며, 현재 행이 유효할 때 위에 줄 바꿈된 줄은 유효하지 않습니까?
이해가 안 되네요. 편집기마다 구문이 다를 수 있나요?
다른 사람이 게시한 게시물의 마크다운을 어떻게 볼 수 있나요? 볼 수 있다면 최소한 배울 수는 있습니다.
모든 보고서의 통계적 차원과 공통 필드를 분석하고, 보고서 모듈에서 새로운 oracle 사용자를 생성하고, 모든 필드를 모듈에 따라 테이블로 나누어 보고서의 기본 테이블로 사용합니다.
DBLink를 통해 Oracle 데이터베이스와 Mysql 데이터베이스를 연결하고 저장 프로시저를 사용하여 기본 대형 테이블에 직접 데이터를 삽입합니다. 장점: 성능 향상; 단점: 다른 사람이 규칙을 유지하기 어려워집니다.
위 내용은 개인적인 의견입니다. 선배님들의 조언 부탁드립니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
당신이 언급한 수요는 기본적으로 데이터 웨어하우스를 구축하는 것입니다.
1. 데이터 웨어하우스의 데이터베이스와 비즈니스 시스템은 독립적입니다. 데이터 웨어하우스의 모델링에는 단순히 큰 테이블을 구축하는 것이 아니라 일반적으로 계층적 설계가 필요합니다.
일반적으로 버퍼 계층, 기본 계층, 집계 계층, 보고서 계층 등으로 구분됩니다. 각 계층의 초점은 다릅니다. 기본 계층은 여전히 패러다임 모델을 기반으로 하며, 집계 계층은 일반적으로 데이터를 중복화해야 합니다. 보고서 레이어는 일반적으로 많은 열이 있는 넓은 테이블 디자인입니다.
2. 데이터 양이 많은 경우 증분 메커니즘이 있어야 합니다. 그렇지 않은 경우 시스템 수정을 적용해야 합니다.
3. 동기화 방법에 대한 몇 가지 아이디어가 있습니다. 으아악