나는 미래에 하나의 사용자가 만들 수있는 항목 수 때문에 여러 데이터베이스에 일부 테이블을 분산시킬 수있는 응용 프로그램 용 데이터베이스 스키마를 설계하는 중입니다. 현재 공통 베스트 프랙티스를 염두에두고 테이블 관계를 설계하고 있지만 서버 아키텍처, 테이블 파티셔닝, 샤딩, 마스터/슬레이브 등은 생각하지 않습니다. 스키마를 만들 때 이러한 것들을 고려해야합니다. 너무 먼 미래를 생각하고있는 상황 중 하나입니까? 지금까지 내가 결정한 유일한 결정은 응용 프로그램 수준에서 외래 키 제약 조건을 관리하는 것이므로 다른 테이블로 테이블을보다 쉽게 이동할 수 있습니다.여러 데이터베이스에 상주 할 수있는 관계형 테이블을 다르게 설계해야합니까?
논리 설계 단계에있는 것처럼 들리 겠지만 객체 모델이 더 편리 할 수도 있습니다. 나는 당신이 너무 일찍 관계형 디자인으로 뛰어 들었다고 생각한다. 일부 데이터는 시스템 적용 무결성 제약 조건을 갖춘 관계형 DB에 적합 할 것입니다. 다른 것들은 RESTful 서비스, memcache 또는 파일 시스템 클러스터에 더 적합 할 수 있습니다. 문제가 필요하지 않은 경우 기능을 설계하지 마십시오. 그리고 ACID 트랜잭션은 디자인 기능이라는 것을 잊지 마십시오. ;)
확장 관계형 디자인의 예제가 있습니다. WordPress에는 모 놀리 식 관계형 디자인이 있지만 wordpress.com을 실행하는 엄청나게 파문을당한 WordPress 뮤는 코드의 99 %를 공유합니다. 다른 사이트 (이 사이트!)는 관계형 디자인에서 거대한 사용자 커뮤니티를 지원합니다.
나는 성능을 무시하고 나중에 추가 할 수 있다고 가정하는 것이 잘못되었다고 생각합니다. 성능을 무시하고 버릴 계획입니까? 그것은 합리적인 접근법입니다.
예 프로덕션 환경에서 예상되는 데이터베이스 크기의 성능을 고려하여 설계해야합니다. 디자인의 변화가 거의 없기 때문에 데이터베이스가 얼마나 잘 확장되는지 엄청나게 다를 수 있습니다. 데이터베이스는 수백만 건의 레코드가 있으면 쉽게 리팩토링 할 수 없습니다. 또한 디자인에서 데이터 보안 및 데이터 무결성을 고려해야합니다. 데이터 무결성은 데이터베이스 수준에서만 성공적으로 보호 될 수 있습니다. 응용 프로그램에서이를 수행하려고 시도하는 것은 어리 석고 근시안입니다.
필요한 경우 메타 데이터를 고려해야합니다. 감사해야합니까? 복제에 GUID가 필요합니까? 레코드가 삽입 된시기를 알아야합니까? 보관 계획을 세우시겠습니까?
응용 프로그램에서 외래 키를 관리하는 것은 매우 좋지 않습니다. 데이터는 종종 응용 프로그램이 아닌 다른 소스에서 데이터베이스로 가져옵니다. 결국에는이 접근 방식에 데이터 무결성 문제가 발생할 것입니다. 정말로 나쁜 생각. – HLGEM
응용 프로그램 이외의 소스에서 데이터베이스로 데이터를 가져 오는 경우 걱정해야 할 더 큰 문제가 있습니다. –
할, 그게 바보 같아. 데이터는 응용 프로그램뿐만 아니라 대량의 업데이트를 통해 다른 공급 업체의 가져 오기에서 가져옵니다. 이러한 일을 계획하지 않으면 문제가 발생합니다. 그러나 잘못된 데이터베이스를 설계하십시오. 그래서 그 데이터베이스를 수정해야합니다. – HLGEM