Sharepoint : 사용자가 작성/편집 한 모든 문서를 찾을 수있는 SQL

Question

Sharepoint 2003에서 특정 사용자 ID로 작성/수정 된 모든 문서를 표시하는 쿼리를 찾고 있습니다.

사용자 (사용자 정보, 사용자 데이터) 에 대한 문서 (문서) 및 테이블이있는 테이블을 찾았지만 조금 이상하게 보입니다. 우리의 userdata 테이블에는 99,000 개의 레코드가 있고 userinfo에는 12,000 개의 레코드가 있습니다. 400 사용자!

400 레코드가있는 사용자 테이블과 간단한 1 대 다수 관계를 예상하고이를 문서 테이블에 합치는 것으로 추측합니다. 그러나 나는 그렇지 않습니다.

도움을 주시면 감사하겠습니다. 내가 그 쿼리를 다시 셰어 포인트 2003 구조 번역 한 감사 비요른, : 편집

내가 할 수있는 경우

select 
d.* from 
userinfo u join userdata d 
on u.tp_siteid = d.tp_siteid 
and 
u.tp_id = d.tp_author 
where 
u.tp_login = 'userid' 
and 
d.tp_iscurrent = 1 

이 나에게 siteid/listid/tp_id 년대의 목록을 가져옵니다 내가해야합니다 확인합니다 그것들을 파일 이름/경로로 되돌립니다. 전체 : 추가 도움이 필요합니다.

Answer 1

SharePoint 2003에서는 데이터베이스를 본 적이 없지만 2007 UserInfo는 사이트에 연결되어 모든 사용자가 각 사이트 모음 (또는 그에 상응하는 2003 가지 개념)에 대해 UserInfo에 행을 가지고 있음을 의미합니다. 따라서 사용자가 무엇을하는지 식별하려면 해당 사이트 내의 사이트 ID와 사용자 ID가 모두 필요합니다. 다른 사람들이 여기에 쓰기로, SharePoint 데이터베이스로 직접 이동하지 않는 것이 좋습니다,하지만 난 당신의 머리를 사용 말하고주의 될 것이다 :

select d.* from userinfo u 
join alluserdata d on u.tp_siteid = d.tp_siteid 
and u.tp_id = d.tp_author 
where u.tp_login = '[username]' 
and d.tp_iscurrentversion = 1 

업데이트 : 2007 년, 나는 이런 식으로 뭔가 시작합니다. 업데이트는 모두 no-no이며, 선택은 컨텍스트에 따라 다릅니다.

Answer 2

SharePoint에서 해당 쿼리를 사용하려는 경우 콘텐츠 데이터베이스에서보기를 만들거나 데이터베이스에 직접 쿼리하는 것이 큰 아니요 인 것 같습니다. 해결 방법은 개체 모델을 반복하고 결과를 사용자의 데이터베이스에 쓰는 사용자 지정 코드 일 수 있습니다. 이것은 타이머 기반이거나 eventtrigger를 기반으로 할 수 있습니다.

Answer 3

SHAREPOINT 데이터베이스를 직접 확인하지 마십시오!

내가 충분히 명확하게 만들었을 까? :)

C#에서 사용할 수있는 개체 모델을 실제로 살펴볼 필요가있는 경우 SiteCollection에 대한 SPSite 인스턴스를 가져온 다음 SPSite 및 SPWeb 개체에 속한 SPList 인스턴스를 반복해야합니다.

일단 SPList 개체가 있으면 원하는 사용자를 필터링하는 쿼리를 사용하여 GetListItems를 호출해야합니다.

원하는대로 할 수있는 방법입니다.

SharePoint는 전혀 설계되지 않았으며 데이터베이스의 구조가 버전과 업그레이드간에 동일하다는 보장 (실제로는 경고가 있음)이 없으므로 절대로 데이터베이스로 직접 이동하지 않아야합니다. 또한 콘텐츠가 팜의 여러 콘텐츠 데이터베이스에 퍼져있는 경우 한 콘텐츠 데이터베이스에서 실행되는 쿼리가 다른 콘텐츠 데이터베이스에서 기대하는대로 작동한다는 보장이 없습니다.

개체 모델을 반복 할 때 생성 한 SPSite 및 SPWeb 개체를 삭제해야 함을 유의하십시오.

아, 네 명이 400 명이 있지만 나는 30 개의 사이트를 가지고있을 것입니다. 정보는 사이트 당 데이터베이스에서 ... 30 x 400 = 데이터베이스의 12,000 항목으로 반복됩니다.

Answer 4

정말로 잠금이있는 SELECT를 수행하면 안됩니다. 즉, 쿼리에 WITH (NOLOCK)를 추가해야합니다. 시스템의 일부분은 시간 제한에 매우 민감하기 때문에 시스템이 예상하지 못했던 잠금을 시작하면 시스템이 이상하게 보일 수 있습니다.

하지만 실제로는 개체 모델을 통해이 작업을 수행해야합니다. IronPython과 OM을 사용한 실험은 거의 완전히 즐겁습니다.