Hvad er forskellen mellem ArcSDE og rumligt aktiverede databaser?

SDE [ArcSDE] kan mindst henvise til to ting: organisering af dine data i databasen (SDE-skemaet) eller en tjeneste, der lytter efter forbindelser fra klienter (SDE-tjenesten). Generelt går de hånd i handske – SDE-tjenesten er bundet til et SDE-skema i en database.

I sin “reneste” (eller måske beskideste) tilstand håndterer SDE alle de geografiske beregninger og gemmer kun data i din database som BLOBer og andre native SQL-typer. Nogle databasefunktioner, som tekst eller XML-indeksering, bruges til at forbedre ydeevnen, men generelt ved databasen ikke, at den serverer geodata. Der er bare en masse tabeller og visninger og procedurer, og de er fulde af data og funktioner.

Med en rumligt aktiveret database ER databasen klar over, at dataene har en placering. Så du kan placere placeringsforespørgsler lige ind i dine SQL-sætninger. Måske er det en god ting for dig , det afhænger virkelig af, hvem der forbruger dine data. Hvis dine dataforbrugere er flydende i SQL, er det godt! Hvis dine dataforbrugere er flydende i ArcMap, kan de sandsynligvis være mindre interesserede.

For nylig har vi været i stand til at blande de to ved at bruge SDE til at oversætte til en underliggende lokal rumtype. Desuden kan vi bruge “direkte forbindelse” til at omgå SDE-tjenesten og bare få forbrugerapplikationen (ArcMap, ArcGIS-server osv.) Til at oprette forbindelse direkte til databasen. Personligt har jeg haft forskellige niveauer af succes med direkte forbindelser.

Fordele ved at bruge ArcSDE:

• Problemfri integration med ESRI-klienter
• God ydeevne
• Nogle underliggende databasefunktioner kan blive eksponeret (rumlige visninger, indekser)

Ulemper ved at bruge SDE:

• Kan være vanskeligt at gendanne fra beskadigede data
• Licensen er bundet til databasen
• Ingen let adgang til geometri uden brug af ESRI-software

Fordele ved en rumligt aktiveret database:

• Data let tilgængelig for enhver SQL-klient
• Data kan administreres ved hjælp af eksisterende DB-værktøjer (backup, gendannelse, analyse)
• Tilgængelige åbne formater

Ulemper ved ved hjælp af en rumligt aktiveret database:

• Klienter (software) kan muligvis ikke oprette forbindelse direkte til dine data og skal muligvis bruge ineffektive protokoller eller eksport for at se dem
• Rumlige referencer er undertiden svære at anvende eller holde konsistente
• Kan medføre ekstra konfiguration eller administrationsomkostninger

Jeg har m malmoplevelse med almindelig SDE, så der er sandsynligvis flere point for den rumligt aktiverede database.

Håber dette hjælper!

Kommentarer

• Du overtræder ESRI-licens, hvis du får adgang til dataene direkte og ikke gennem SDE-tjenesten.
• Der er ingen overtrædelse. ESRI direct connect bruger ingen SDE-tjeneste (i det mindste i serverenden). Desuden har de offentliggjort mange artikler om brug af PostGres, MSSQL og WKT som den rumlige lagringstype, mens du bruger SDE, som giver dig mulighed for at kommunikere med de geodata direkte. Og mere, når jeg først har været nødt til at rydde op i SDE ved at få adgang til data direkte, da den brød. En anden fordel for rumligt aktiverede databaser er, at databasen kan udføre arbejdet i stedet for at bringe alle data ind i en klient og få den til at udføre arbejdet.
• @CrazyEnigma: citation nødvendig.
• stor beskrivelse af SDE vs ST Geometry @mwalker Tak
• re: geografiske referencer, jeg tror, at det er det modsatte. Rumlige referencer i PostGIS er standard, og SRIDerne er de samme som EPSG-koder for gældende SRS. Med SDE, mindst 9,3x, indeholder SRIDS udvidelser osv., Så du kan have to forskellige SRIDer til det samme Spatial Reference System. Dette forårsager problemer, hvis du vil bruge geografisk SQL.

Her er mit svar på en linje: Brug SDE, når du har brug for flere brugeradgang til dine geospatiale data.

Lad os sige, at du vil have flere brugere til at redigere dine data: brug SDE. Lad os sige, at du vil servere data til og lade dem redigeres over internettet: brug SDE. Hvis du er en lille butik med en GIS-fyr, skal du ikke bruge SDE.

Hvis du er den eneste person, der bruger dine geodata, SDE er ikke noget for dig. Hvis du ikke har brug for redigering af flere brugere, er SDE ikke noget for dig. Det er bedre for dig at bruge en fil GeoDatabase.

Hvad angår kompromiser … SDE er ikke trivielt at konfigurere eller administrere. Du skal bruge en RDBMS.

SDE er beregnet til større organisationer, hvor der er behov for en database, men flere brugere har brug for at få adgang til og opdatere / redigere data.

Kommentarer

• Jeg mener, at Arc-produkter er ret dårlige, når det kommer til multi-usr-miljøer. Der ser ud til at være mange ting, som ' ikke kan gøres, mens folk er forbundet. Hvis ydeevne og robust multibrugermiljø er vigtigt, skal RDBMS bedre lade alt det arbejde, der ikke involverer noget beskidt mellemvare, bare sænke tingene ned og sætte låse på alt. Men det ser fint ud, jeg må indrømme, boksen mener jeg 🙂
• Jeg er enig med Nicklas. Din sammenligning giver mening inden for buen verden, men SDE er ikke fantastisk med flere brugere. En rumligt aktiveret RDBMS som PostGIS har fordele i denne arena. Har du nogensinde forsøgt at give en bruger rettigheder til et SDE-datasæt, som en anden ser?
• Ja, jeg ' har kørt ind i det problem, du ' beskriver med tildeling af privilegier. Ikke sikker på, om det ' stadig er et problem, da jeg ikke har ' t måtte administrere en SDE GDB om et par år. Tilskud bør ikke blokeres af låse. Hvordan håndterer postgres / postgis redigering af flere brugere?

I dag tillader de fleste rumlige dbs flere rumlige kolonner i en tabel, mens SDE holder fast i en rumlig kolonne til en tabel. De har også rumlige data integreret med deres fleksible og effektive datastyringsværktøjer, som SDE mangler, såsom brugersaktioner, datareplikering, SQL-support osv.

ESRI SDEBinary er den hurtige performer. Hvis det kommer til ST_GEOMETRY, har SDE muligvis ikke den bedste ydeevne.