Relations SQL Server dans ArcSDE?

J'exécute ArcSDE 10 avec SQL Server 2008 R2 Standard Edition. Je suis nouveau sur SDE et SQL Server, mais je comprends que SQL Server a la capacité de créer des relations entre les tables et de maintenir certaines règles d'intégrité référentielle.

ArcGIS possède des classes de relations qui agissent de manière similaire, mais une classe de relations n'a pas toutes les fonctionnalités des relations SQL et n'entraîne pas de relation SQL dans la base de données ArcSDE.

Est-il possible de créer des classes de relations dans ArcGIS pour une base de données ArcSDE et de créer des relations pour les mêmes tables dans SQL Server? Ce faisant, je pourrai utiliser ces relations, que je travaille avec les données dans ArcGIS ou dans SQL Server Management Studio. Les deux types de relations entreront-ils en conflit ou entraveront-ils autrement les performances?

— Brian
source

C'est juste une supposition (c'est pourquoi ce n'est pas une réponse) mais je parierais que l'ajout de relations pourrait provoquer des conflits à moins que vous ne soyez très prudent. Sur une note importante, si vous versionnez vos tables, vous ne voulez pas les lire du côté SQL, seulement du côté SIG. La lecture du côté SQL ne montre que la version la plus ancienne des données (et non les modifications qui constituent les versions).

— Michael Todd

@MichaelTodd - Merci pour votre réponse. J'ai entendu parler des problèmes d'accès aux données versionnées via SQL Server. Cependant, j'ai également entendu que cela est possible en utilisant des vues multi-versions. Je suis toujours un débutant avec ce genre de choses, donc je ne sais pas exactement ce que cela signifie, mais ce que je retiens c'est que c'est possible. Je constate simplement qu'en ce qui concerne la gestion des données dans ArcSDE, ArcGIS est le maillon le plus faible.

— Brian

Oui, une vue multi-version fonctionne, mais elle est beaucoup plus lente. Nous sommes passés de requêtes de moins d'une seconde à des requêtes de 4 secondes lorsque nous sommes passés aux MVV (ce qui ne ressemble pas beaucoup, mais le décalage était très perceptible en interne ainsi qu'aux clients externes).

— Michael Todd

SDE et SQL ne sont pas vraiment amis. Ils ne coopèrent pas très bien. SDE utilise sql mais ne tire pas parti de toutes ses capacités natives. Une relation configurée dans sde n'est pas reflétée dans SQL. La modification des tables de classes d'entités gérées par SDE, la modification des schémas de table en dehors du catalogue, ainsi que de nombreuses autres tâches, entraîneront le fonctionnement de SDE. Compte tenu de ces antécédents, je laisserais les relations à SDE si vous essayez de relier des informations sur la classe d'entités. Si vous utilisez des tables régulières, coupez sde et utilisez sql natif.

Il n'y a aucune référence pour cela autre que mes propres expériences. S'il s'agit de documents non sourcés, contestez-les ou supprimez-les.

— Steve
source