structuur van DBAL

[tombo_inc]

ik ben van plan om een database abstractie laag te gaan maken. daarom heb ik eerst een hele berg artikelen en berichten gelezen over dit onderwerp. hier op GoT kwam ik een hele berg interessante ideeen en opzetten tegen, en daaruit heb ik zelf een opzet bedacht die mij geschikt lijkt.
mijn idee is als volgt:

allereerst had ik het idee om query objecten te gaan gebruiken. dit lijkt mij handig omdat ik dan stored queries kan gebruiken en omdat ik dan alleen maar een query object door hoef te geven aan mijn dbal. een query bouwen zou dan moeten geschieden via een aantal set methods van het query uobject. echter, queries kunnen nogal complex zijn en daarom zal het aantal "bouw methods" ook sterk toenemen. ik vraag me dan ook af of dit een geschikte manier is om met queries om te gaan.

verder wil ik voor mijn DBAL een factory gebruiken waarin ik aan kan geven wat voor een driver ik wil laden. dus ik zeg bijvoorbeeld tegen mijn dbal dat ik een mysql db nodig heb, dan zorgt de factory ervoor dat de mysql driver geladen wordt. dus zeg maar een soort adapter pattern.

de drivers, ookwel adapters genoemt geloof ik, zorgen vervolgens voor de database specifieke implementatie. je zegt dus tegen de adapter dat je een query uit wilt voeren en je geeft dan het betreffende query object mee als parameter. de adapter parsed vervolgens het query object en vertaalt deze naar de juiste database specifieke querystring, waarna de query uitgevoerd wordt.

wat ik met het queryresultaat ga doen ben ik nog niet helemaal over uit. waarschijnlijk wordt dat ook een resultobject oid. misschien kunnen jullie me daarover adviseren.

in ieder geval lijkt me dit wel een goede manier van aanpak. ik zou graag jullie mening horen over mijn idee. wat doe ik goed, wat doe ik fout of wat kan er anders/beter, en ben ik nog belangrijke zaken vergeten.

[momania]

Waarom zou je dit zelf willen maken

En in welke taal dan eventueel?

[tombo_inc]

ik wil dit zelf maken omdat het dan voldoet aan mijn eisen. ook is het systeem niet te log of te uitgebreid. ik implementeer dan alleen die zaken die ik nodig heb.
de taal die ik ga gebruiken is php. omdat het systeem een onderdeel wordt van een backend voor een webapplicatie.

[RobIII]

tombo_inc schreef op zondag 24 december 2006 @ 00:07:
de taal die ik ga gebruiken is php. omdat het systeem een onderdeel wordt van een backend voor een webapplicatie.

En waarom zou dat dan "automatisch" php betekenen? Je kunt een DBAL in princiepe in iedere taal schrijven hoor

Ik denk dat je het wiel opnieuw aan 't uitvinden bent; maar ik kan me ook wel vinden in het "dan doet het niet meer/minder dan ik ervan eis". Ik denk dat je het beste gewoon eens kunt kijken naar andere projecten hoe die het oppakken/aanpakken. Er zijn vele wegen die leiden naar rome, en er is niet "één juiste".

tombo_inc schreef op zaterdag 23 december 2006 @ 23:14:
in ieder geval lijkt me dit wel een goede manier van aanpak. ik zou graag jullie mening horen over mijn idee. wat doe ik goed, wat doe ik fout of wat kan er anders/beter, en ben ik nog belangrijke zaken vergeten.

Om antwoord te geven op je vraag: Geen idee, je beschrijft het nu heel globaal en aan de hand daarvan kunnen wij natuurlijk niet 1 2 3 zeggen of je iets vergeet of verkeerd doet. Je verhaal klinkt an sich prima en het zal aan de uiteindelijke implementatie ervan liggen hoe goed het is.

[ Voor 14% gewijzigd door RobIII op 24-12-2006 02:04 ]

[momania]

tombo_inc schreef op zondag 24 december 2006 @ 00:07:
ook is het systeem niet te log of te uitgebreid. ik implementeer dan alleen die zaken die ik nodig heb.

Lees dit zelf nog eens een paar keer terug en zie dat je jezelf nu aan het tegenspreken bent.

Je wilt een database onafhankelijke en abstracte DAL etc, maar je wilt wel alleen de zaken implementeren die jij nodig hebt.

[kenneth]

tombo_inc schreef op zondag 24 december 2006 @ 00:07:
ik wil dit zelf maken omdat het dan voldoet aan mijn eisen. ook is het systeem niet te log of te uitgebreid. ik implementeer dan alleen die zaken die ik nodig heb.

Wat is te log? Een systeem met 100 features die al tig keer getest zijn, gedebugged zijn, worden onderhouden, wil jij niet gebruiken omdat je er 20 niet gebruikt? Dus je wilt dan 80 features helemaal opnieuw uitvinden, met bijbehorende bugs?

Met die redenering zou je ook eerst even je eigen taal moeten gebruiken, want in PHP zitten ook dingen die je niet gebruikt.

[tombo_inc]

dat de taal waarin je zoiets maakt niet zoveel uitmaakt snap ik. ik wil echter php gebruiken omdat ik die taal vaardig ben en omdat mijn dbal op een webserver moet gaan draaien.
verder is log inderdaad moeilijk te definieren, maar ik bedoel dat ermee dat ik nu een systeem wil dat doet wat ik wil, en niet een 100 tal functies omvat die ik nooit gebruik. dat zou mijn applicatie alleen maar trager maken. op het moment dat ik iets meer nodig heb dan breid ik mijn systeem gewoon uit.
daarnaast vind ik het gewoon leuk en leerzaam om zoiets zelf te maken, in plaats van bestaande systemen te gebruiken. op die manier leer je (denk ik) het hele systeem en principe ook beter begrijpen. uiteraard bestudeer ik ook bestaande systemen en test ik mijn systeem ook uitgebreid.
tot zover mijn motivatie

[Brakkie]

Je zou eens kunnen kijken naar de feature set van doctrine. Dit is een object relational mapper voor php. Misschien dat je er wat ideeen uit kan halen.

code:

Doctrine supports:

    * Multiple databases
    * Runtime configuration (no XML needed!)
    * Database abstraction with PDO + Doctrine session drivers
    * Database views
    * Column aggregation inheritance as well as class table inheritance
    * Nested transactions
    * UnitOfWork pattern (flexible session flushing)
    * EventListeners
    * Validators
    * Transactional errorStack population with validators
    * Query caching
    * Pessimistic offline locking
    * Transactional query optimization (gathering of DELETE statements)
    * State-wise records and sessions
    * Foreign key relations as well as association table relations
    * Tree structures
    * Association table self-referencing
    * Full data type abstraction
    * Relation aliases
    * PHP Array / Object data types for columns (automatic serialization/unserialization)
    * Enum data type emulation for all databases
    * OO-style query API for both DQL and raw SQL
    * DQL (Doctrine Query Language)
    * LIMIT / OFFSET support
    * Sequence / autoincrement emulation
    * Object population trhough rawsql
    * Proxy fetching
    * Lazy property fetching
    * Composite, Natural and autoincremented identifiers
    * Database query profiling
    * Automatic table creation

phpdoctrine

[kenneth]

tombo_inc schreef op zondag 24 december 2006 @ 16:54:
verder is log inderdaad moeilijk te definieren, maar ik bedoel dat ermee dat ik nu een systeem wil dat doet wat ik wil, en niet een 100 tal functies omvat die ik nooit gebruik. dat zou mijn applicatie alleen maar trager maken.

Dat betwijfel ik. Misschien zit dat tussen de oren, maar 'n framework gebruiken is in 99% van de gevallen de juiste keuze.

daarnaast vind ik het gewoon leuk en leerzaam om zoiets zelf te maken

Dat is natuurlijk altijd 'n goede motivatie

[tombo_inc]

om nog even terug te komen op mijn ontwerp.
bij het gebruiken van query objecten, kan ik dan het beste voor iedere type query (select, insert etc.) een apart object maken? of is het beter om 1 object te maken waarin ik iedere mogelijke query kan vastleggen. dit i.v.m. geheugen gebruik en de logheid van het object.
en wat is aan te raden wat betreft het afhandelen van resultsets? kan ik het beste een result object maken, dat ik dan weer aan mijn DAL door kan geven. of kan ik beter de standaard database resultset gebruiken? ik kan hier niet een eenduidig antwoord op vinden in de artikelen (het is natuurlijk ook situatie afhankelijk). ik zou hier graag wat adviezen over willen hebben

[Verwijderd]

Tombo_inc; groot gelijk dat je het wiel opnieuw wil uitvinden. Ik snap werkelijk waar niet waarom hier op GoT toch best vaak de houding is; waarom zo moeilijk doen? dit, dat, zus en zo is er al. Dit forum heet niet voor niets Software Engineering & Architecture. Hier komen mensen die willen weten hoe iets precies in elkaar zit, mensen die zelf het wiel opnieuw willen uitvinden omdat ze dat leuk en leerzaam vinden.

Om even concreet ontopic te komen. Wil je ActiveRecord van Fowler implementeren? In dat geval zou ik eerst zijn boeken over deze patterns er op naslaan. Je driver idee is prima, maar nou niet het meest complexe en kritieke punt.

Er is een groot aantal problemen waar je tegen aan zult lopen. Een aantal punten waar je rekening mee moet houden;

lazy-load
Gebruik lazy-load. Wanneer je een collectie van bijvoorbeeld Personen ophaalt, wil je niet je hele geheugen volspugen. Pas op het moment dat je een row nodig hebt, wil je hem fetchen.

code:

$persons = &PersonPeer::doSelect ();
$iter = $persons->iterator();
while ($iter->hasNext() && $person = $iter->next()) {
  $name = $person->getName();
  $salary = $person->getSalary();
  sprintf('%s earns %s dollar per month.', $name, $salary);
}

relaties
Je moet veel relaties ondersteunen; one-to-one, one-to-many, many-to-many, self-referencing etc. Hoe wil je de interactie tussen Objecten laten plaatsvinden.

[kenneth]

Verwijderd schreef op dinsdag 26 december 2006 @ 11:51:
Tombo_inc; groot gelijk dat je het wiel opnieuw wil uitvinden. Ik snap werkelijk waar niet waarom hier op GoT toch best vaak de houding is; waarom zo moeilijk doen? dit, dat, zus en zo is er al.

Omdat de insteek vaak is dat je een doel wil bereiken, dat het hier om het maken ging, en niet om het gemaakte, was niet iedereen (mij ook niet) duidelijk

Dat is toch 'n logische houding? Ik snap werkelijk niet waarom je dat niet snapt? Natuurlijk, als hij het wil maken om het maken, moet hij dat vooral doen, dat kan zeker een leuk en uitdagend project zijn, maar in ieder ander geval gebruik je toch slim de beschikbare tools? (Om maar te zeggen: hoeveel mensen schrijven eerst hun eigen taal en compiler voordat ze beginnen met programmeren )

[whoami]

lazy-load
Gebruik lazy-load. Wanneer je een collectie van bijvoorbeeld Personen ophaalt, wil je niet je hele geheugen volspugen. Pas op het moment dat je een row nodig hebt, wil je hem fetchen.

Hier wil ik toch even op inpikken.
Lazy Load kan in bepaalde omstandigheden best handig of noodzakelijk zijn; maar het zorgt toch in veel gevallen voor wat extra complexiteit (bij het ontwikkelen dan). Lazy Load voor collecties gebruik ik echt als het moet / noodzakelijk is. Nu en dan ben ik ook eens met NHibernate bezig, en daar gebruik ik het zelfs liever niet.

[tombo_inc]

@quist
dat activerow principe ziet er erg interessant uit, ik zal het eens gaan bestuderen. ik denk echter dat het niet is wat ik op dit moment nodig heb.
mijn idee is nu om query objecten te gebruiken waarin ik mijn queries op sla. als ik een query dan uit wil voeren dan geef ik het query object door aan mijn database driver. die zorgt dan dat de query uitgevoert wordt.
ik zit nu meer de dubben over wat ik het beste met het query resultaat kan doen. moet ik dat opslaan in een resultobject (dan kun je dus lazy-loading toepassen), of moet ik gewoon gaan werken met de native resultset die de database me teruggeeft? ik weet nog niet wat nou de beste aanpak is.
en wat bedoel je precies met het ondersteunen van die relaties?

@whoami
zou je mssn een voorbeeld kunnen geven wanneer lazyloading noodzakelijk is. en wat voor extra complexiteit levert dat lazyloading dan zoal op? dat zie ik nog niet echt

[Brakkie]

of moet ik gewoon gaan werken met de native resultset die de database me teruggeeft

Als je een abstractie layer wilt die echt database onafhankelijk is moet je dit resultaat wel gaan bewerken want er zijn verschillen in de manier waarop database systemen hiermee omgaan. Oracle schijnt alle veldnamen uppercase terug te geven. Ook geeft oracle lege strings terug als null. Wanneer je hier dus geen wrapper voor maakt kan je zonder code veranderingen geen andere database aan je applicatie hangen.

Deze zaken heb ik trouwens van de site van de orm die ik eerder in dit topic noemde.

[Verwijderd]

whoami schreef op dinsdag 26 december 2006 @ 15:29:
[...]

Hier wil ik toch even op inpikken.
Lazy Load kan in bepaalde omstandigheden best handig of noodzakelijk zijn; maar het zorgt toch in veel gevallen voor wat extra complexiteit (bij het ontwikkelen dan). Lazy Load voor collecties gebruik ik echt als het moet / noodzakelijk is. Nu en dan ben ik ook eens met NHibernate bezig, en daar gebruik ik het zelfs liever niet.

Wat wordt strikt genomen eigenlijk verstaan onder Lazy Load? Volgens Fowler "An object that does not contain all of the data you need but knows how to get it". Misschien is in het geval wat ik eerder noemde Lazy Load een beetje dubieus, maar het kan nooit kwaad.
Lazy Load is handig wanneer je van een author meerdere books kan schrijven.

code:

$author = AuthorPeer::retrieveByPk(4);
$name = $author->getName();
$books = $author->getBooks();
$iter = $books->iterator();
while ($iter->hasNext() && $book = $iter->next()) {
  $title= $book->getTitle();
  sprintf('%s has written book %s', $name, $title);
}

In dit geval wil je toch echt dat alle boeken pas opgehaald worden wanneer je ook daadwerkelijk door de Books van de Author wil iteraten. Je wil niet dat op het moment dat je $author initialiseert, het object ook meteen alle boeken ophaalt.

[Verwijderd]

tombo_inc schreef op dinsdag 26 december 2006 @ 16:00:
ik zit nu meer de dubben over wat ik het beste met het query resultaat kan doen. moet ik dat opslaan in een resultobject (dan kun je dus lazy-loading toepassen), of moet ik gewoon gaan werken met de native resultset die de database me teruggeeft? ik weet nog niet wat nou de beste aanpak is.
en wat bedoel je precies met het ondersteunen van die relaties?

Als ik even een ruw opzetje geef:

code:

class MySqlDatabase extends Database
{
  var $connected = false;

  function connect($hostname, $username, $password, $database) { ... }
  function connected() { ... }

  function query($sql) {
    return new MySqlResultSet(mysql_query($sql));
  }

  function &getInstance() {
    static $instance = null;
    if (is_null($instance)) {
      $instance = new MySqlDatabase();
    }
    return $instance;
  }
}

class ResultSet
{
  var $result = null;

  function &getResult() {
    return $this->result;
  }

  function iterator() { }
  function length() { }
}

class MySqlResultSet extends ResultSet
{
  var $length;

  function MySqlResultSet($result) {
    $this->result = $result;
    if (!is_bool($result)) {
      $this->length = mysql_num_rows($result);
    }
  }

  function iterator() {
    return new MySqlResultSetIterator(&$this);
  }

  function length() {
    return $this->length;
  }
}

class Iterator
{
  ... some implementation ...
}

class MySqlResultSetIterator extends Iterator
{
  function MySqlResultSetIterator(&$resultSet) {
    $this->object = &$resultSet;
    $this->reset();
    $this->length = $resultSet->length();
  }

  function reset() {
    parent::reset();

    $resultSet = &$this->object;
  }

  function hasNext() {
    return $this->position <= $this->length;
  }

  function next() {
    $this->position++;

    $resultSet = &$this->object;
    return mysql_fetch_array($resultSet->getResult());
  }
}

Dit is voor zover ik het begrijp zie Lazy Load. Op het moment dat de next() aangeroepen wordt, krijg je een mysql array... Het is gewoon wat voorbeeld code, dus pin me er niet op vast dat dit werkt. Daarnaast wil je ook niet dat next() een gewone array retourneert, maar er moet een object geretourneerd worden die goed gepopulate is.

[whoami]

Ik weet wel wat lazy loading is hoor.

De vraag is ook: wil je wel dat je Author class een collectie heeft van de boeken die hij geschreven heeft Op die manier heb je meestal een 2-wegs relatie in je object-model: je author heeft een collectie van boeken die hij geschreven heeft, je boek object heeft een referentie naar de author die het boek geschreven heeft.
Hoeveel keer ga je, als je je author object gebruikt, die collectie van boeken moeten gebruiken. Hoeveel keer ga je via author naar de boeken collectie moeten gaan ? Is het dan de moeite om die collectie mee op te halen met je author object (ook al is het via lazy loading ? )
In de meeste (dergelijke) gevallen is het gewoon makkelijker om in je boeken repository (of whatever je hebt om je DB access een beetje te abstraheren) een method te hebben die er als volgt uit ziet:

code:

BookCollection GetBooksFromAuthor ( Autor a );

Op die manier zal je je ontwerp een pak vereenvoudigen, ga je geen problemen hebben met evt updaten van cross-referenties, etc... Althans, dat vind ik.

Maar goed, dit is ontwerp, en dit is van applicatie tot applicatie afhankelijk.

[Verwijderd]

whoami

Het was ook niet naar jou gericht, maar meer voor de KB van GoT Het probleem wat jij aangeeft probeert een vriend van mij ook te overwinnen op dit moment. Hij houdt zich bezig met het O/R Mapping gedeelte van ons Framework.

whoami schreef op dinsdag 26 december 2006 @ 18:18:
je author heeft een collectie van boeken die hij geschreven heeft, je boek object heeft een referentie naar de author die het boek geschreven heeft.

Dat is inderdaad een terecht probleem waar wij ook mee zitten. Aangezien van een formele specificatie toch code gegenereerd zal worden, vinden wij het geen probleem dat het er min of meer dubbel in staat.

Dit gaat nu wel in op een heel specifiek gedeelte van de O/R Mapper, en zoals ik begrijp zoekt TS alleen maar een soort van wrapper classes om query's SQL onafhankelijk te definieren. Misschien splitsen?

[tombo_inc]

Verwijderd schreef op dinsdag 26 december 2006 @ 18:30:
Dit gaat nu wel in op een heel specifiek gedeelte van de O/R Mapper, en zoals ik begrijp zoekt TS alleen maar een soort van wrapper classes om query's SQL onafhankelijk te definieren. Misschien splitsen?

Dat klopt, een O/R mapper is ook leuk maar dat is iets voor de volgende keer .

Maar als ik het goed begrijp moet ik dus wel een resultset object gaan gebruiken aangezien de resultsets die verschillende databases retourneren ook verschillend zijn. in mijn resultset object moet ik dan de resultset die de DB uitspuugt zo gaan omvormen zodat deze er altijd hetzelfde uitziet voor de rest van mijn applicatie.

wat betreft dat lazyloading, ik snap het idee wel het is me alleen nog niet zo duidelijk wanneer je dat nou nodig hebt. je zou toch denken dat wanneer je gegevens ophaalt uit je database dat je ze dan ook meteen nodig hebt.

[BertS]

tombo_inc schreef op woensdag 27 december 2006 @ 15:21:
[...]
wat betreft dat lazyloading, ik snap het idee wel het is me alleen nog niet zo duidelijk wanneer je dat nou nodig hebt. je zou toch denken dat wanneer je gegevens ophaalt uit je database dat je ze dan ook meteen nodig hebt.

Als je een lijst met orders ophaalt en vervolgens een specifieke order wilt openen, dan wil je bij het openen van die order ook de klantinformatie en de orderregels ophalen. Maar die heb je niet nodig in je collectie die je gebruikt voor de selectie van de te openen order.

[Genoil]

Ik blijf het maar paradoxaal vinden. Je gaat een DBAL schrijven voor 1 webapplicatie? Hoeveel drivers ben je van plan te gaan implementeren? Verder geef je aan dat je snelheid belangrijk vind, terwijl een DBAL per definite overhead geeft. Nouja, onder het mom van leerzaamheid is het natuurlijk prima, maar ik kan leukere oefeningen bedenken dan een DBAL

Ik denk dat het goed is om wat research te doen naar de al bestaande bekende DBALs in PHP, zoals adodb, Pear::DB en Creole. Het zal daarna moeilijk worden met iets heel origineels op de proppen te komen, maar dat is je uitdaging begrijp ik .

Wat betreft lazy-loading, ik vind dat dat niet in een DBAL thuishoort maar bij een OR Mapper.