I mit læringsmål for Databaser og datalagring har jeg blandt andet sat mig som mål at kunne analysere projektets behov for datalagring og på den baggrund vælge og begrunde en egnet databaseløsning.
Min første tanke var at undersøge open-source teknologier, men jeg har tidligere arbejdet med Microsoft SQL Server, og derfor giver det også mening at have den med i sammenligningen.
Mit fokus er ikke nødvendigvis at finde den database, der har flest funktioner, men den løsning der passer bedst til behovet i vores projekt QuestGame.
Hvad har QuestGame behov for?
QuestGame har en forholdsvis klassisk relationel datamodel med eksempelvis quests, quest-items, deltagere, besvarelser og svarmuligheder. Derfor virker en relationel database som et naturligt udgangspunkt.
Samtidig har projektet et særligt behov: lokationsdata.
Et QuestItem skal kunne være knyttet til en geografisk position, og backend skal blandt andet kunne arbejde med afstand mellem brugerens position og punkter på kortet. Derfor er understøttelse af geografiske datatyper og forespørgsler et vigtigt kriterium i databasevalget.
Derudover lægger jeg vægt på:
- integration med EF Core
- relationer og dataintegritet
- migrations og Code First
- understøttelse af geografiske data
- dokumentation og værktøjer
- kompleksiteten i forhold til projektets størrelse
På den baggrund har jeg især undersøgt PostgreSQL, MySQL og Microsoft SQL Server.
PostgreSQL
PostgreSQL var en af de første databaser, jeg kiggede nærmere på, fordi den er open source og samtidig er en veletableret relationel database. PostgreSQL understøtter blandt andet foreign keys, transaktioner og komplekse forespørgsler og er designet til at kunne udvides med yderligere funktionalitet.
Det mest interessante i forhold til QuestGame er PostGIS.
PostGIS udvider PostgreSQL med geografiske datatyper, spatial-indeks og funktioner til blandt andet afstandsberegninger og andre geografiske forespørgsler. Det betyder eksempelvis, at lokationer kan gemmes som geografiske punkter og forespørges direkte i databasen.
Samtidig findes der en EF Core-provider til PostgreSQL gennem Npgsql. Med NetTopologySuite kan geografiske .NET-typer mappes til PostGIS, og flere spatial-operationer kan oversættes til forespørgsler, der udføres direkte i databasen.
Det passer sammen med et spørgsmål fra mit læringsmål: Hvilke beregninger bør foretages i backend, og hvilke bør foretages i databasen?
En afstandsforespørgsel er et godt konkret eksempel på noget, hvor det kan være relevant at lade databasen udføre arbejdet frem for først at hente alle lokationer til backend.
MySQL
MySQL var også relevant at undersøge, da det er en udbredt relationel database og findes i en open-source Community Edition.
I første omgang havde jeg en forestilling om, at PostgreSQL nærmest automatisk ville være det oplagte valg, hvis projektet havde geografiske data. Det viser sig dog at være mere nuanceret.
MySQL understøtter selv geografiske datatyper som blandt andet POINT, LINESTRING og POLYGON samt funktioner til behandling af geografiske data. Det understøtter også spatial-indeks.
Der findes desuden EF Core-providers til både MySQL og MariaDB. Microsofts oversigt over EF Core-providers nævner blandt andet både Pomelo-providerens understøttelse af MySQL/MariaDB og Oracles egen MySQL-provider.
MySQL kan derfor umiddelbart opfylde mange af de samme grundlæggende krav som PostgreSQL.
For QuestGame skal jeg derfor ikke blot sammenligne, om databaserne kan håndtere geografiske data, men snarere hvor godt funktionaliteten passer til de geografiske forespørgsler, vi faktisk har behov for.
Microsoft SQL Server
Jeg vil også inkludere Microsoft SQL Server i vurderingen, selvom min oprindelige motivation var at se på open-source løsninger.
En væsentlig årsag er, at jeg allerede har arbejdet med SQL Server. Samtidig har SQL Server en meget direkte integration med vores backendteknologi. Microsoft vedligeholder selv Microsoft.EntityFrameworkCore.SqlServer, som er den officielle EF Core-provider til SQL Server.
SQL Server har desuden sin egen understøttelse af geografiske data gennem datatyperne geometry og geography. geography er beregnet til data på jordens overflade og kan blandt andet bruges til GPS-koordinater.
Dermed kan SQL Server også håndtere et centralt krav i QuestGame.
Fordelen for mig ville blandt andet være, at teknologien allerede er forholdsvis kendt, og at EF Core-integrationen vedligeholdes som en del af Microsofts eget EF Core-projekt.
Til gengæld er SQL Server ikke open source. Det behøver ikke i sig selv at udelukke den, men det er en forskel i forhold til den retning, jeg oprindeligt ønskede at undersøge.
Sammenligning
| PostgreSQL | MySQL | SQL Server | |
|---|---|---|---|
| Relationel database | Ja | Ja | Ja |
| Open source | Ja | Ja, Community Edition | Nej |
| EF Core | Npgsql | Flere providers | Microsoft-provider |
| Geografiske data | PostGIS | Indbygget spatial support | geometry / geography |
| Spatial-indeks | Ja | Ja | Ja |
| Min erfaring | Begrænset | Begrænset | Større |
| Særligt interessant for QuestGame | PostGIS | Alternativ open-source løsning | Kendt .NET-økosystem |
Sammenligningen har været nyttig, fordi den udfordrer min første antagelse om, at valget hovedsageligt stod mellem en database med eller uden geografisk funktionalitet. Alle tre løsninger kan i forskellig grad håndtere geografiske data.
Spørgsmålet bliver derfor snarere, hvilken løsning der passer bedst til den måde, QuestGame skal arbejde med data på.
Mit foreløbige valg
På nuværende tidspunkt hælder jeg mod PostgreSQL med PostGIS.
Det skyldes ikke kun, at løsningen er open source. Det interessante er kombinationen af en relationel database, stærk understøttelse af geografiske data og muligheden for at integrere dette med EF Core gennem Npgsql og NetTopologySuite.
PostGIS passer samtidig godt til nogle af de spørgsmål, jeg gerne vil undersøge som en del af mit læringsmål. Jeg kan eksempelvis arbejde med geografiske datatyper, spatial-indeks og afstandsforespørgsler og undersøge, hvornår sådanne operationer bør ligge i databasen frem for i backend.
Jeg betragter dog ikke databasevalget som afsluttet alene på baggrund af teknologiernes featurelister. Næste skridt er at koble valget til konkrete use cases fra QuestGame og afprøve, hvordan de vigtigste dele fungerer sammen med EF Core.
På den måde bliver selve valget og begrundelsen af databaseteknologi en del af arbejdet med mit læringsmål, frem for at PostgreSQL blot er en teknologi, der var valgt på forhånd.
Homepostgis.net (åbner i en ny fane)
PostgreSQLpostgresql.org (åbner i en ny fane)