Rendszerátépítés futás közben 2. lépés

futasTörténetünk első lépésében arra kerestem a megoldást, hogy hogyan lehet egy futó rendszert menet közben teljesen átépíteni. A több lehetséges megközelítés közül a béka módszert választottam, azaz azt, hogy szépen elemenként kifejlesztünk egy funkciót és aktiválásakor kiiktatjuk a régi rendszer részt. Lássuk a hogyant!

Az adatbázis séma

Mivel minden adatokat kezelő rendszer – így a szóban forgó megrendelés és ügyfélnyilvántartó is – legalapvetőbb építőköve maga az adat így az átépítést az adatok kezelésével kezdtem. Fogtam és a 0-ról felvázoltam egy adatbázis sémát amiben a jelenlegi rendszerhez szükséges adatokat megfelelően le lehetne tárolni. Ezután melléjük tettem az új igényeket, módosítottam a sémát ahol szükséges volt. Így kaptam egy teljes adatbázis sémát ami kényelmesen kiszolgálja a rendszerrel szemben támasztott követelményeket. A célunk az, hogy az átépítésé végére ez legyen a séma amiben minden adat mozog.

Adatmigráció

A következő feladat az, hogy felvázoljuk azokat a kapcsolódási pontokat ahol a régi adatbázis séma és az új átfedi egymást. Ennek szemléltetésére készítettem egy egyszerű táblázatot ahol bal oldalon voltak felsorolva az eredeti adatbázis séma táblái és mezői és mellettük jobb oldalon az új sémában a réginek megfelelő mezők. Végül – egy jóval hosszabb de – ilyesmi táblázatot kaptam.

Régi tábla.mezőnév Új tábla.mezőnév
telepules.id telepulesek.id
telepules.nev telepulesek.nev
telepules.csoport
rendeles.id rendelesek.id
rendeles.tetel * rendelesek.menu_id
rendeles.mennyiseg rendelesek.mennyiseg
rendeles.datum rendelesek.kiszallitas

A táblázatot arra használtam, hogy lássam, hogy a régi sémából mely adatok hogyan vándorolnak az újba. Ez alapján 3 féle adattal van dolgunk.

  • nem migrálandó adatok
  • egy az egyben migrálható adatok
  • összetett migrálású adatok

Nem migrálandó adatok

Velük lesz a legkönnyebb dolgunk, mivel ezek azok az adatok amelyekről úgy döntünk, hogy nem fogjuk a régi sémából áttenni őket az újba, hanem egyszerűen eldobjuk őket mivel nem lesz rájuk szükség. A táblázatunkban ezekbe a sorokba az új tábla.mezőnév oszlopába egy kis vízszintes vonal került jelezve ezzel, hogy az adott mező nem kerül migrálásra. Persze alaposan át kell gondolni, hogy milyen adatokat nem fogunk migrálni és miért, nehogy valami fontos kimaradjon.

Egy az egyben migrálható adatok

Itt már lesz egy kis dolgunk. Ezek olyan mezők lesznek amelyek minimális vagy semmilyen átalakítás után kerülnek be az régi sémából az újba. Például a userek id-jét nem akarjuk módosítani fogjuk majd és egyszerűen csak áttesszük a régiből az újba. Egyszerű módosításnak minősül ha mondjuk egy migrálandó mező értékei elé be akarunk tennie egy fix stringet, egy számot tároló mező típusát változtatjuk vagy mondjuk egy régen datetime-ként tárolt mezőt az új sémában date-ként tárolunk. Ezen konverziókat egyszerűen automatizálhatjuk majd.

Az egy az egyben migrálható mezők esetében a táblázatunk bal oldala a régi tábla és mezőnév párost, a jobb oldal pedig az új tábla és mezőnév párost mutatja.

Összetett migrálású adatok

Ezek az izzasztó feladatok. Akkor válik egy mező összetett migrálásúvá ha az új séma szerint nem az eredeti adatot hanem annak egy kapcsolatát akarjuk az új sémában szerepeltetni.

Vegyük például a rendeles.tetel mezőt a régi sémánkban. Ez egy szöveges mező volt ami egy menü nevét takarta. A menüknek persze van egyedi id-je is, így ez a tábla szerintem indokolatlanul volt normalizálatlan. Az új sémában emiatt ezt a régi sztringként tárolt menü nevet a menü id-jére akarom cserélni.

Egy másik – szintén indok nélkül normalizálatlan – táblában egy rekordban szerepelt egy ar és egy ar2 mező. Az új sémában ezeket két külön rekordban akartam szerepeltetni.

Ilyen és ehhez hasonló esetekben nem fogunk tudni egy sima SELECT INTO-val adatokat átpumpálni a régi sémából az újba, hanem mindegyikükkel külön-külön foglalkoznunk kell.

Ezeket a mezőket *-gal jelöltem a táblázatban.

A következő részben azt nézzük meg, hogy konkrétan milyen módszerrel tudjuk a jelenlegi adatainkat migrálni a régi sémából az újba, valamint, hogy hogyan tudjuk elérni azt, hogy a rendszer futása közben a lehető legkisebb erőfeszítéssel (értsd a legkisebb hibalehetőséggel) a régi sémából az adatok folyamatosan csordogáljanak az új sémába is.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.