Migrering är aldrig helt gratis. Men den brukar bli billigare och säkrare för den förutseende, och även framtida byten av databasplattform blir enklare om man tänker efter före. Fast tänker gör vi rätt olika, och olika mycket. Hårddrar vi det, finns det åtminstone tre olika grader av organisationsmognad när det gäller att planera för migrering.
Se hela Informators utbildningsutbud inom Objektorientering
Grad 1: Stureplansinventarierna
Varför tänka efter alls? Den dagen den sorgen. Målar gladeligen in sig hos en enskild databasleverantör.
Fördelar: Stureplan har en bra arbetsmarknad. När migreringen väl närmar sig har man fått nytt jobb tvärs över gatan.
Nackdelar: På nya jobbet har de "tänkt" likadant...
Grad 2: Standardminimalisterna
Håller sig konsekvent till SQL-kärnan i såväl DDL (databasdefinitioner) som DML (SQL-anrop samt förlagrade procedurer) i vetskap om att standarden är skiktad och att man ur migreringssynpunkt sett sitter säkrast närmast basen (kärnan).
Fördelar: Goda överlevnadschanser på samma jobb även vid migrering. Vad gäller objektdatabaser resp "native XML"-databaser där ett byte utöver databasmotorn även berör hela datastrukturen (ungefär som när man gick från hierarkier i DL/1 till tabeller i DB/2)så har minimalisten åtminstone gjort livet lättare för sina leverantörer av stödverktyg för migrering.
Nackdelar: Tar inte tillvara SQL-motorns potential fullt ut. Att olika produkter kan stödja olika årgångar av SQL-standarden ger samtidigt en liten men ändå påtaglig risk för en icke ringa handpåläggning under migreringen.
Grad 3: Björndressörerna
Använder objekt-relationsmappning, OR M, i ett extra mellanskikt av "hanteringsklasser", idag oftast Hibernate (eng: "gå i ide"), för att hantera objekt i "vinterdvala". SQL-tabellerna utgör då björnidet. Eventuell tilläggsfunktionalitet utöver SQL-kärnan läggs i Hibernate. Applikationsprogrammerarnas jobb blir då i stort sett lika smidigt som i en renodlad objektdatabasmiljö.
Fördelar: Best-case scenariot i DB-migreringen handlar om omkonfigurering av Hibernate, och worst case ger knappast mer jobb än hos standardminimalisten. Hibernate har blivit allt vanligare och det är gratis (öppen källkod - observera att inga dolda förmåner utgår till undertecknad), och numera också en del av Javastandarden, samtidigt som det även finns anpassningar för C#. Därför är risken att behöva byta även själva ORM-skiktet ganska liten. Hibernate automatiserar allt handarbete kring strukturkonflikten mellan objekt i ett modernt programspråk och tabeller (i traditionell SQL). Det innebär mindre handkodning i det dagliga och dessutom ger det mindre jobb vid migrering.
När man ändå ser över sina automationsmöjligheter i allmänhet kan man eventuellt låta sitt UML-verktyg generera datamodeller och SQL-DDL (scheman, tabelldefinitioner) från klassdiagram i UML.
Nackdelar: Vanebildande. De företag som gått över till ORM-teknik har ingen större lust att byta tillbaka till handarbete. Open Source-kulturen kan naturligtvis göra att Hibernate tvärs över gatan inte uppför sig in i minsta detalj som det gamla invanda - men å andra sidan, vem har sagt att SQL gör det in i minsta detalj...
Beroende på situationen går det inte att förkasta något av alternativen. Företag med en planeringshorisont på ett par dagar skulle nog arbeta som Stureplansinventarierna. Skulle samtliga databasanrop vara enkla och solklara är Standardminimalisterna rätt ute. Men i en tid då kraven på IT-sidan i organisationerna är luddiga och det enda tydliga kravet är att allt måste vara lätt att förändra,verkar Björndressörerna sitta med de starkaste korten. Och handen på hjärtat, vem blir inte imponerad av mer automation?
Milan Kratochvíl, författare och konsult, Kiseldalen.com, lärare på Informator.