Das .dba-Schemaformat und die mitgelieferten Schemadateien #

Diese Seite richtet sich an Datenbankadministratoren, die wissen möchten, woher die Definition einer Exponential-Datenbank kommt, bevor sie eine vergleichen, dumpen oder umziehen. Sie beantwortet: was eine .dba-Datei ist, welche Schemadateien mit dem Kernel ausgeliefert werden und welches Werkzeug jede liest, wie Erweiterungen Tabellen hinzufügen und was Namen auf jeder Engine gültig hält.

Inhalt #

1. Das Format .dba
2. Die mitgelieferten Dateien
3. Schema-Handler
4. Erweiterungen und ihr Schema
5. Der Lint-Checker
6. Was Sie mit diesen Dateien tun
7. Checkliste

Das Format .dba #

Eine .dba-Datei ist eine PHP-Datei, die ein Array enthält: für das Schema einen Eintrag je Tabelle mit ihren Feldern (Typ, Länge, not_null, Standard) und Indizes; für Daten die Zeilen. Sie beschreibt die Datenbank ohne den Dialekt einer Engine, eine Datei dient also jeder Engine. Der Anfang von share/db_schema.dba sieht so aus:

<?php
// This array contains the database schema
$schema = array (
  'expaudit_cursor' =>
  array (
    'name' => 'expaudit_cursor',
    'fields' =>
    array (
      'byte_offset' =>
      array (
        'length' => 20,
        'type' => 'bigint',
        ...

ezsqldumpschema.php --format=generic --output-array schreibt dieses Format aus einer laufenden Datenbank (Schemawerkzeuge: Dump, Insert und Diff). --format=local schreibt einen Dump, der nur zu der Engine passt, aus der er stammt.

Die mitgelieferten Dateien #

Schema-Handler #

settings/dbschema.ini [SchemaSettings] ordnet einem Typ eine Handler-Klasse zu:

Ein Handler schreibt DDL aus einem .dba-Schema und liest eine laufende Datenbank in eines zurück. Indexnamen gelten auf SQLite und PostgreSQL datenbankweit; die Handler legen einen kollidierenden Namen als <table>__<name> an. Auf PostgreSQL legt der Handler jede Sequenz vor ihrer Tabelle an, und nach dem Laden von Daten korrigiert der Schema-Installer die Sequenzen (PostgreSQL betreiben).

Erweiterungen und ihr Schema #

Eine Erweiterung mit Tabellen liefert ihre eigene share/db_schema.dba (und oft sql/<engine>/*.sql). Die Upgrade-Prüfung liest die share/db_schema.dba jeder aktiven Erweiterung, und die Schemas installierter, aber inaktiver Erweiterungen nur, um Ihnen zu sagen, zu welcher Erweiterung eine Tabelle gehört (Das Schema nach einem Upgrade prüfen). Einige Datentypen liefern eigene Daten: bin/php/ezimportdbafile.php --datatype=<name> importiert sie (Beispiel aus seiner Hilfe: --datatype=ezisbn).

Der Lint-Checker #

dbschema.ini [LintChecker] begrenzt die Länge von Namen, damit das Schema auf Engines mit kurzen Bezeichnern gültig bleibt: TableLimit=26, FieldLimit=30, IndexLimit=30, mit Listen historischer Ausnahmen (IgnoredTables[], IgnoredFields[], IgnoredIndexes[]). ezsqldiff.php --lint-check prüft eine Datenbank gegen diese Regeln, statt zwei Schemas zu vergleichen. Entwickler von Erweiterungen sollten ihre Namen innerhalb der Grenzen halten.

Was Sie mit diesen Dateien tun #

• Bearbeiten Sie nie share/db_schema.dba oder die Dateien in kernel/sql/: Ein Upgrade ersetzt sie.
• Vergleichen Sie Ihre Datenbank nach einem Upgrade mit share/db_schema.dba.
• Ziehen Sie eine Website zwischen SQL-Engines um, indem Sie nach .dba dumpen und mit einem anderen --type einfügen (Eine Website auf eine andere Engine umziehen).
• Bewahren Sie einen .dba-Dump Ihrer eigenen Datenbank als portables zweites Sicherungsformat neben dem nativen Dump der Engine auf.

Checkliste #

• To do: Sie wissen, welche Schemadatei jedes Werkzeug liest.
• To do: Ihre eigenen Erweiterungen liefern eine share/db_schema.dba für ihre Tabellen.
• To do: Die Namen in Ihren Erweiterungen bestehen ezsqldiff.php --lint-check.

Verwandte Seiten #

• Schemawerkzeuge: Dump, Insert und Diff
• Die Tabellen, die ein Datenbankadministrator kennen sollte
• Die Datenbankschicht auf einer Seite
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.