Databases voor Joomla

1. De basis

1.1 Wat is een database?

Een database is een geordende opslag van informatie die andere programma's snel kunnen lezen en schrijven. Joomla gebruikt een relationele database, die gegevens in tabellen bewaart. Elke tabel heeft kolommen (de velden) en rijen (de records). Een artikel is een rij in een tabel met artikelen; een gebruiker is een rij in een tabel met gebruikers.

De software die deze tabellen beheert, is de database-engine (ook wel databaseserver of DBMS genoemd). Joomla bewaart de gegevens niet zelf; het vraagt de engine om dat te doen, met een taal die SQL heet (Structured Query Language).

1.2 Waarom Joomla er een nodig heeft

Een Joomla-pagina is geen bestand op schijf. Als een bezoeker een artikel opent, draait Joomla PHP die een SQL-query naar de database stuurt, het resultaat leest en de HTML ter plekke opbouwt. Bijna alles wat je in de beheeromgeving beheert, staat in de database:

• Inhoud: artikelen, categorieen, tags, contacten en aangepaste velden.
• Structuur: menu's, modules en hun posities.
• Mensen: gebruikers, groepen en toegangsniveaus.
• Configuratie: de meeste extensie-instellingen en de lijst met geinstalleerde extensies.

Een klein aantal dingen staat juist als bestand, bijvoorbeeld media-uploads, het bestand configuration.php en templatecode. Al het andere staat in de database.

1.3 Waar de database draait

De database-engine draait meestal op dezelfde server als je site, of op een aparte databaseserver ernaast. Joomla maakt er verbinding mee via een netwerksocket met een hostnaam, een gebruikersnaam, een wachtwoord en een databasenaam. Die vier waarden stel je eenmalig in tijdens de installatie, en Joomla bewaart ze in configuration.php.

3. MySQL en MariaDB

3.1 De standaardkeuze

De grote meerderheid van de Joomla-sites draait op MySQL of MariaDB. Dit zijn de databases die bij vrijwel elk shared hosting-account en elke cPanel-server zitten, en het is wat een verse Joomla-installatie verwacht. Als je niets bijzonders doet, is dit wat je krijgt.

3.2 MariaDB is een fork van MySQL

MariaDB begon als een community-fork van MySQL nadat Oracle MySQL had overgenomen, en de oorspronkelijke MySQL-ontwikkelaars bouwden hem. Voor Joomla zijn ze vrijwel uitwisselbaar: dezelfde SQL, dezelfde tabelindeling, dezelfde Joomla-driver. Joomla detecteert met welke van de twee het praat en past automatisch een paar details aan. Veel hosts leveren tegenwoordig standaard MariaDB en noemen dat gewoon "MySQL".

3.3 MySQLi versus PDO MySQL

Joomla biedt twee manieren om verbinding te maken met een MySQL- of MariaDB-database, en je kiest er een tijdens de installatie:

Voor vrijwel alle sites maakt het verschil niet uit. MySQLi is de veilige standaard. Beide praten met dezelfde database en slaan gegevens op dezelfde manier op, dus je kunt ertussen wisselen door een regel in configuration.php te wijzigen, zolang de bijbehorende PHP-extensie is geinstalleerd.

3.4 Minimale versies

Joomla 6.x vereist MySQL 8.0.13 of hoger (aanbevolen: MySQL 8.4), of MariaDB 10.4 of hoger (aanbevolen: MariaDB 12.0), zie: Joomla! Programmers Documentation: Requirements for Joomla! 6.x. Oudere versies die je soms ziet (MySQL 5.6, MariaDB 10.0) zijn de ondergrens van de onderliggende joomla/database-bibliotheek, niet de eis van het moderne CMS; een Joomla 6-site draait er niet op. Draai een actuele, ondersteunde release voor betere snelheid, beveiliging en volledige utf8mb4-ondersteuning. Een host die nog MySQL 5.7 of een oude MariaDB aanbiedt, draait software die zijn beste tijd heeft gehad, en je zou moeten upgraden of verhuizen voordat je Joomla 6 installeert.

5. SQLite en Microsoft SQL Server

5.1 SQLite: de bestandsgebaseerde engine

SQLite is bijzonder: het is helemaal geen server. De hele database is een enkel bestand op schijf, en de engine draait binnen de applicatie die hem opent. Er valt niets te installeren of via een netwerk te benaderen, wat het perfect maakt voor testen, geautomatiseerde testsuites en kleine embedded tools.

Het framework van Joomla levert een SQLite-driver mee, en het Joomla-project gebruikt SQLite intern voor sommige van zijn eigen geautomatiseerde tests. Maar het Joomla-CMS levert geen SQLite-installatieschema, dus je kunt er geen normale Joomla-website op draaien. Beschouw de SQLite-driver als een tool voor ontwikkelaars en het framework, niet als een hostingoptie.

5.2 Microsoft SQL Server en Azure SQL

Het framework levert ook drivers voor Microsoft SQL Server (sqlsrv) en Azure SQL (sqlazure), beide gemeld als servertype mssql. Net als bij SQLite heeft het CMS geen MSSQL-installatie- of updateschema, dus deze drivers bestaan voor maatwerkapplicaties op het Joomla-framework, niet voor een standaard Joomla-site. Als een host of artikel suggereert om Joomla op SQL Server te installeren, wees dan voorzichtig: het ondersteunde pad voor een Microsoft-omgeving is MySQL of MariaDB op Windows draaien, of IIS voor een MySQL-database zetten.

5.3 De praktische conclusie

Voor een echte Joomla-website zijn je echte keuzes MySQL, MariaDB of PostgreSQL. SQLite en SQL Server zijn alleen relevant als je een ontwikkelaar bent die een maatwerkapplicatie bovenop het Joomla-framework bouwt.

7. Hoe Joomla verbinding maakt met de database

7.1 Het bestand configuration.php

Joomla bewaart de databaseverbindingsgegevens in het rootbestand configuration.php, ingesteld tijdens de installatie. Vijf instellingen bepalen de verbinding:

public $dbtype = 'mysqli';        // de driver: mysqli, pdomysql of pgsql
public $host = 'localhost';       // adres van de databaseserver
public $user = 'joomla_user';     // databaseaccount
public $password = 'secret';      // het wachtwoord
public $db = 'joomla_site';       // de databasenaam
public $dbprefix = 'abcd1_';      // de tabelprefix (zie sectie 8)

De waarde $dbtype is de drivernaam uit sectie 2. Om een MySQL-site van MySQLi naar PDO over te zetten, wijzig je hier mysqli in pdomysql, mits de PHP-extensie pdo_mysql is geinstalleerd. Omdat dit bestand het wachtwoord in platte tekst bevat, mag de webserver het nooit serveren; Joomla en een correcte serverconfiguratie houden het afgeschermd.

7.2 De host-waarde

De $host is meestal localhost of 127.0.0.1 als de database op dezelfde machine draait. Managed en cloudhosting geeft je vaak een aparte hostnaam en soms een poort, geschreven als host:poort. Sommige opstellingen verbinden via een Unix-socket in plaats van TCP. Je host vertelt je de juiste waarde; een verkeerde host is de meest voorkomende oorzaak van "Could not connect to the database" tijdens de installatie.

7.3 Wat er bij elke aanvraag gebeurt

Als er een aanvraag binnenkomt, leest Joomla configuration.php, laadt de bijbehorende driver en opent een verbinding met de engine. Elke query in die aanvraag gaat over die ene verbinding, en Joomla sluit hem als de aanvraag eindigt. Daarom maakt een trage of overbelaste database de hele site traag: elke pagina wacht erop.

7.4 Verbinden met een database op afstand

Als je lokaal ontwikkelt maar wilt werken tegen een database op een server op afstand, heb je twee manieren om hem te bereiken, en die hebben heel verschillende beveiligingsprofielen.

Directe verbinding met een IP-allowlist. Je wijst Joomla rechtstreeks naar de server op afstand door $host op zijn adres en poort te zetten, bijvoorbeeld db.example.com:3306. Hiervoor moet de database op afstand verbindingen van buitenaf accepteren, moet de firewall jouw IP-adres toestaan en moet de databasegebruiker vanaf dat adres mogen verbinden. Dit is eenvoudig, maar het stelt de databasepoort bloot aan het internet en gaat stuk zodra je thuis- of kantoor-IP verandert.

SSH-tunnel (de veiligere optie). In plaats van de database voor de hele wereld open te zetten, stuur je een lokale poort via SSH door naar de server op afstand. Joomla verbindt dan met die lokale poort alsof de database op je eigen machine staat. Je opent de tunnel met een commando:

ssh -N -L 3307:127.0.0.1:3306 Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.

Dit koppelt lokale poort 3307 aan 127.0.0.1:3306 zoals de server op afstand die ziet, dus zijn eigen MySQL. Wijs Joomla nu naar het lokale uiteinde van de tunnel:

public $host = '127.0.0.1:3307';   // lokale uiteinde van de SSH-tunnel
public $user = 'remote_db_user';
public $password = 'remote_db_password';
public $db = 'remote_db_name';

Omdat de tunnel eindigt op de server op afstand, ziet MySQL de verbinding alsof die van zijn eigen localhost komt, zodat het databaseaccount beperkt kan blijven tot localhost en de databasepoort nooit naar het internet hoeft te wijzen. Alleen SSH (met sleutel-authenticatie) staat open, en daarom is een tunnel veiliger dan de poort openzetten en een IP op een allowlist plaatsen.

Twee belangrijke details:

• Gebruik 127.0.0.1, niet localhost. De MySQLi-driver behandelt het letterlijke woord localhost als een verzoek om een Unix-socket en negeert de poort, waardoor de tunnel wordt omzeild. 127.0.0.1 dwingt een echte TCP-verbinding naar de doorgestuurde poort af.
• De SSH-inloggegevens staan niet in Joomla. De SSH-host, gebruiker en sleutel staan in je SSH-client (het commando hierboven of een vermelding in ~/.ssh/config), nooit in configuration.php. Joomla ziet alleen de databaseverbinding met 127.0.0.1:3307. Dit zijn twee aparte logins: SSH authenticeert de tunnel, de databasegegevens authenticeren Joomla.

Houd de tunnel open zolang Joomla draait; als hij wegvalt, meldt Joomla meteen "Could not connect to the database". Een tool als autossh opent hem automatisch opnieuw. Onthoud ook dat je op live data werkt, dus behandel destructieve acties met dezelfde zorg als op productie.

9. Tekensets en collation

9.1 Waarom codering ertoe doet

Een tekenset bepaalt welke tekens de database kan opslaan; een collation bepaalt hoe hij ze sorteert en vergelijkt. Als dit fout gaat, veranderen letters met accenten, emoji of niet-Latijnse schriften in vraagtekens of mojibake, en gaat het sorteren raar. Joomla streeft naar volledige Unicode zodat een site elke taal aankan.

9.2 Hoe collation het sorteren verandert

Collation gaat niet alleen over opslag; het bepaalt de volgorde van een alfabetische lijst, en die volgorde hangt af van de taal. Dezelfde woorden sorteren anders onder een algemene (ASCII/Engelse) collation dan onder een taalspecifieke. Een klassiek voorbeeld is de Zweedse stad Örebro:

• Algemene (ASCII/Engelse) collation: Ö wordt behandeld als een gewone O, dus "Örebro" wordt gesorteerd alsof het "Orebro" is en belandt tussen de O-vermeldingen.
• Zweedse collation: Ö is een aparte letter die na Z komt. Het Zweedse alfabet eindigt met X, Y, Z, Å, Ä, Ö, dus "Örebro" sorteert bijna helemaal achteraan in de lijst.

Het effect op een lijst met plaatsnamen is goed te zien:

Daarom kan een meertalige Joomla-site een categorie- of taglijst tonen in een volgorde die voor een moedertaalspreker verkeerd lijkt: de database sorteert correct, alleen onder de verkeerde collation voor die taal. De oplossing is de collation af te stemmen op de taal van de inhoud in plaats van alles op een enkele algemene collation te laten.

9.3 utf8mb4 op MySQL en MariaDB

Op MySQL en MariaDB gebruikt Joomla utf8mb4, de vier-byte UTF-8-codering die elk Unicode-teken kan opslaan, inclusief emoji. De oudere utf8 in MySQL is eigenlijk maar drie bytes en kan geen emoji of sommige Aziatische tekens opslaan, wat jarenlang voor subtiele bugs zorgde. Joomla controleert de databaseversie en zet utf8mb4-ondersteuning aan zodra de server nieuw genoeg is (MySQL of MariaDB vanaf de 5.5.3-generatie). Een typische Joomla-tabel gebruikt de collation utf8mb4_unicode_ci, waarbij ci staat voor hoofdletterongevoelig (case-insensitive).

9.4 Het detail van de null-datum

Elke engine vertegenwoordigt een "lege" tijdstempel anders, en Joomla kent de juiste waarde per driver. Op MySQL en MariaDB is de historische null-datum 0000-00-00 00:00:00; als de server in strict mode draait die nuldatums verbiedt, gebruikt Joomla in plaats daarvan 1000-01-01 00:00:00. PostgreSQL gebruikt 1970-01-01 00:00:00 en SQL Server 1900-01-01 00:00:00. Dit is onzichtbaar in dagelijks gebruik, maar het verklaart waarom je nooit 0000-00-00 hard in je eigen query's moet zetten. Vraag de driver in plaats daarvan om de null-datum, met $db->getNullDate().

Modern Joomla is waar het kan afgestapt van de nuldatum-vervanger. Veel datumkolommen zijn nu nullable, en een lege datum wordt opgeslagen als een echte SQL-NULL in plaats van 0000-00-00; een actueel Joomla 6-schema geeft geen enkele kolom meer standaard een nuldatum. De null-datum die getNullDate() teruggeeft, blijft van belang voor de kolommen die niet-nullable zijn, bijvoorbeeld created in #__content. De veilige regel heeft dus twee delen: vergelijk met $db->getNullDate() voor niet-nullable datumkolommen, en controleer op SQL-NULL bij de nullable kolommen, in plaats van ooit met de hand 0000-00-00 te schrijven.

11. Query's schrijven op de Joomla-manier

11.1 De query builder

Handgeschreven SQL-strings zijn kwetsbaar en makkelijk fout te krijgen, vooral rond quoting. Joomla biedt een query builder die correcte, overdraagbare SQL voor de actieve engine schrijft. Je haalt een lege query op met $db->getQuery(true) en ketent er methodes aan:

use Joomla\CMS\Factory;
use Joomla\Database\DatabaseInterface;
use Joomla\Database\ParameterType;

$db    = Factory::getContainer()->get(DatabaseInterface::class);
$query = $db->getQuery(true);

$query->select($db->quoteName(['id', 'title']))
      ->from($db->quoteName('#__content'))
      ->where($db->quoteName('state') . ' = :state')
      ->order($db->quoteName('created') . ' DESC');

$query->bind(':state', 1, ParameterType::INTEGER);

$db->setQuery($query);
$articles = $db->loadObjectList();

11.2 Quote namen en bind waarden

Twee regels houden je query's veilig en overdraagbaar:

• Quote identifiers (tabel- en kolomnamen) met $db->quoteName(). Het voegt het juiste quote-teken voor de engine toe, backticks op MySQL en dubbele aanhalingstekens op PostgreSQL.
• Bind waarden met benoemde parameters en bind(), of quote ze met $db->quote(). Plak nooit een rauwe waarde uit een formulier rechtstreeks in SQL.

11.3 Waarom dit SQL-injectie tegenhoudt

SQL-injectie is de aanval waarbij een gebruiker SQL in een formulierveld typt en de server het uitvoert. Parameters binden verslaat dit, want een gebonden waarde wordt altijd als data behandeld, nooit als code. De query builder is niet alleen netjes; het is de eerste verdedigingslinie van Joomla's databasebeveiliging. De meeste meldingen van datalekken in Joomla-extensies zijn terug te voeren op een query die deze stap oversloeg.

13. Schema-updates en migraties

13.1 Hoe Joomla de database wijzigt

Als Joomla of een extensie wordt bijgewerkt, heeft de nieuwe versie vaak nieuwe kolommen of tabellen nodig. Joomla past deze wijzigingen toe via geversioneerde SQL-updatebestanden. De kernbestanden staan in administrator/components/com_admin/sql/updates/, opgesplitst per engine in de mappen mysql/ en postgresql/, met een bestand per wijziging benoemd naar versie en datum.

13.2 Het database-reparatieprogramma

Soms wordt een update onderbroken, of raakt een database uit de pas met de versie die Joomla verwacht. Joomla heeft een ingebouwde controle bij Systeem → Onderhoud → Database. Het vergelijkt je werkelijke schema met het schema dat de geinstalleerde versie zou moeten hebben en biedt een knop Herstel die de ontbrekende wijzigingen uitvoert. Zie je ooit "Database schema is not up to date", dan is dit de pagina die het repareert.

13.3 De command line

Hetzelfde onderhoud bestaat op de command line, handig voor geautomatiseerde deployments:

php cli/joomla.php maintenance:database

Dit controleert het schema en meldt of repareert problemen zonder de beheeromgeving te openen. Het is het database-equivalent van een vastgelopen update met de hand vlottrekken.

13.4 Extensies doen hetzelfde

Goed gebouwde extensies leveren hun eigen SQL-updatebestanden en een installatiescript mee, zodat het installeren van een nieuwe versie hun tabellen automatisch bijwerkt. Daarom werk je extensies bij via het Joomla-installatieprogramma in plaats van bestanden eroverheen te kopieren: het installatieprogramma voert de schemawijzigingen uit die losse bestanden zouden overslaan.

15. Performance en tuning

15.1 Indexen zijn de grote hefboom

Een index is een opzoekstructuur waarmee de database rijen vindt zonder de hele tabel te doorlopen, net als de index achter in een boek. De kerntabellen van Joomla zijn goed geindexeerd. De performanceproblemen waar mensen tegenaan lopen, komen meestal van grote maatwerktabellen of extensies die niet-geindexeerde kolommen bevragen. Als een bepaalde pagina traag is, is de oorzaak vaak een query zonder index. Indexen zijn niet gratis: elke index versnelt het lezen maar voegt een beetje kosten toe aan elke insert en update, dus indexeer de kolommen waarop je zoekt en filtert, niet elke kolom.

15.2 De trage query's vinden

Zet Joomla's Debug-modus aan in de Globale configuratie, en de Debug-plugin toont elke query die een pagina draaide, met tijden. De database-engine kan ook trage query's loggen (de slow query log van MySQL). Samen vertellen ze je precies welke query je moet aanpakken, in plaats van gissen.

15.3 Lees het queryplan met EXPLAIN

Zodra je weet welke query traag is, vraag de database waarom. Elke engine heeft een query planner die bepaalt hoe een query wordt uitgevoerd, en je ziet zijn plan door EXPLAIN voor de query te zetten:

EXPLAIN SELECT title FROM #__content WHERE state = 1;

De uitvoer vertelt je of de database een index gebruikt of de hele tabel doorloopt (let op "ALL", wat een volledige tabelscan betekent). Op PostgreSQL gaat EXPLAIN ANALYZE verder en draait de query echt om reele tijden te melden. Dit is de nuttigste gewoonte om een trage query te diagnosticeren: gis niet of een index helpt, meet het.

15.4 Caching spaart de database

De snelste query is degene die je nooit draait. Joomla's caching (de System - Page Cache-plugin en view-caching) bewaart opgebouwde pagina's en queryresultaten zodat herhaalbezoeken de database helemaal overslaan. Op een drukke site haalt dit enorm veel belasting van de engine. Combineer het met een persistente cache-opslag als Redis of Memcached voor het beste effect.

15.5 Geef de engine ruimte

Een database-engine is veel sneller als hij de werkgegevens in het geheugen kan houden. Op een managed host is dit voor je afgesteld; op je eigen server bepalen instellingen als MariaDB's innodb_buffer_pool_size hoeveel van de database in RAM gecachet blijft. Genoeg geheugen voor de engine doet vaak meer voor de snelheid dan welke losse Joomla-instelling ook.

15.6 Een echt voorbeeld: DISTINCT vermijden

Een les uit de ontwikkeling van de Joomla-core zelf laat zien waarom de vorm van een query meer uitmaakt dan de engine eronder. Toen ik in 2015 de functie Category Item Count voor Joomla ontwikkelde, gebruikte mijn eerste versie het SQL-sleutelwoord DISTINCT om dubbele rijen te verwijderen. Op kleine sites werkte het prima. Maar mensen met heel grote sites, veel categorieen met elk een enorm aantal artikelen, meldden ernstige vertragingen.

De reden is dat DISTINCT de database dwingt uit te zoeken welke rijen dubbel zijn voordat hij een resultaat kan teruggeven, vaak met extra sortering, een tijdelijke tabel of hashing. Op een grote dataset wordt dat duur. De query is later herschreven om hetzelfde resultaat zonder DISTINCT te leveren, en de vertraging verdween.

Een query die er elegant uitziet, is niet altijd de snelste query.

Als je SQL voor een Joomla-extensie schrijft en je naar DISTINCT grijpt om dubbele rijen te verbergen, stop dan en vraag waar de dubbelingen vandaan komen. Vaak haalt een betere JOIN, een selectievere WHERE, een GROUP BY of een extra index de noodzaak ervan helemaal weg. En bevestig altijd met EXPLAIN (MySQL en MariaDB) of EXPLAIN ANALYZE (PostgreSQL) in plaats van aan te nemen dat de query al optimaal is.

17. Veelgemaakte fouten en valkuilen

17.1 Verkeerde verbindingsgegevens

Symptoom: de installatie of de site mislukt met "Could not connect to the database".

Oplossing: controleer de vier waarden in configuration.php tegen wat je host je gaf: host (vaak localhost of met een poort), gebruiker, wachtwoord en databasenaam. Een verkeerde host of een database die nog niet bestaat, is de gebruikelijke oorzaak.

17.2 PostgreSQL kiezen zonder extensies te controleren

Symptoom: de core werkt, maar een extensie van derden gooit SQL-fouten op PostgreSQL.

Oplossing: bevestig dat elke extensie PostgreSQL ondersteunt voordat je je vastlegt. Bij twijfel gebruik je MariaDB, waar het hele ecosysteem op mikt.

17.3 De valkuil utf8 versus utf8mb4

Symptoom: emoji of sommige tekens worden opgeslagen als vraagtekens, of een gemigreerde database toont mojibake.

Oplossing: zorg dat de database en tabellen utf8mb4 gebruiken, niet de oude drie-byte utf8. Zet een oudere database om naar utf8mb4 in plaats van hem op utf8 te laten.

17.4 Tabellen met de hand bewerken

Symptoom: gegevens zien er goed uit in phpMyAdmin, maar Joomla gedraagt zich vreemd, verliest toegangsrechten of toont verweesde items.

Oplossing: vermijd directe tabelbewerkingen. Joomla houdt samenhangende tabellen in de pas (assets, history, associaties); een rij met de hand wijzigen kan die koppelingen breken. Gebruik de beheeromgeving of de databaselaag.

17.5 Geen database in de back-up

Symptoom: een "back-up" zet de bestanden terug maar de site is leeg of blijft op een oude versie hangen.

Oplossing: maak altijd back-up van bestanden en de SQL-dump samen, en test een restore. Een kopie van alleen bestanden is geen Joomla-back-up.

17.6 De tabelprefix hardcoderen

Symptoom: maatwerk-SQL werkt op de ene site maar faalt op een andere met een andere prefix.

Oplossing: schrijf #__tabelnaam, nooit de letterlijke prefix. Joomla vervangt de echte prefix tijdens het draaien.

19. In het kort

ONDERSTEUND (CMS)  MariaDB, MySQL, PostgreSQL
ALLEEN DRIVER      SQLite, MS SQL Server, Azure SQL (frameworkapps)
DBTYPE-WAARDEN     mysqli, pdomysql, pgsql
SERVERTYPES        mysql, postgresql, mssql, sqlite
VEREISTEN          Joomla 6.x: MySQL 8.0.13+, MariaDB 10.4+, PostgreSQL 12.0+
VERBINDING         configuration.php: dbtype, host, user, password, db, dbprefix
TABELPREFIX        Schrijf #__tabel; Joomla zet de echte prefix erin
CODERING           utf8mb4 op MySQL/MariaDB (niet 3-byte utf8)
DRIVER OPHALEN     Factory::getContainer()->get(DatabaseInterface::class)
QUERY              $db->getQuery(true) + quoteName() + bind()
SERVERTYPE-CHECK   $db->getServerType()  // 'mysql' of 'postgresql'
STORAGE ENGINE     InnoDB voor alle kerntabellen (niet MyISAM)
TRANSACTIES        $db->transactionStart() / transactionCommit() / Rollback()
INTEGRITEIT        Joomla gebruikt geen DB-foreign-keys; in PHP afgedwongen
SCHEMABESTANDEN    administrator/components/com_admin/sql/updates/{mysql,postgresql}
SCHEMA HERSTELLEN  Systeem → Onderhoud → Database  (of CLI hieronder)
CLI                php cli/joomla.php maintenance:database
BACK-UP            Bestanden + SQL-dump samen (mysqldump / pg_dump)
SNELHEID           Indexen + caching (Page Cache, Redis) + enginegeheugen
DIAGNOSE           EXPLAIN (MySQL) / EXPLAIN ANALYZE (PostgreSQL); vermijd DISTINCT