[Postfixbuch-users] DB-Strukturen

[Christian Boltz]

Hallo Stefan, hallo Leute,

Am Donnerstag, 30. Oktober 2008 schrieb Stefan Förster:
> BTW, ich entschuldige mich schonmal für die Zeilenlänge.

Kein Problem, nur kommt dabei ein "interessantes" Quoting raus. Daher 
verzichte ich soweit möglich aufs Zitat der Tabellenstrukturen ;-)

Ich sollte außerdem vorwegschicken, dass ich durch die Datenbankstruktur 
von Postfixadmin "vorbelastet" bin ;-)  Von mir aus kannst Du Dir auch 
mal die Datenbankstruktur von Postfixadmin ansehen - da das Ziel 
(Domains, Mailboxen und Aliase verwalten) gleich ist, ist der 
Unterschied nicht allzu groß.

> mailsystem=> \d virtual_mailbox_domains

Passt.

[Extra Tabelle mit Logindaten, Quota usw.]

Was ist der Grund, das nicht in der virtual_mailbox_maps-Tabelle zu 
haben? Üblicherweise wirst Du sowieso eine 1:1-Zuordnung von Logindaten 
und Mailboxen haben.

> Als Login wollte ich nicht die eMail-Adresse benutzen. 

Geschmackssache - ein eigenens Feld für den Usernamen tut jedenfalls 
nicht weh. Andererseits ist die Regel "Mailadresse = Benutzername" für 
die User leicht zu merken ;-)

> Dazu dann die Mailboxen:
>
> mailsystem=> \d virtual_mailbox_maps
...
> domain    | integer               |
>  login     | integer               |
>  localpart | character varying(65) | not null

Die Aufsplittung von Localpart und Domain ist rein aus Sicht der 
Datenbank-Normalisierung sinnvoll. In der Praxis (Indexnutzung, 
Vereinfachung der Queries) kann es aber sinnvoll sein, die komplette 
Mailadresse in einem Feld zu haben.

Oder man nutzt ein *zusätzliches* Feld, das die komplette Mailadresse 
enthält - mit Triggern kann man sowas bequem aktuell halten.

>                                   Table "public.virtual_mailbox_maps"

Gleicher Hinweis wie oben - führt zu einer "interessanten" Query.
Da ist sie ja schon:

> query = SELECT (SUBSTR(vum.login, 1, 1) || '/' || vum.login ||
> '/Maildir/') AS mail FROM virtual_mailbox_domains vmd LEFT JOIN
> virtual_mailbox_maps vmm ON (vmd.id = vmm.domain) LEFT JOIN
> virtual_user_maps vum ON (vmm.login = vum.id) WHERE vmm.localpart =
> '%u' AND vmd.name='%d' AND vum.active;

Es mag Geschmackssache sein, aber mir wäre diese Query etwas zu lang für 
eine simple Mailbox-Abfrage.

> Soweit ist das alles ganz einfach, und es bleibt auch einfach, wenn
> man nur Aliasse von/zu Domains aus virtual_mailbox_domains zulassen
> will, 
...
> mailsystem=> \d virtual_mailbox_aliases
...
>  target    | integer               |

Und wie willst Du Weiterleitungen an externe Adressen umsetzen?
Der Einfachheit halber sollte die Zieladresse ein varchar-Feld sein, in 
dem schlicht eine Mailadresse steht.

> Was hier fehlt ist ein Constraint, der überprüft, ob es den
> "localpart" in der Domain "target" schonmal gibt - hier nehme ich
> gerne Hilfe an.

Sobald ein Catchall ins Spiel kommt, _brauchst_ Du sogar einen Eintrag 
für jede Mailbox in der Alias-Tabelle. Ansonsten geht alles an den 
Catchall und die anderen Mailboxen bekommen ihre Mails nicht mehr.

> Das führt dann zu folgender Map in virtual_alias_maps:
...

Na gut, mit einer ausreichend langen Query kann man alles erschlagen *g*

Du verbaust Dir dadurch aber die Option, Mails an eine Mailbox 
gleichzeitig auch an eine andere Adresse weiterzuleiten ;-)

> Arbeitet man mit virtual_alias_domains, wird es eklig. 

Oh ja. Haben wir bei Postfixadmin auch schon gemerkt ;-)

> Die Tabelle 
> für die Domains legt man analog zu virtual_mailbox_domains an (ein
> Constraint, wie ich überprüfen kann, daß eine Domain nicht in beiden
> Tabellen auftaucht, wäre schön), 

Packe alle Domains in eine Tabelle ;-) und baue ein zusätzliches 
Boolean-Feld für "ist eine Alias-Domain" ein.

Postfixadmin treibt Alias-Domains übrigens auf die Spitze - eine Domain 
kann Alias-Domain sein, aber trotzdem noch abweichende Mailadressen 
enthalten. (Nein, ich habe nicht gesagt, dass die zugehörige Query 
schön ist ;-)

Um das Ganze nochmal zusammenzufassen:
- eine perfekte Datenbank mit möglichst vielen Fremdschlüsseln ist zwar 
  schön, aber nicht immer praxistauglich
- ein Blick auf die Datenbankstruktur von Postfixadmin (SVN-Version) und 
  die verwendeten Queries (siehe DOCUMENTATION/*) kann Dir die ein oder 
  andere Anregung geben (vielleicht auch mir - falls Dir also irgendwas 
  seltsam vorkommt, melde Dich)
- oft sind "Schattenspalten" praktisch, um eine bessere Indexnutzung
  und/oder einfachere Queries zu bekommen. Hint: diese Spalten lassen 
  sich per Trigger füllen und aktuell halten.
- für alle Tabellen hat sich ein Feld zum temporären Deaktivieren einer
  Domain/Mailbox/... bewährt (Spalte "active" in postfixadmin)


Gruß

Christian Boltz
-- 
Vermutlich initialisiert das BIOS die Hardware nur halb, und die andere
Hälfte hängt vom Wasserstand in der Pegnitz und der Mondphase ab.
[Stefan Seyfried in suse-laptop]