DBA vs fejlesztő

A DBA hányaveti módon tervezi meg az adatbázist. A fejlesztő meg bénán használja. Aztán mindkettő a másikat szidja.

A DBA nem készített normális struktúrát és indexeket, a fejlesztő pedig megszórja ad-hoc select *-is lekérdezésekkel, meg a tranzakciós adatbázisból közvetlenül riportol. Ismerős a helyzet?

Sajnos azt kell, hogy mondjam, mindkét sapka volt már rajtam, de szerintem a DBA tud többet tenni az ügy érdekében. Nem csak abban, hogy jóóóó előre gondolkozik, hogyan fogják az adatbázist használni. Ebben is, de én inkább arra szavazok, hogy a DBA dolga folyamatosan figyelni az adatbázis használatot, és újabb fejlesztésekkel előrébb vinni a dolgokat.

Tudom, hogy a fejlesztések általában úgy zajlanak, hogy ha befejeződött, akkor a legkisebb esély arra van, hogy ismét elővegyék a rendszert és optimalizáljanak. Legtöbb esetben az alkalmazás odakerül és megy évekig. Esetleg még kicsit piszkálják itt-ott, de a teljesítménybeli felülvizsgálat csak a leges-legvégső esetben jön el.

A DBA ellenben együtt él az adatbázisokkal, együtt lélegzik velük minden nap, órában, percben. Sokkal előbb el tudja kapni, ha valami megfekszi egy adatbázis pici pociját… és lépni is előbb tud, mint egy alkalmazás fejlesztője.

Óvatos kis módosításokkal tudja terelgetni az adatbázist, az adatfolyamot, hogy a jó ideje változatlan alkalmazás is úgy tűnjön a felhasználóknak, hogy de hasít. Persze néha drasztikus változtatás is lehetséges, vagy egészen egyszerűen tényleg fejbe kell verni a fejlesztőt, hogy ezt hogyan gondolta.

A lényeg: az együttműködés nagyon fontos, és ha valami gond van, először találjuk meg a megoldást, akár közösen is. Aztán majd mehet az egymásra mutogatás, hogy kinek a hibája volt, bár addigra valószínűleg mindkét „oldal” túl fáradt lesz ahhoz, hogy ezt komolyan számon kérje.