[ALG] Hoe SQL van van code scheiden

[Verwijderd]

als nette programmeur zorg je ervoor dat de specifieke dbms commando's van je programmeercode in een aparte class geschreven worden.
Dit om te zorgen dat als je een andere dbms wil, enkel de database-module moet herschrijven.

zoiets als

PHP:

class mysql{ 
function connect($DB_PARAMS){ 
    $this->dbid = @mysql_connect($this->...blablbla); 
    blablbla....
  }
function __query($querystring){ 
    $result = mysql_query($querystring, $this->dbid);
}
}

Maar de SQL queries zijn niet voor elke dbms het zelfde
deze moeten ook herschreven worden bij het veranderen van dbms.

Hoe voorzie je dit nu het best in je code ?

ik heb al 2 mogelijkheden bedacht :


1. zet al de queries in constanten bovenaan een module en dan je code :

PHP:

   var query_function1 = "select * from ...");

class dosomething{ 

   $database->query(query_function1);
  .....

2. voor elke specifieke query maak je in je database module een aparte functie

PHP:

$database->Getuserdata();

hoe programmeren jullie als je verschillende DBMS moet ondersteunen?

BTW ik weet dat er iets bestaat zoal PEAR ... maar dat wil ik nu even buiten beschouwing laten.
bij mij gaat het hier toevallig over php, maar ik had ook in een andere omgeving aan het ontwikkelen zijn...

Modbreak:

Hoe post je code? / Hoe gebruik je de code tag?

[ Voor 7% gewijzigd door NMe op 01-09-2006 21:43 ]

[Michali]

Queries met objecten opbouwen, ipv direct met SQL. Ga hier alleen niet te ver in en stel geen eisen die nergens op slaan. Het wisselen van een DBMS gebeurt vrijwel nooit.

[GX]

Michali schreef op vrijdag 01 september 2006 @ 20:45:
Queries met objecten opbouwen, ipv direct met SQL. Ga hier alleen niet te ver in en stel geen eisen die nergens op slaan. Het wisselen van een DBMS gebeurt vrijwel nooit.

Wisselen zelden, anders implementeren wel.. Verder wel met je eens, opbouwen met objecten, maar niet te ver gaan..

[Verwijderd]

Het wisselen van een DBMS gebeurt vrijwel nooit.

Wisselen niet, maar het ondersteunen van meerdere DBMS's in 1 applicatie komt heel vaak voor.
Voor MySQL nog niet echt een optie, maar in zo'n geval is het onderbrengen van de queries in stored procedures een goede optie. De DB-specifieke syntaxverschillen en optimalisaties stop je dan in de stored procs van die bewuste DB, en in je data access layer hoef je dan alleen maar rekening te houden met een paar kleine syntaxverschillen in het aanroepen van die stored procs.

Of je gebruikt een O/R mapper die met meerdere DBMS's overweg kan, maar dat heeft vrijwel altijd tot gevolg dat je a) meestal meer gegevens uit de DB haalt dan je op dat moment nodig hebt, en b) geen DB-specifieke optimalisaties kunt gebruiken. Oftewel, de boel wordt een stuk trager.

Overigens, wanneer 't om een simpele query gaat als "select BankAccount from Customers where CustomerID = ..." is 't onzin om dat in een stored proc te stoppen. Pas bij joins, unions, subqueries, DB-specifieke functies (datum-functies zijn berucht), etc. wordt 't echt zinvol.

[ Voor 14% gewijzigd door Verwijderd op 02-09-2006 08:23 ]

[Verwijderd]

jullie brengen hier mooie ideeën aan!

Hebben jullie daar ook online lectuur over?
ik weet niet op welke woorden ik moet zoeken bij google om meer uitleg te krijgen over dit onderwerp

[xos]

Er zijn veel verschillende manieren, maar wat je kan doen is even op deze pagina kijken en dan met name bij het kopje "Object-Relational Metadata Mapping Patterns". Hier worden enkele patterns kort besproken welke gebruikt worden. Daarna zal je zelf op google of via een boek wat meer info kunnen zoeken.

Hibernate is een voorbeeld van een library welke je kan gebruiken om je code min of meer onafhankelijk te maken van het soort database dat gebruikt wordt. Helaas komt het met een prijs zoals afterlife al aangeeft.

offtopic:
Ik vind persoonlijk dat je voor dit soort dingen eigenlijk beter een boek kan aanschaffen omdat de kwaliteit van gratis online artikelen nog wel eens erg kan tegenvallen.

[whoami]

Leuk om Hibernate hier te vermelden, maar als de TS in PHP gaat werken, heeft hij daar niet zoveel aan. Ik vraag me trouwens af of er uberhaupt O/R mappers voor PHP bestaan.

Zowiezo is het onderwerp wat je hier aansnijdt heel uitgebreid, en ik denk niet dat je na één week met een 'aha erlebnis' zult komen, die je het licht laat zien. Iedere keer heb je wel met een ander probleem te kampen, en veel hangt dus af van je requirements.

Wat je kan doen, is een set classes maken die aan een bepaalde interface voldoen. Deze classes implementeren dan die interface, en in je programma 'programmeer je dan tegen die interface'.
Je specifieke classes bevatten dan de (Sql) code die specifiek is voor de DB die je daarmee wil ondersteunen. Op die manier is het makkelijk om gewoon de implementatie te wisselen, mocht dat nodig zijn.

Hier op GoT zijn er trouwens al een paar topics over geweest:
[Alg] Ontwerpen van Data-access en business classes
\[.NET|C#] Opzetten van een DAL
\[Alg/DDD] Repositories & domain classes
[DBMS] meerdere DBMSs ondersteunen?
[Alg] Data access + Business logic, hoe?
[alg] enterprise applicatie - totaal oplossing.
\[C#] Multi-tier applicatie

[MBV]

Dit is toch typisch iets waar ze het ontwerp in 3 lagen voor hebben?
van de link hierboven: service layer
1e laag is je interface, pak-em-beet je GUI.
2e laag is je business logic, je verwerking van gegevens naar dingen waar je GUI wat mee kan.
3e laag is je database-access, je queries etc.

Jouw probleem gaat dus over de 3e laag. Ik ben verliefd op het flyweight pattern (schema'tje) waarin je aan een singleton object vraagt: "geef mij eens een persoon die aan die-en-die eisen voldoet" (heet in het plaatje de FlyWeightFactory). Dat ding moet je abstract maken, zeg een PersonFactory, en 1 of meerdere implementaties voor maken (bijv een MysqlPersonFactory of een MssqlPersonFactory).

Ik moet alleen wel toegeven dat ik dit model nog niet echt in de praktijk heb kunnen brengen bij applicaties die 'te moeilijke' databasedingen doen.

[ronaldmathies]

Kijk eventueel eens naar het Data Access Object design pattern, die lost dit soort problemen ook op.

[MBV]

Goh, mooie zoekterm. Dat is dus wat ik eigenlijk altijd al maak, maar het blijkt een mooie naam te hebben Da's het leuke aan design patterns: vaak zijn ze niet eens zo moeilijk, maar gewoon handig
Duidelijkste diagrammetje wat ik net kon vinden: