Igazából nem feltétlenül jelent ez problémát, mert ugye a customer-nek sem mindegy, hogy az
adott termék elmegy egy ingyenes linux/postgres kombó alatt, vagy - bár nincs kihasználva -
de windows/oracle kell neki. És akkor a termék ára simán több misivel megnő (oracle licenszt
néztem múltkor, és szörnyülködtem...) amivel lényegében versenyképtelen lehetsz a konkurenciával
szemben.
Több megoldás van ugyanarra a problémára, az egyik az, hogy minél közelebb tartjuk az adatokhoz az
adatokat kezelő logikát. Ez a logika nem feltétlenül pl/sql, hanem jöhet a táblák megfelelő szerkezetéből.
Amennyiben bonyolultabb, több táblát érintő trükkös változtatásokra van szükség, akkor ott a pl/sql.
Erről a témáról van egy nagyon jó tutorial itt, amit kötelezővé tennék:
http://database-programmer.blogspot.hu/2008/09/comprehensive-table-of-c…
Egy másik megoldás az OO mappelés, amikor azt mondjuk, hogy egy általános lekérdező nyelven fogjuk az
adatokat elérni, és a mögötte lévő ORM rendszerre bízzuk, hogy ezt hogy is fogja megtenni. Ezt csinálja
pl. a Hibernate is, ahol megadjuk, hogy milyen táblák vannak, ezek között milyen kapcsolat, ezek után pedig rábízzuk az adatok elérését/cache-elését. Ez elvileg nagyon kényelmes, hiszen ha másik adatbázisra akarunk átállni, akkor csak egy sort kell módosítani, és minden megy, mint a karikacsapás. Az ördög viszont a részletekben van, amikor bonyolult lekérdezéseket kell írni, jó sok join-nal, esetleg olyan adatbázis által támogatott funkciókat kell kezelni, mint például a geografikus koordináták kezelése (postgis, etc.) vagy egyéb trükkös dolgok. Egy másik probléma, hogy bejönnek olyan új osztályok, amik mondjuk egy adatbázis sort
reprezentálnak, de az üzleti logikában nem feltétlenül ezen a logikai szinten szeretnénk dolgozni, bár ez inkább csak saját nyavajgás...
A harmadik megoldás az, hogy ORM mapper nélkül közvetlenül SQL parancsokat futtatunk, viszont az üzleti logikát az adott programozási nyelven implementáljuk. Ez olyan kis öszvér megoldás, volt nálunk ilyen kód,
de annyira nem tetszett, mert sok mindenre kell figyelni, amit az adatbáziskezelő jobb esetben magától megold. Nyilván ezzel viszont elveszik az adatbázis függetlenség.
Összességében azt mondanám, hogy mindig az adott projekttől függ, hogy milyen adatbázis elérési módszert használunk, más-más feladat más-más megoldást kívánhat, figyelembe véve az requirement/budget/szívás faktort.