학습용으로 나는 블로깅 시스템을 도입하려고합니다.블로깅 시스템의 데이터베이스 디자인
목표는 blogger.com이나 wordpress.com과 같이 여러 개의 블로그를 만들 수있는 코드를 작성하는 것이지만 훨씬 단순화되었습니다.
나는이 유형의 스크립트에 가장 적합한 데이터베이스 설계가 무엇이라고 생각합니까?
큰 테이블 하나를 갖고 모든 사용자의 모든 블로그 (friendfeed와 같은)의 게시물을 포함하는 것이 더 좋습니까, 아니면 각 블로그 게시물마다 별도의 테이블을 만드는 것이 더 좋습니까?
사전에 큰 도움을 주신 덕분에 피터.
가장 효율적인 방법은 제대로 표준화 된 데이터베이스 (작성자, 게시물, 설명 테이블)를 작성한 다음 문제가 발생할 때 설계하지 않고 성능 문제를 처리 할 방법을 찾는다. 앞면 ... 그 문제는 결코 실현 될 수 없습니다.
일반적으로 단일 테이블을 여러 테이블로 분할하려는 경우 데이터를 쿼리하는 방법을보고 데이터를 분할하는 가장 좋은 방법을 결정해야합니다. 그 시간이 파티션을 나누는 더 좋은 방법 일 수도 있고, 저자 또는 블로그 URL을 기준으로 파티션을 나누고 싶을 수도 있습니다.
합계 - 전통적인 정규화 된 디자인으로 시작하고 성능 문제가 발생했을 때 그 경로에서 벗어난 경우.
이것은 좋은 질문입니다 (+1).
확장 성의 관점에서 볼 때, 모든 사람의 모든 블로그에 대해 하나의 표는 매우 큰 예산을 갖고 있지 않는 한 비행하지 않을 것입니다. 어쩌면 FriendFeed가 서버 팜을 테이블에 밀어 넣을 수는 있겠지만, 나는 그들에 대한 연구를 읽는 것이 흥미로울 것입니다.
소수의 사용자 만 예상하는 경우 디자인에 집중하고 확장 성을 무시하십시오.
답변은 프로젝트 확장의 정도에 달려 있다고 생각합니다.
+1 좋은 답변입니다! – amelvin
또한 여러 테이블로 분할하면 즉시 SQL을 생성해야하거나 복잡한 동적 별칭을 사용하여 동일한 테이블 복사본을 사용하는 하나의 응용 프로그램을 만들 수 있습니다. 이는 잠재적 인 소프트웨어 유지 보수의 악몽입니다. 동적으로 생성 된 SQL을 사용하는 것이 잘못되면 보안상의 악몽이 될 수 있습니다. –