문제

CMS를 만들고 있는데 아직 구조물에 주어진 페이지에 대한 완전한 URL을 어디서 저장 해야하는지에 대한 문제에 대해서는 아직 해결되지 않았습니다.

모든 페이지에는 슬러그 (URL 친화적 인 페이지 이름)가 있으며 모든 페이지에는 무효가 가능한 (최상위 페이지 용) 부모와 어린이가 있습니다.

주어진 페이지에 대한 전체 URL (/First-Page/Sub-Page)을 어디에 저장합니까? 페이지의 다른 속성과 함께 데이터베이스 또는 일부 캐시에 있어야합니까?

업데이트

그것은 내가 묻는 데이터베이스 디자인이 아니고, 전체 URL을 주어진 페이지에 저장할 곳이 아니므로 사용자가 요청한 페이지를 얻기 위해 전체 URL을 통과 할 필요가 없습니다 (/first-page/sub-page )

업데이트 2

현재 요청 된 URL에 속하는 페이지를 찾아야합니다. 요청 된 URL이 /First-Page /하위 페이지 인 경우 URL을 분할하고 데이터베이스를 통해 루핑을 원하지 않습니다 (분명히).

차라리 테이블에 전체 URL을 사용하여 단일 쿼리 (url = '/first-page/sub-page')를 수행 할 수 있지만 이상적이지 않은 것 같습니다. 부모 페이지? 그런 다음 모든 후손에 대한 URL 필드를 업데이트해야합니다.

다른 사람들은이 문제를 어떻게 해결합니까? 그들은 데이터베이스에 넣고 있습니까? 캐시에서 페이지의 ID에 대한 첫 페이지 /하위 페이지를 맵핑 하시겠습니까? 아니면 요청 된 URL을 분할하고 데이터베이스를 통해 루핑을하고 있습니까?

감사

앤더스

도움이 되었습니까?

해결책

웹 서버가 지속적으로 URL을 찾아야하므로 캐시에 저장하십시오. 페이지의 URL이 매우 빠르게 변경 될 것으로 예상하지 않는 한 캐싱은 데이터베이스 중심 웹 사이트에서 병목 현상 인 데이터베이스의로드를 크게 줄입니다.

기본적으로 URL-> 페이지를 렌더링하는 데 필요한 사전을 원합니다. 많은 웹 서버는 운영 체제의 파일 시스템을 사전으로 자동 사용하며 파일 시스템의 파일이 변경 될 때 인식 할 수있는 내장 캐시가 종종 있습니다. 이것은 아마도 CMS에 쓸 수있는 것보다 훨씬 더 효율적 일 것입니다. 따라서 CMS가 파일 시스템에서 직접 구조를 구현하고 하드 또는 소프트 링크로 추가 매핑을 처리하는 것이 좋습니다.

다른 팁

나는 방금 이것을 위해했다 MVCCMS. 콘텐츠 카테고리/하위 카테고리 및 콘텐츠 페이지의 아이디어를 가지고 갔다. 컨텐츠 범주 / 하위 범주가 만들어지면 부모를 통해 재귀 적으로 가서 전체 경로를 구축 한 다음 카테고리 테이블에 저장합니다. 그런 다음 페이지가 요청되면 올바른 컨텐츠 페이지를 찾아 내 NAV 구조를 통과 할 때 현재 내 NAV가 현재 또는 활성 경로인지 확인할 수 있습니다.

이 접근법은 카테고리가 편집 될 때 발생하는 일에 대한 몇 가지 규칙이 필요합니다. 현재 접근 방식은 전체 경로가 하위 범주로 설정되면 나중에 일반 도구로 변경할 수 없다는 것입니다.

소스는 mvccms.codeplex.com입니다

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top