Je ne sais pas si quelqu'un d'autre est du genre à "lire en avance". Je passais en revue quelque chose qu'un employé d'ESRI du côté base de données que je connais a envoyé concernant l'enthousiasme autour de la gestion des versions de branches. Il est vrai que cela ouvre de belles perspectives et je peux voir des opportunités potentielles à l'utiliser. Vous pouvez tout lire dans ces 2 articles :<\/P>
<\/P>
Introduction à Branch Versioning<\/A><\/P>Préparer le terrain<\/A><\/P><\/P>Comme à mon habitude, il ne suffit pas d'avoir le résumé, j'ai dû aller sous le capot. Là, vous trouverez quelques pièges très intéressants du côté Oracle. L'impossibilité d'utiliser des tables compressées n'est probablement pas idéale pour certains de vos DBA mais reste acceptable. L'impossibilité d'utiliser le type de géométrie natif d'Oracle est ce qui posera problème. Si vous êtes comme nous, nous avons une multitude d'autres systèmes qui ne sont pas pilotés par ESRI et qui utilisent le SDO_GEOMETRY natif. Bien que ce ne soit pas un obstacle majeur et que vous puissiez tout faire fonctionner en ST_GEOM et convertir une fois prêt à diffuser des formats de données standardisés dans toute l'agence, si vous utilisez Roads & Highways et êtes déjà déployé en production avec le SDO_GEOM, cela pourrait devenir intéressant.<\/P><\/P>Je ne sais pas si R&H finira par utiliser branch versioning ou non.<\/P>Je ne sais pas si ESRI a l'intention que branch versioning fonctionne un jour avec SDO_GEOM ou non.<\/P>Je peux dire que c'est quelque chose à garder à l'esprit et cela pourrait influencer les décisions que vous prendrez pour R&H à l'avenir, surtout lorsque vous déciderez de passer à Pro, ce qui semble être le moment idéal pour vous préparer au mieux à ce type de capacités à long terme.<\/P><\/P>Voici l'article que vous voudrez consulter si vous voulez aller sous le capot :<\/P>Enregistrer les données comme versionnées<\/A><\/P><\/BODY><\/HTML>
Comme à mon habitude, il ne suffit pas d'avoir le résumé, j'ai dû aller sous le capot. Là, vous trouverez quelques pièges très intéressants du côté Oracle. L'impossibilité d'utiliser des tables compressées n'est probablement pas idéale pour certains de vos DBA mais reste acceptable. L'impossibilité d'utiliser le type de géométrie natif d'Oracle est ce qui posera problème. Si vous êtes comme nous, nous avons une multitude d'autres systèmes qui ne sont pas pilotés par ESRI et qui utilisent le SDO_GEOMETRY natif. Bien que ce ne soit pas un obstacle majeur et que vous puissiez tout faire fonctionner en ST_GEOM et convertir une fois prêt à diffuser des formats de données standardisés dans toute l'agence, si vous utilisez Roads & Highways et êtes déjà déployé en production avec le SDO_GEOM, cela pourrait devenir intéressant.<\/P>
Je ne sais pas si R&H finira par utiliser branch versioning ou non.<\/P>
Je ne sais pas si ESRI a l'intention que branch versioning fonctionne un jour avec SDO_GEOM ou non.<\/P>
Je peux dire que c'est quelque chose à garder à l'esprit et cela pourrait influencer les décisions que vous prendrez pour R&H à l'avenir, surtout lorsque vous déciderez de passer à Pro, ce qui semble être le moment idéal pour vous préparer au mieux à ce type de capacités à long terme.<\/P>
Voici l'article que vous voudrez consulter si vous voulez aller sous le capot :<\/P>
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
