Sharepoint: SQL pour rechercher tous les documents créés / modifiés par un utilisateur

Question

Je recherche une requête qui fonctionnera sous Sharepoint 2003 pour afficher tous les documents créés / touchés par un ID utilisateur donné.

J'ai trouvé des tables avec les documents (Docs) et des tables pour les utilisateurs (UserInfo, UserData) mais la relation entre les deux semble un peu étrange - il y a 99 000 enregistrements dans notre table userdata, et 12 000 enregistrements dans userinfo - nous avons 400 utilisateurs!

Je suppose que je m'attendais à une relation simple "1 à plusieurs" avec une table d'utilisateurs ayant 400 enregistrements et la reliant à la table de documents, mais je vois que ce n'est pas le cas.

Toute aide serait appréciée.

Modifier: Merci Bjorn, J'ai traduit cette requête dans la structure Sharepoint 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

Cela me donne une liste de sitesid / listid / tp_id, je devrai voir si je peux les retracer vers un nom de fichier / chemin. Tous: toute aide supplémentaire est toujours appréciée!

Answer 1

Je n'ai jamais examiné la base de données dans SharePoint 2003, mais en 2007, UserInfo est connecté à Sites, ce qui signifie que chaque utilisateur a une ligne dans UserInfo pour chaque collection de sites (ou le concept équivalent de 2003). Donc, pour identifier quel utilisateur avez-vous besoin de l'identifiant de site et de l'identifiant d'utilisateur sur ce site? En 2007, je commencerais par quelque chose comme ceci:

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

Mise à jour: comme d’autres écrivent ici, il n’est pas recommandé d’aller directement dans la base de données SharePoint, mais je dirais qu’il faut utiliser sa tête et faire attention. Les mises à jour sont non majuscules, mais la sélection dépend du contexte.

Answer 2

NE PAS QUERTER LA BASE DE DONNÉES SHAREPOINT DIRECTEMENT!

Je me demande si j'ai bien expliqué cela? :)

Vous devez vraiment examiner le modèle d'objet disponible en C #, vous devez obtenir une instance SPSite pour un SiteCollection, puis effectuer une itération sur les instances SPList qui appartiennent aux objets SPSite et SPWeb.

Une fois que vous avez l'objet SPList, vous devez appeler GetListItems à l'aide d'une requête qui filtre pour l'utilisateur que vous souhaitez.

C’est la manière recommandée de faire ce que vous voulez.

Vous ne devez jamais accéder directement à la base de données, car SharePoint n’est pas conçu pour cela et il n’ya aucune garantie (en fait, il existe un avertissement spécifique) selon laquelle la structure de la base de données sera la même entre les versions et les mises à niveau, et En outre, lorsque le contenu est réparti sur plusieurs bases de données de contenu dans une batterie de serveurs, rien ne garantit qu’une requête exécutée sur une base de données de contenu produira ce que vous attendez d’une autre base de données de contenu.

Lorsque vous examinez le modèle d'objet pour l'itération, notez également que vous devrez disposer () des objets SPSite et SPWeb que vous créez.

Oh, et oui vous pouvez avoir 400 utilisateurs, mais je parierais que vous avez 30 sites. Les informations sont répétées dans la base de données par site ... 30 x 400 = 12 000 entrées dans la base de données.

Answer 3

Si vous envisagez d'utiliser cette requête dans Sharepoint, vous devez savoir que créer des vues sur la base de données de contenu ou interroger directement la base de données semble être un gros no-no. Une solution de contournement pourrait consister en un code personnalisé qui parcourt le modèle d’objet et écrit les résultats dans votre propre base de données. Cela peut être basé sur un minuteur ou sur un déclencheur d’événements.

Answer 4

Vous ne devriez vraiment pas faire de SELECT avec Locks, c’est-à-dire ajouter WITH (NOLOCK) à vos requêtes. Certaines parties du système sont très sensibles au timeout et si vous commencez à introduire des verrous auxquels le système ne s'attendait pas, vous pouvez voir le système paniquer.

Mais en réalité, vous devriez le faire via le modèle objet. Déranger avec quelque chose comme IronPython et les expérimentations avec l'OM sont presque carrément agréables.