<\/HEAD>
Pokud jste použili jakoukoli součást ESRI enterprise technologie, určitě jste narazili na všudypřítomný jedinečný identifikátor Global ID. <\/P>
<\/P>
Pravděpodobně tak, že jste klikli pravým tlačítkem na feature class a vybrali „Add Global ID's“ a pak na to zapomněli. <\/P>
<\/P>
Tento příspěvek je spíše výlevem a výkřikem proti náhodným <\/STRONG>GUID než čemukoli jinému. Určitě potřebujete sloupec GUID, pokud replikujete data nebo provádíte odpojené úpravy. <\/P><\/P>Prostě je naprosto nesnáším! Můj problém se sloupcem Global ID je způsob, jakým ho ESRI implementuje. Není jen jedinečný (jak by měl být), ale také náhodný. Používám SDE\/SQL data pro mnohem víc než jen zobrazování teček na mapě. Propojujeme tato data s jinými aplikacemi, například těmi, které spravují ne-GIS data připojená k té tečce na mapě. V některých aplikacích mám desítky vztahů a tabulek navázaných na tu "GIS tabulku". Vše je dosaženo šikovným využitím sloupce Global ID jako způsobu propojení ne-GIS dat s GIS daty. Jistě, mohl bych použít něco jiného, ale pak bych neměl tak poutavý název blogového příspěvku. <\/P><\/P>Můj problém se sloupcem Global ID je jeho náhodnost. Představte si feature class s 10 000 (mám několik s 500 000) body. To je 10 000 náhodných GUID. Teď se na tu tabulku odkažte pomocí toho sloupce, nebo ji seřaďte, nebo filtrujte. Dejte na sloupec Global ID clusterovaný (nebo neclusterovaný) index. Ty náhodné GUIDy opravdu zpomalují věci, že? <\/P><\/P>Pojďme se podívat, jak to funguje. Když provedete to kliknutí pravým tlačítkem a zapomenete na to, SDE přidá omezení do pole Global ID: <\/P><\/P>ALTER TABLE [dbo].[TEST] ADD DEFAULT ('{00000000-0000-0000-0000-000000000000}') FOR [GlobalID]<\/PRE><\/P>Každý nový prvek přidaný do té feature class volá uloženou proceduru, která vezme SQL newid (hodnotu GUID) a převede ji na řetězec. <\/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>Ale co kdybychom mohli udělat GUID sekvenční a ne náhodný, ale stále jedinečný? Taková věc existuje a hledání na internetu vám odhalí velmi vášnivou debatu s mnoha názory pevně zakořeněnými pro nebo proti sekvenčním GUIDům. Tady o tom není řeč....<\/P><\/P>Snažit se změnit SP tak, aby defaultoval na SQL newSEQUENTIALID nefunguje...<\/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
Funkce newsequentialid() může být použita pouze v DEFAULT výrazu pro sloupec typu 'uniqueidentifier' ve CREATE TABLE nebo ALTER TABLE příkazu. Nelze ji kombinovat s jinými operátory k vytvoření složitého skalárního výrazu.<\/PRE>Takže tady je moje řešení: Vložte trigger mezi delta a základní tabulku a ignorujte ESRI SP, který zapisuje náhodný GUID. Můžeme to udělat pomocí instead of insert triggeru a změnou defaultu sloupce Global ID. <\/P><\/P>Nejprve: <\/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>Pak: <\/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>Přidejte pár nových bodů a<\/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>Všimněte si jak mé nové body (začínající na řádku 08 a končící na 12) obsahují sekvenční ID. Používám zde instead of místo after update triggeru protože chci aby se to stalo PŘED tím než to zasáhne základní tabulku. <\/P><\/P>Bohužel tato „změna“ není příliš robustní a nelze ji použít pokud jsou vaše data verzovaná BEZ přesunu úprav do základní tabulky nebo vůbec nejsou verzovaná (což potřebujete při použití Collector for ArcGIS). Také zde není diskutován můj velmi přesvědčivý důvod pro použití pole Global ID v některých ne-GIS aplikacích používajících tato data. Zařaďme to do kategorie „hrátky“. Jsem si jistý že ESRI má velmi dobrý důvod implementovat default Global ID tak jak to dělají a tento příspěvek jistě vyvolá vášnivou debatu a komentáře. <\/P><\/P>Toto spolu s after update\insert triggerem prezentovaným v Hey Neighbor? What's Your Value?<\/A> povede k pěkné upravené feature class kde téměř všechny atributy budou automaticky vyplněny a vaše Global ID budou uspořádána. <\/P><\/P>
<\/P>
