Hva er forskjellen mellom ArcSDE og romlig aktiverte databaser?

SDE [ArcSDE] kan referere til minst to ting: organisering av dataene dine i databasen (SDE-skjemaet) eller en tjeneste som lytter etter tilkoblinger fra klienter (SDE-tjenesten). Vanligvis går de hånd i hanske – SDE-tjenesten er bundet til et SDE-skjema i en database.

I sin «reneste» (eller kanskje skitneste) tilstand håndterer SDE alle romlige beregninger, og lagrer bare data i databasen din som BLOB og andre innfødte SQL-typer. Noen databasefunksjoner, som tekst eller XML-indeksering, brukes for å forbedre ytelsen, men generelt vet ikke databasen at den serverer romlige data. Det er bare en haug med tabeller og visninger og prosedyrer, og de er fulle av data og funksjoner.

Med en romlig aktivert database ER databasen klar over at dataene har en plassering. Så du kan plassere spørsmål direkte i SQL-setningene dine. Kanskje dette er en god ting for deg , avhenger det virkelig av hvem som bruker dataene dine. Hvis datakonsumentene dine er flytende i SQL, er det flott! Hvis datakonsumentene dine er flytende i ArcMap, kan de sannsynligvis bry seg mindre.

Mer nylig har vi vært i stand til å blande de to ved å bruke SDE til å oversette til en underliggende innfødt romlig type. Videre kan vi bruke «direktekobling» for å omgå SDE-tjenesten og bare ha forbrukerapplikasjonen (ArcMap, ArcGIS-server osv.) Koblet direkte til databasen. Personlig har jeg hatt varierende suksessnivåer med direkte forbindelser.

Fordeler ved bruk av ArcSDE:

• Sømløs integrasjon med ESRI-klienter
• God ytelse
• Noen underliggende databasefunksjonaliteter kan bli utsatt (romlige visninger, indekser)

Ulemper ved bruk av SDE:

• Kan være vanskelig å gjenopprette fra ødelagte data
• Lisensen er bundet til databasen
• Ingen enkel tilgang til geometri uten å bruke ESRI-programvare

Fordeler med en romlig aktivert database:

• Data enkelt tilgjengelig for alle SQL-klienter
• Data kan administreres ved hjelp av eksisterende DB-verktøy (sikkerhetskopiering, gjenoppretting, analyse)
• Åpne formater tilgjengelig

Ulemper med ved hjelp av en romlig aktivert database:

• Klienter (programvare) kan kanskje ikke koble direkte til dataene dine, og de må kanskje bruke ineffektive protokoller eller eksport for å se dem
• Romlige referanser er noen ganger vanskelige å bruke eller holde konsistente
• Kan medføre ekstra konfigurasjon eller administrasjonsomkostninger

Jeg har m malmopplevelse med vanlig SDE, så det er sannsynlig flere poeng for den romlig aktiverte databasen.

Håper dette hjelper!

Kommentarer

• Du vil krenke ESRI-lisensiering hvis du får tilgang til dataene direkte og ikke gjennom SDE-tjenesten.
• Det er ingen overtredelse. ESRI direct connect bruker ingen SDE-tjeneste (i det minste ved serverens slutt). Videre har de publisert mange artikler om bruk av PostGres, MSSQL og WKT som romlig lagringstype mens du bruker SDE, som lar deg kommunisere med romlige data direkte. Og mer enn en gang har jeg måttet rydde opp i SDE ved å få tilgang til data direkte når den brøt. En annen fordel med romlig aktiverte databaser er at databasen kan gjøre jobben i stedet for å bringe alle dataene inn i en klient og få den til å gjøre jobben.
• @CrazyEnigma: sitering nødvendig.
• flott beskrivelse av SDE vs ST Geometry @mwalker Takk
• re: romlige referanser, jeg tror at det er motsatt. Romlige referanser i PostGIS er standard, og SRIDene er de samme som EPSG-koder for gjeldende SRS. Med SDE, minst 9,3x, inneholder SRIDS-utstrekninger osv., Slik at du kan ha to forskjellige SRID-er for samme romlige referansesystem. Dette forårsaker problemer hvis du vil bruke romlig SQL.

Her er svaret mitt på en linje: Bruk SDE når du trenger tilgang for flere brukere til dine geodata.

La oss si at du vil at flere brukere skal redigere dataene dine: bruk SDE. La oss si at du vil servere data til og la dem redigeres over nettet: bruk SDE. Hvis du er en liten butikk, med en GIS-fyr, ikke bruk SDE.

Hvis du er den eneste personen som bruker dine geodata, SDE er ikke noe for deg. Hvis du ikke trenger redigering av flere brukere, er SDE ikke noe for deg. Det er bedre å bruke en GeoDatabase-fil.

Når det gjelder kompromisser … SDE er ikke trivielt å sette opp eller administrere. Du må bruke en RDBMS.

SDE er ment for større organisasjoner der en database er nødvendig, men flere brukere trenger tilgang til og oppdaterer / redigerer data.

Kommentarer

• Jeg mener Arc-produkter er ganske dårlige når det gjelder miljøer med flere brukere. Det ser ut til å være mange ting som ' ikke kan gjøres mens folk er tilkoblet. Hvis ytelse og robust flerbrukermiljø er viktig, må RDBMS gjøre alt arbeidet som ikke involverer noe skittent mellomutstyr, bare å bremse ting og sette låser på alt. Men det ser fancy ut, jeg må innrømme, boksen mener jeg 🙂
• Jeg er enig med Nicklas. Din sammenligning er fornuftig i lysbuen, men SDE er ikke bra for flere brukere. En romlig aktivert RDBMS som PostGIS har fordeler på denne arenaen. Har du noen gang prøvd å gi brukerrettigheter til et SDE-datasett som noen andre ser på?
• Ja, jeg ' har kjørt inn i problemet du ' beskriver og gir rettigheter. Ikke sikker på om det ' fortsatt er et problem da jeg ikke har ' t måtte administrere en SDE GDB om et par år. Tilskudd bør ikke blokkeres av låser. Hvordan håndterer postgres / postgis redigering av flere brukere?

I dag tillater de fleste romlige dbs flere romlige kolonner i en tabell, mens SDE holder seg til en romlig kolonne for en tabell. De har også romlige data integrert med sine fleksible og kraftige verktøy for dataadministrasjon, som SDE mangler, for eksempel brukerpakker, replikering av data, SQL-støtte og så videre.

ESRI SDEBinary er den raskeste. Hvis det gjelder ST_GEOMETRY, har SDE kanskje ikke den beste ytelsen.