De kern van de meeste applicaties wordt gevormd door de aanwezige data. Die kunnen op veel verschillende manieren worden opgeslagen, maar bij meer complexe toepassingen zal er vrijwel altijd sprake zijn van een database. ZF zou natuurlijk onvolledig zijn als er niet een uitgebreide serie componenten beschikbaar was om toegang te bieden tot de database, zijn tabellen en gegevens.

Twee klassen zijn met name van belang: Zend_Db_Table_Abstract, en Zend_Db_Table_Row_Abstract. De eerste biedt een aantal methoden om toegang te krijgen tot de rijen gegevens in een tabel; de tweede tot de eigenschappen (de kolommen) van een afzonderlijke rij.

Opbouw van de database

Voordat we ons gaan richten op de interactie tussen de elesio en de database, moeten we eerst de juiste tabellen inrichten. Dat doen we op basis van de beschrijving in hoofdstuk 2, ‘Uitwerking van het concept’. In Mysql Workbench, het freeware GUI programma van Mysql, heb ik dit schema gemaakt:

Klik op de afbeelding om haar in groter formaat te zien.

Centraal in het schema staan twee tabellen, products en articles.

1. Products is de moeder van twee afgeleide tabellen, books en gadgets. Boeken en apparaten worden beschouwd als de twee concrete producttypes die besproken kunnen worden op onze website. Die delen een aantal eigenschappen die in de moedertabel worden opgeslagen: het ean (een uniek productnummer, vergelijkbaar met het vroegere ISBN; maar dan algemener), de prijs, de invoerdatum, een herzieningsdatum, en een gemiddelde waardering van de gebruiker. Books en gadgets voeren daar nog hun specifieke eigenschappen aan toe, zoals titel, auteur, producent enzovoorts. Via de index products_id wordt de relatie gelegd met products tabel. De relatie tussen books en gadgets enerzijds en products anderzijds is één op één.
2. In articles wordt alle content opgeslagen. Over elk product kunnen meerdere artikelen worden geschreven. Die relatie wordt belichaamd door de vreemde sleutel products_id in articles. Bovendien kan een artikel alleen worden geschreven door een geregistreerde gebruiker. Deze bevindt zich in de users tabel, en komt terug in de article tabel door de vreemde sleutel users_id.
3. Er zijn voor de users vier verschillende rollen gedefinieerd: unconfirmed, registered, writer, admin. Wie zich registreert, is in eerste instantie een nieuwe, unconfirmed gebruiker. Zodra hij op de link in een bevestigingsmail klikt, wordt hij registered. Daarna is het aan de admin om een registered user te promoveren tot writer of zelfs tot admin. We hebben nog niet de exacte verschillen tussen deze rollen gedefinieerd, maar we willen onze applicatie toekomstbestendig maken; daarom is het handig om onze database daarop nu al in te richten. Wachtwoorden in onze applicatie worden versleuteld opgeslagen (sha1). Continue reading →