Wat is het verschil tussen ArcSDE en ruimtelijk ingeschakelde databases?

SDE [ArcSDE] kan verwijzen naar ten minste twee dingen: de organisatie van uw gegevens in de database (het SDE-schema) of een dienst die luistert naar verbindingen van klanten (de SDE-dienst). Over het algemeen gaan ze hand in hand – de SDE-service is gebonden aan een SDE-schema in een database.

In zijn “puurste” (of misschien smerigste) staat verwerkt SDE alle ruimtelijke berekeningen en slaat alleen gegevens in uw database als BLOBs en andere native SQL-typen. Sommige databasefuncties, zoals tekst- of XML-indexering, worden gebruikt om de prestaties te verbeteren, maar over het algemeen “weet” de database niet dat het om ruimtelijke gegevens gaat. Er zijn slechts een aantal tabellen en weergaven en procedures, en ze zijn vol van gegevens en functies.

Met een ruimtelijk ingeschakelde database IS de database zich ervan bewust dat de gegevens een locatie hebben. U kunt dus locatiequerys rechtstreeks in uw SQL-instructies plaatsen. Misschien is dit een goede zaak voor u , het hangt er echt van af wie uw gegevens gebruikt. Als uw gegevensgebruikers vloeiend SQL spreken, is dat geweldig! Als uw dataconsumenten ArcMap vloeiend beheersen, kan het hen waarschijnlijk minder schelen.

Meer recentelijk hebben we de twee kunnen combineren door SDE te gebruiken om te vertalen naar een onderliggend native ruimtelijk type. Bovendien kunnen we “direct connect” gebruiken om de SDE-service te omzeilen en de consumententoepassing (ArcMap, ArcGIS-server, enz.) Rechtstreeks met de database te laten verbinden. Persoonlijk heb ik verschillende niveaus van succes gehad met directe verbindingen.

Voordelen van het gebruik van ArcSDE:

• Naadloze integratie met ESRI-clients
• Goede prestaties
• Sommige onderliggende databasefunctionaliteit kan worden blootgelegd (ruimtelijke weergaven, indexen)

Nadelen van het gebruik van SDE:

• Kan moeilijk te herstellen zijn van beschadigde gegevens
• De licentie is gebonden aan de database
• Geen gemakkelijke toegang tot geometrie zonder gebruik van ESRI-software

Voordelen voor een ruimtelijk ingeschakelde database:

• Gegevens gemakkelijk toegankelijk voor elke SQL-client
• Gegevens kunnen worden beheerd met behulp van bestaande DB-tools (back-up, herstel, analyse)
• Open formaten beschikbaar

Nadelen aan een ruimtelijk ingeschakelde database gebruiken:

• Clients (software) kunnen mogelijk niet rechtstreeks verbinding maken met uw gegevens, en moeten mogelijk inefficiënte protocollen of exportbestanden gebruiken om deze te zien
• Ruimtelijke verwijzingen zijn soms moeilijk toe te passen of consistent te houden.
• Kan leiden tot extra configuratie- of beheeroverhead

Ik heb m of ervaring met gewone SDE, dus er zijn waarschijnlijk meer punten voor de ruimtelijk ingeschakelde database.

Ik hoop dat dit helpt!

Reacties

• U zou inbreuk maken op ESRI-licenties als u de gegevens rechtstreeks benadert en niet via de SDE-service.
• Er is geen inbreuk. ESRI Direct Connect gebruikt geen SDE-service (tenminste aan de serverzijde). Bovendien hebben ze veel artikelen gepubliceerd over het gebruik van PostGres, MSSQL en WKT als het ruimtelijke opslagtype tijdens het gebruik van SDE, waarmee u rechtstreeks met de ruimtelijke gegevens kunt communiceren. En meer dan eens heb ik SDE moeten opschonen door direct toegang te krijgen tot gegevens wanneer deze kapot ging. Een ander voordeel van ruimtelijk ingeschakelde databases is dat de database het werk kan doen in plaats van alle gegevens naar een client te brengen en deze het werk te laten doen.
• @CrazyEnigma: citaat nodig.
• geweldige omschrijving van SDE vs ST Geometry @mwalker Bedankt
• re: ruimtelijke referenties, ik denk dat het het tegenovergestelde is. Ruimtelijke verwijzingen in PostGIS zijn standaard en de SRIDs zijn hetzelfde als EPSG-codes voor toepasselijke SRS. Met SDE, ten minste bij 9.3x, bevatten de SRIDS extensies, enz., Dus u kunt twee verschillende SRIDs hebben voor hetzelfde ruimtelijke referentiesysteem. Dit veroorzaakt problemen als je ruimtelijke SQL wilt gebruiken.

Hier is mijn antwoord in één regel: Gebruik SDE wanneer u multi-user toegang nodig heeft tot uw geospatiale data.

Stel dat u wilt dat meerdere gebruikers uw data bewerken: gebruik SDE. Stel dat u gegevens aan wilt leveren en wilt laten bewerken via internet: gebruik SDE. Als u een kleine winkel bent met één GIS-man, gebruik dan geen SDE.

Als u bent de enige die uw ruimtelijke gegevens gebruikt, SDE is niet voor u. Als u geen bewerking door meerdere gebruikers nodig heeft, is SDE niet voor u. U kunt beter een bestand GeoDatabase gebruiken.

Wat betreft afwegingen … SDE is niet triviaal om op te zetten of te beheren. U moet een RDBMS gebruiken.

SDE is bedoeld voor grotere organisaties waar één database nodig is, maar meerdere gebruikers toegang moeten hebben tot gegevens en deze moeten bijwerken / bewerken.

Reacties

• Ik bedoel, Arc-producten zijn behoorlijk slecht als het gaat om multi-usr-omgevingen. Er schijnen veel dingen te zijn die ' niet kunnen worden gedaan terwijl mensen verbonden zijn. Als prestaties en een robuuste multi-user-omgeving belangrijk zijn, moet het RDBMS beter al het werk laten doen, zonder vuile middleware, alleen dingen vertragen en alles vergrendelen. Maar het ziet er mooi uit, ik moet toegeven, de doos bedoel ik 🙂
• Ik ben het met Nicklas eens. Uw vergelijking is logisch binnen de Arc-wereld, maar SDE is niet geweldig met meerdere gebruikers. Een ruimtelijk ingeschakeld RDBMS zoals PostGIS heeft voordelen op dit gebied. Heeft u ooit geprobeerd een gebruikersrechten te verlenen op een SDE-dataset die iemand anders bekijkt?
• Ja, ik ' ben het probleem tegengekomen dat u ' opnieuw beschrijven met toekenning van privileges. Ik weet niet zeker of het ' nog steeds een probleem is, aangezien ik ' t over een paar jaar een SDE GDB moest beheren. Subsidies mogen niet worden geblokkeerd door sloten. Hoe gaat postgres / postgis om met bewerkingen door meerdere gebruikers?

Tegenwoordig staan de meeste ruimtelijke dbs meervoudige ruimtelijke kolommen in één tabel, terwijl SDE vasthoudt aan één ruimtelijke kolom voor één tabel. Ze hebben ook ruimtelijke gegevens geïntegreerd met hun flexibele en krachtige gegevensbeheertools, waaraan SDE ontbreekt, zoals gebruikersachems, gegevensreplicatie, SQL-ondersteuning enz.

ESRI SDEBinary is de snelste. Als het gaat om ST_GEOMETRY, levert SDE mogelijk niet de beste prestaties.