<\/HEAD>
Si vous avez utilisé un composant de la technologie d'entreprise ESRI, vous avez rencontré l'identifiant unique Global ID omniprésent. <\/P>
<\/P>
Probablement en cliquant droit sur une classe d'entités et en sélectionnant "Ajouter des Global ID" puis en l'oubliant. <\/P>
<\/P>
Ce post est plutôt une diatribe contre les GUID aléatoires<\/STRONG> qu'autre chose. Vous avez certainement besoin d'une colonne GUID si vous répliquez des données ou effectuez des modifications déconnectées. <\/P><\/P>Je les déteste absolument ! Mon problème avec la colonne Global ID est la façon dont ESRI l'implémente. Non seulement elle est unique (comme elle devrait l'être), mais elle est aléatoire. J'utilise les données SDE\/SQL bien plus que pour afficher des points sur une carte. Nous relions ces données à d'autres applications, telles que celles qui gèrent les données non SIG attachées à ce point sur la carte. Dans certaines applications, j'ai des dizaines de relations et de tables liées à cette "table SIG". Tout cela réalisé grâce à l'utilisation astucieuse de la colonne Global ID comme moyen de relier les données non SIG aux données SIG. Bien sûr, je pourrais utiliser autre chose, mais je n'aurais pas un titre de blog aussi accrocheur. <\/P><\/P>Mon problème avec la colonne Global ID est son caractère aléatoire. Imaginez une classe d'entités avec 10 000 (j'en ai quelques-unes avec 500 000) points. Ce sont 10 000 GUID aléatoires. Maintenant, liez cette table en utilisant cette colonne, ou triez-la, ou filtrez-la. Mettez un index clusterisé (ou non clusterisé) sur la colonne Global ID. Ces GUID aléatoires ralentissent vraiment les choses, n'est-ce pas ? <\/P><\/P>Voyons comment cela fonctionne. Lorsque vous faites ce clic droit et oubliez, SDE ajoute une contrainte au champ Global ID : <\/P><\/P>ALTER TABLE [dbo].[TEST] ADD DEFAULT ('{00000000-0000-0000-0000-000000000000}') FOR [GlobalID]<\/PRE><\/P>Chaque nouvelle entité ajoutée à cette classe d'entités appelle une procédure stockée qui prend un newid SQL (valeur GUID) et le convertit en chaîne de caractères. <\/P><\/P>CREATE PROCEDURE [dbo].[next_globalid]
@guid NVARCHAR(38) OUTPUT
AS SET NOCOUNT ON
BEGIN
SELECT @guid = '{' + CAST (NEWID() AS NVARCHAR(38)) + '}'
END
GO<\/PRE><\/P>Mais que se passerait-il si nous pouvions rendre le GUID séquentiel et non aléatoire, tout en restant unique ? Une telle chose existe, et une recherche sur internet vous révélera un débat très animé avec de nombreuses opinions fermement ancrées pour ou contre les GUID séquentiels. Pas ici....<\/P><\/P>Essayer de modifier la procédure stockée pour utiliser par défaut le SQL newSEQUENTIALID ne fonctionne pas...<\/P><\/P>CREATE PROCEDURE [dbo].[next_globalid]
@guid NVARCHAR(38) OUTPUT
AS SET NOCOUNT ON
BEGIN
SELECT @guid = '{' + CAST (NEWSEQUENTIALID() AS NVARCHAR(38)) + '}'
END
GO
La fonction intégrée newsequentialid() ne peut être utilisée que dans une expression DEFAULT pour une colonne de type 'uniqueidentifier' dans une instruction CREATE TABLE ou ALTER TABLE. Elle ne peut pas être combinée avec d'autres opérateurs pour former une expression scalaire complexe.<\/PRE>Voici donc ma solution : mettre un trigger entre la table delta et la table de base et ignorer la procédure stockée ESRI qui écrit le GUID aléatoire. Nous pouvons faire cela avec un trigger instead of insert et en changeant la valeur par défaut de la colonne Global ID. <\/P><\/P>Premièrement : <\/P><\/P>ALTER TABLE [dbo].[TEST] DROP CONSTRAINT [DF__TEST__GlobalID__65FFA925]
GO
ALTER TABLE [dbo].[TEST] ADD CONSTRAINT [DF__TEST__GlobalID__65FFA925] DEFAULT (newsequentialid()) FOR [GlobalID]
GO<\/PRE><\/P>Puis : <\/P><\/P>CREATE TRIGGER [dbo].[TEST_GLOBAL_ID]
ON [dbo].[TEST]
INSTEAD OF INSERT NOT FOR REPLICATION
AS BEGIN
SET NOCOUNT ON;
INSERT [TEST](
OBJECTID, SOMEFIELD, SHAPE, LON, LAT, QuadName, Watershed, County, State, PARKDISTRICT, ELEVATION, StreamName, RiverOrder
)
SELECT
OBJECTID, a.SOMEFIELD, a.SHAPE, a.LON, a.LAT, a.QuadName, a.Watershed, a.County, a.State, a.PARKDISTRICT, a.ELEVATION, a.StreamName, a.RiverOrder
From
(SELECT
OBJECTID, SOMEFIELD, SHAPE, LON, LAT, QuadName, Watershed, County, State, PARKDISTRICT, ELEVATION, StreamName, RiverOrder
FROM inserted)
AS a
;
end
GO<\/PRE>Ajoutez quelques nouveaux points et<\/P><\/P>SELECT
[GlobalID]
FROM [FISH].[dbo].[TEST]<\/PRE><\/P><\/P>GlobalID
C10EB116-8B14-45AB-924D-0C734E5AB5B6
61AE23FA-F02D-45C1-991D-571B77592014
0695789D-35A7-4BE4-B5F6-5EAF68D2A50B
5A20B628-6048-4D48-8380-AC005A0E70EC
CF52E6DE-5F60-456E-9DEF-C006D9BBD348
58F80A07-F8A8-4D62-BBB3-D012EA781F0C
5E7B9C91-2891-E411-B57C-E41F134196DA
BE30E498-2891-E411-B57C-E41F134196DA
BF30E498-2891-E411-B57C-E41F134196DA
C030E498-2891-E411-B57C-E41F134196DA
C130E498-2891-E411-B57C-E41F134196DA
38C5A6F2-60FF-4C39-BF37-F7AFCBDFDE90<\/PRE><\/P>Notez comment mes nouveaux points (commençant à la ligne 08 et finissant à 12) contiennent des ID séquentiels. J'utilise un trigger instead of plutôt qu'un trigger after update ici parce que je veux que cela se produise AVANT que cela n'atteigne la table de base. <\/P><\/P>Malheureusement, cette "modification" n'est pas très robuste et ne peut pas être utilisée si vos données sont versionnées SANS déplacer les modifications vers la base ou pas du tout versionnées (comme nécessaire lors de l'utilisation de Collector for ArcGIS). Non discuté ici est ma raison très convaincante d'utiliser le champ Global ID dans certaines des applications non SIG qui utilisent ces données. Considérons cela comme du "bricolage". ESRI a sûrement une très bonne raison d'implémenter la valeur par défaut du Global ID comme ils le font, et ce post suscitera sûrement un débat animé et des commentaires. <\/P><\/P>Cela ajouté au trigger after update\insert présenté dans Hey Neighbor? What's Your Value?<\/A> aboutira à une classe d'entités propre où presque tous les attributs sont automatiquement remplis et vos Global ID sont ordonnés. <\/P><\/P>
<\/P>
</ P >< P >Il s'agit d'un blog personnel qui ne recommande ni n'endosse ni ne soutient les méthodes décrites ci-dessus. La modification des données via SQL en dehors de la pile logicielle ESRI n'est bien sûr pas prise en charge et ne doit pas être appliquée à une base de données de production sans une compréhension approfondie et un plan de reprise après sinistre.<\/EM></ P >< /BODY >< /HTML >
