Vad är skillnaden mellan ArcSDE och rumsligt aktiverade databaser?

SDE [ArcSDE] kan referera till åtminstone två saker: organisationen av dina data i databasen (SDE-schemat) eller en tjänst som lyssnar på anslutningar från klienter (SDE-tjänsten). Generellt går de hand i handske – SDE-tjänsten är bunden till ett SDE-schema i en databas.

I sitt ”renaste” (eller kanske smutsigaste) tillstånd hanterar SDE alla rumsliga beräkningar och lagrar bara data i din databas som BLOB och andra inbyggda SQL-typer. Vissa databasfunktioner, som text eller XML-indexering, används för att förbättra prestanda, men i allmänhet vet databasen inte att den serverar rumslig data. Det finns bara en massa tabeller och vyer och procedurer, och de är fulla av data och funktioner.

Med en rumsligt aktiverad databas är databasen medveten om att data har en plats. Så du kan lägga platsfrågor direkt i dina SQL-uttalanden. Det kanske är bra för dig , det beror verkligen på vem som konsumerar dina data. Om dina datakonsumenter är flytande i SQL är det bra! Om dina datakonsumenter är flytande i ArcMap kan de förmodligen bry sig mindre.

På senare tid har vi kunnat blanda de två genom att använda SDE för att översätta till en underliggande lokal typ av rum. Dessutom kan vi använda ”direktanslutning” för att kringgå SDE-tjänsten och bara ha konsumentapplikationen (ArcMap, ArcGIS-server osv.) Anslut direkt till databasen. Personligen har jag haft olika nivåer av framgång med direktanslutningar.

Fördelar med att använda ArcSDE:

• Sömlös integration med ESRI-klienter
• Bra prestanda
• Vissa underliggande databasfunktioner kan exponeras (rumsliga vyer, index)

Nackdelar med att använda SDE:

• Kan vara svårt att återställa från skadade data
• Licensen är bunden till databasen
• Ingen enkel åtkomst till geometri utan att använda ESRI-programvara

Fördelar med en rumsligt aktiverad databas:

• Data enkelt tillgänglig för alla SQL-klienter
• Data kan hanteras med hjälp av befintliga DB-verktyg (säkerhetskopiering, återställning, analys)
• Öppna format tillgängliga

Nackdelar med använder en rumsligt aktiverad databas:

• Klienter (programvara) kanske inte kan ansluta direkt till dina data och kan behöva använda ineffektiva protokoll eller export för att se den
• Spatiala referenser är ibland svåra att tillämpa eller hålla konsekventa
• Kan medföra extra konfiguration eller administrationsoverhead

Jag har m malmupplevelse med vanlig SDE så det finns sannolikt fler poäng för den rumsligt aktiverade databasen.

Hoppas det hjälper!

Kommentarer

• Du skulle bryta mot ESRI-licensiering om du får åtkomst till data direkt och inte via SDE-tjänsten.
• Det finns ingen överträdelse. ESRI direct connect använder ingen SDE-tjänst (åtminstone vid serverns slut). Dessutom har de publicerat många artiklar om att använda PostGres, MSSQL och WKT som den rumsliga lagringstypen medan du använder SDE, vilket gör att du kan kommunicera med rumsliga data direkt. Och mer än en gång har jag varit tvungen att städa upp SDE genom att komma åt data direkt när den bröt. En annan fördel för rumsaktiverade databaser är att databasen kan göra jobbet snarare än att ta med all information till en klient och få den att göra jobbet.
• @CrazyEnigma: citat behövs.
• bra beskrivning av SDE vs ST Geometry @mwalker Tack
• re: rumsliga referenser, jag tror att det är tvärtom. Rumsliga referenser i PostGIS är standard och SRID: erna är desamma som EPSG-koder för tillämpliga SRS. Med SDE, åtminstone 9,3x, innehåller SRIDS omfattningar etc. så att du kan ha två olika SRID för samma rumsliga referenssystem. Detta orsakar problem om du vill använda rumslig SQL.

Här är mitt svar på en rad: Använd SDE när du behöver fleranvändaråtkomst till dina geospatiala data.

Låt oss säga att du vill att flera användare ska redigera dina data: använd SDE. Låt oss säga att du vill skicka data till och låta det redigeras via webben: använd SDE. Om du är en liten butik med en GIS-kille, använd inte SDE.

Om du är den enda personen som använder dina rumsliga data, SDE är inte något för dig. Om du inte behöver redigera flera användare är SDE inte för dig. Det är bättre att du använder en fil GeoDatabase.

När det gäller kompromisser … SDE är inte trivialt att konfigurera eller hantera. Du måste använda en RDBMS.

SDE är avsedd för större organisationer där en databas behövs men flera användare behöver komma åt och uppdatera / redigera data.

Kommentarer

• Jag menar att Arc-produkter är ganska dåliga när det gäller miljöer med flera användare. Det verkar finnas många saker som ' inte kan göras medan människor är anslutna. Om prestanda och robust fleranvändarmiljö är viktigt måste RDBMS göra allt det arbete som inte involverar något smutsigt mellanvaror, bara sakta ner saker och låsa allt. Men det ser snyggt ut jag måste erkänna, rutan menar jag 🙂
• Jag håller med Nicklas. Din jämförelse är meningsfull inom Arc-världen, men SDE är inte bra för flera användare. En rumsligt aktiverad RDBMS som PostGIS har fördelar i denna arena. Har du någonsin försökt bevilja en användarrättighet till en SDE-datamängd som någon annan tittar på?
• Ja, jag ' har stött på problemet du ' beskrivs med beviljande av behörigheter. Inte säker på om det ' fortfarande är ett problem eftersom jag inte har ' t var tvungen att administrera en SDE GDB på ett par år. Bidrag bör inte blockeras av lås. Hur hanterar postgres / postgis redigering av flera användare?

Numera tillåter de flesta rumsliga dbs flera rumsliga kolumner i en tabell, medan SDE håller fast vid en rumslig kolumn för en tabell. De har också rumsliga data integrerade med sina flexibla och kraftfulla datahanteringsverktyg, som SDE saknar, såsom användarsachem, datareplikering, SQL-support och etc.

ESRI SDEBinary är den snabbaste. Om det gäller ST_GEOMETRY kanske SDE inte har bäst prestanda.