[DBMS] meerdere DBMSs ondersteunen?

[Verwijderd]

In hoeverre is het mogelijk om een systeem te bouwen dat gebruik kan maken van meerdere DBMSs?

Voor ons systeem zijn we ruim een jaar geleden uitgegaan van MySQL. Echter, we zijn er nu wel achter dat MySQL leuk is voor eenvoudige toepassingen, maar een aantal belangrijke tekortkomingen heeft. We willen ons systeem gaan ombouwen, en baseren op PostgreSQL.

Maar voordat we als een gek aan de slag gaan met het ombouwen, willen we eerst kijken in hoeverre we meerdere DBMSs kunnen ondersteunen. Op database-layer (apart database-handler object per DBMS) niveau is het geen enkel probleem.

Maar het niveau daarboven, waarin de queries opgebouwd worden en de DBMS-specifieke functies aangeroepen worden, lijkt een groter probleem.

Bijvoorbeeld de date functions; die verschillen in MySQL en PostgreSQL nogal. Dit zou je op kunnen vangen door in je code een check op het DBMS te laten uitvoeren en ad.h.v. het resultaat een andere functie aanroepen. Maar, dit maakt de code erg complex. Het gebruik van DBMS-specifieke functionaliteit (triggers, views, nested queries etc) lijkt helemaal een ramp te worden dan.

Afgaand op het feit dat er voor alle DBMSs aparte managers zijn (phpmyadmin, phpPgAdmin) neem ik aan dat het niet te doen is. Of is MySQL een beetje een exoot en liggen PGSQL, Oracle en Sybase bijvoorbeeld dichter bij elkaar?

[mulder]

Queries worden (wil je) toch juist in de DAL gemaakt, niet een niveau er boven?

[raoulduke]

In PHP kan je gebruik maken van PEAR of ADODB, dat zijn volgens mij twee bekende technieken om database abstractie toe te passen.

[whoami]

Als je je applicatie als n-tier opgezet hebt, dan is het te doen.
Je kan dan voor iedere DMBS die je wilt ondersteunen een eigen data access laag schrijven.
In je applicatie zelf (in je GUI) heb je dan geen SQL statements, maar praat je tegen een data access layer.

[whoami]

Don Facundo schreef op dinsdag 26 april 2005 @ 15:11:
Queries worden (wil je) toch juist in de DAL gemaakt, niet een niveau er boven?

Ja, dat snap ik ook niet ?
Je hebt toch je DAL layer waarin je al je queries hebt, bv:

code:

class SqlServerPersonGateway : IPersonGateway
{
    public PersonCollection GetAllPersons( string name )
    {
        string sql = "SELECT * FROM person WHERE name LIKE @p_name";
        ...
        return thePersons;
    }
}

[JayVee]

Zo een data access laag is voor ons overkill. DBMS onafhankelijkheid is leuk meegenomen als het kan, maar is niet zo belangrijk dat we een DAL gaan schrijven.

offtopic:
* JayVee werkt dus met GdHn samen

[ Voor 4% gewijzigd door JayVee op 26-04-2005 15:16 ]

[mulder]

Dan zie ik niet zo hoe je wel DBMS onafhankelijkheid wilt bereiken?

[whoami]

Sterker zelfs, dan is het onmogelijk.
Tenzij je met een conditionaldefine ofzo gaat werken:

code:

#ifdef ORACLE
sqlString = "oracle specific sql query";
#else ifdef SQLSERVER
sqlString = "blaa...";
etc...

Maar dan wordt het al gauw een zooitje, en moet je voor iedere DBMS die je wilt ondersteunen, een binary hebben.

[alienfruit]

Je zou de SQL queries dynamisch kunnen laten generen, zodat je "on-demand" van database server zou kunnen switchen.

[djc]

Of een aparte file met alle queries.

[SPee]

Werkt ODBC niet op zo'n manier.
1 way 4 all ?

[Standeman]

JayVee schreef op dinsdag 26 april 2005 @ 15:15:
Zo een data access laag is voor ons overkill. DBMS onafhankelijkheid is leuk meegenomen als het kan, maar is niet zo belangrijk dat we een DAL gaan schrijven.

offtopic:
* JayVee werkt dus met GdHn samen

Als je een beetje DBMS onafhankelijk wilt zijn, zou je toch een aparte datalaag moeten gaan schrijven. Nu weet ik niet hoe groot het datamodel is, maar in principe hoeft dit helemaal niet zoveel moeite te kosten. Hangt natuurlijk wel af van het budget & de tijd die je hebt.

[Verwijderd]

Als je een DAL overkill vindt zou je kunnen overwegen stored procedures te gaan gebruiken, zolang je de "interface" (de input/output params en de data die je terugstuurt) hetzelfde houdt zou je relatief eenvouding van DB moeten kunnen switchen. Op die manier kun je MySQL (vanaf versie 5, nu nog in beta), PostgreSQL, SQL Server, Oracle etc. ondersteunen zonder iets aan je applicatie te hoeven veranderen. Houdt in dat geval wel rekening met de "lowest common denominator", ga bijvoorbeeld geen gebruik maken van de XML kolomtypes of andere relatief exotische db features, want dan kom je in de problemen bij het porten van je SP's.

Voor niet al te ingewikkelde applicaties is dit een goede manier om meerdere db's te ondersteunen, de sp's vormen dan als het waren je DAL.

[Verwijderd]

Jullie zijn eenduidig, DAL is noodzakelijk voor zuivere onafhankelijkheid.

Ons datamodel is erg groot. Het systeem is volledig database-driven. De volledige opbouw van alle schermen wordt gemaakt op basis van database gegevens. Ik denk dat het maken van een DAL een enorme klus wordt, er zijn zeer veel complexe/dynamische aspecten.

Zoals ik er nu naar kijk, focussen we ons op PostgreSQL.

Bedankt!

[Standeman]

Verwijderd schreef op dinsdag 26 april 2005 @ 15:50:
Als je een DAL overkill vindt zou je kunnen overwegen stored procedures te gaan gebruiken, zolang je de "interface" (de input/output params en de data die je terugstuurt) hetzelfde houdt zou je relatief eenvouding van DB moeten kunnen switchen. Op die manier kun je MySQL (vanaf versie 5, nu nog in beta), PostgreSQL, SQL Server, Oracle etc. ondersteunen zonder iets aan je applicatie te hoeven veranderen. Houdt in dat geval wel rekening met de "lowest common denominator", ga bijvoorbeeld geen gebruik maken van de XML kolomtypes of andere relatief exotische db features, want dan kom je in de problemen bij het porten van je SP's.

Voor niet al te ingewikkelde applicaties is dit een goede manier om meerdere db's te ondersteunen, de sp's vormen dan als het waren je DAL.

Ik heb wel eens een DB moeten porten van MSQL-server naar Oracle en dat was niet echt een pretje.. maar goed, dat was dan ook wel weer 3 jaar geleden ofzo. De PL/SQL deed toch niet helemaal wat het zo moeten doen in 50% van de procedures..

[Verwijderd]

Standeman schreef op dinsdag 26 april 2005 @ 16:03:
De PL/SQL deed toch niet helemaal wat het zo moeten doen in 50% van de procedures..

Lag dat aan de database of aan de programmeur?

[JaQ]

ik begin met de dag minder te geloven in database onafhankelijk programmeren. Je flikkerd namelijk alles weg wat een database meer maakt dan een verzameling bestandjes. Er zijn best database die vergelijkbare features hebben, maar het blijft altijd een subset.

[djc]

Je zit inderdaad vast aan een lowest common denominator, maar aangezien deze naar ik aanneem (en dat lijkt me een niet onredelijke aanname) steeds groter wordt moet het toch best mogelijk zijn.