MOSS - 120개 이상의 추가 열과 별도의 연결 목록 중 무엇을 선택하시겠습니까?

Question

피드백을 활용할 수 있는 디자인 문제가 있으므로 동료 SharePoint 전문가가 이 문제를 해결하는 데 도움을 줄 수 있기를 바랍니다.

저는 단일 MOSS 목록(List1)에서 일련의 프로젝트를 관리하고 있습니다. 여기서 "프로젝트 이름" 열은 관련 목록에 대한 '기본 키'(적어도 제 생각에는)로 처리됩니다.각 프로젝트에는 정의된 결과물 세트(각 프로젝트 수명 동안 최대 37개의 개별 활동)가 연결되며, 각 결과물은 프로젝트 중에 완료하도록 권장되는 하나의 중요한 활동을 추적합니다.

나의 초기 생각은 37개의 결과물을 별도의 '조회 목록'(List2)으로 정의하여 각 결과물이 "Deliverable Name"뿐만 아니라 다음도 갖도록 하는 것이었습니다.

"URL" - 별도의 비 모스 위키에 링크하여 사용자가 전달 가능한 "설명"을 달성하는 방법에 대한 추가 정보를 찾을 수 있습니다. 세부 사항을 얻기 위해 별도의 서버) "프로젝트 단계" - 전달 가능성을 완료 해야하는 순서대로 필터링하고 전달 된 순서로 정렬하는 데 도움이됩니다.

그런 다음 다른 목록(List3)에 개별 항목을 생성합니다. 각 항목은 (1) 프로젝트 및 (2) '제공물 조회 목록'의 '템플릿' 항목과 연결되어 있어 이러한 항목을 추가로 추적할 수 있습니다. 프로젝트/제공물별 필드:

"완료 날짜" - 전달 가능한 날짜가 완료된 날짜 (지금까지) "어떻게 처분 된 방법" - 드롭 다운 목록, 사용자가 "완료", "연기", "N/A"또는 "Still과 같은 상태를 선택할 수있는 드롭 다운 목록. 프로세스 ""노트 " - 무료 형식 텍스트를 기록하여 무엇을했는지, 그 이유에 대한 더 많은 설명/이론적 근거

이 접근 방식의 한 가지 주요 문제점은 Microsoft의 모범 사례 지침이 목록에 2000개 이상의 항목이 포함된 MOSS 목록을 권장하지 않는다는 것입니다.각 프로젝트에 더 많은 결과물을 추가하지 않더라도 매우 짧은 시간에 54개 프로젝트("허용된" 수 = 2000/37개) 이상으로 확장할 수 있을지 걱정됩니다.List3의 여러 인스턴스를 만드는 것은 이론적으로 가능하지만 자동화하기에는 악몽처럼 보입니다(추적 프로젝트 세트가 늘어남에 따라).

제가 생각할 수 있는 첫 번째 대안은 프로젝트 목록에 37개의 추가 열과 사용자가 필요로 하는 "날짜", "처리" 및 "메모" 필드를 활성화하는 데 필요한 (37 x 3) 열을 미리 정의하는 것입니다. 각 결과물을 추적합니다.또한 이 모든 데이터 입력 및 데이터 관리를 위해 UI를 "예쁘게" 만드는 데 사용하고 싶은 각 SPD 양식 및 웹 파트 페이지의 취약한 구성/디자인을 관리해야 합니다.

누군가 나에게 제안한 또 다른 대안은 각 프로젝트에 대한 하위 사이트를 만들고 프로젝트 하위 사이트의 단일 목록에 프로젝트 결과물을 나열하는 것입니다.나에게는 엄청나게 무거워 보이는데, 나는 이것을 최후의 수단으로만 생각하고 있다.

외부 데이터베이스나 서버에 설치해야 하는 코드에 의존하지 않고 MOSS에서 이 작업을 어떻게 수행하시겠습니까?이 작업을 수행하는 데 일반적인 MOSS 목록 기능에서는 명확하지 않은 몇 가지 트릭이 있습니까?사용해야 할 MOSS의 숨겨진 기능이 있나요?아직 발견하지 못한 SharePoint Designer의 멋진 측면이 있나요?나 가지다 다른 많은 사람들도 이와 같은 한계에 직면했고 이를 알아냈다고 믿습니다. 일부 작동하게 하는 방법.여러분이 제안할 수 있는 어떤 아이디어라도 감사하겠습니다. 미리 감사드립니다!

Answer 1

내 경험상 컨테이너 당> 2000 항목 (목록, 폴더, 인덱스 항목)은 세계의 끝이 아닙니다. 그러나 더 나쁜 것은 서로 연결된 여러 목록을 사용하기 시작하는 경우 (일반적으로 조회를 통해)입니다. 그런 다음 조회의 일부가 아닌 부모의 값에 따라 아이를 필터링하고 싶을 때 큰 고통이됩니다. 이 데이터에 대한보고는 가입과 관련된 레코드가 많으면 매우 느리게 진행될 수 있습니다.

과거의 성향은 3 번째 정상 형태를 사용하는 것이었지만 SharePoint 목록과 잘 어울리지 않으므로 상당히 평평한 구조를 고려할 것입니다. 그러나 일대일 관계가 있다면 대부분 별도의 목록을 사용하고 싶을 것입니다.

Answer 2

Microsoft의 모범 사례는 성능의 이유로 2000 개 이상의 항목이 보다; 목록에 수백만 개의 항목이 완벽하게 잘 가질 수 있지만 한 번에 2000 개 미만의 항목 만 반환하기 위해 뷰와 색인 열을 신중하게 정의해야합니다.

목록 데이터가 자주 변경되지 않고 서버에서 많은 메모리를 사용할 수있는 경우 목록을 쿼리하기 위해 PortalsItemApprovider를 살펴볼 가치가 있습니다. 목록을 쿼리하는 다양한 방법에 대한 자세한 정보와 전체 비교 백서를 찾을 수 있습니다. 여기.

건배!

Answer 3

각 프로젝트에 대해 하위 사이트나 사이트 모음을 사용하는 것이 좋습니다.프로젝트 사이트에 대한 중요한 정보를 롤업할 수 있는 메타 프로젝트 사이트를 정의할 수 있습니다.그러면 프로젝트 사이트는 결과물보다 더 많은 것을 저장할 수 있으며 프로젝트 공동 작업의 초점이 될 수 있습니다.

MS에서는 50,000개가 넘는 사이트 모음을 사용하면 성능이 저하되기 시작하므로 어느 정도 유연성이 있다고 조언합니다.콘텐츠 데이터베이스가 너무 커지면 콘텐츠 데이터베이스 간에 하위 사이트를 이동할 수 있는 좋은 방법이 없기 때문에 많은 문서를 저장할 때 하위 사이트를 빠르게 관리할 수 없게 될 수 있습니다.

프로젝트 아키텍처별 사이트 모음은 더 큰 유연성을 제공하고 복잡한 조회 목록으로 인한 불쾌한 문제를 피할 수 있다고 생각합니다.그러나 검색 결과 웹파트를 상당히 영리하게 사용하는 데 의존합니다.

Answer 4

"Moss는 목록에> 2000 항목이있는 목록"

이것은 단지 당신이보기에서 보여주는 것이기 때문에 이것은 문제가되지 않습니다. Moss는 더 많은 필드가있는 MOE 복잡한 품목을 추가하기위한 개발 플랫폼이 아니라고 생각합니다. 정상적인 sqlserver asp.net 응용 프로그램을 수행해야합니다