> > Das nennt man Verletzung der Normalform und ist nach Möglichkeit zu vermeiden. > Das nenne ich Halbwissen! Besser als Drittelwissen. Also auf zum Nebenschauplatz. Obwohl - eigentlich ist es gar keiner, zum Herausparsen der Domain dürfte es ganz interessant werden. Stell Dir vor, die URL wäre nicht die URL, sondern die postalische Adresse und du möchtest nach PLZ abfragen. Aber weil Deine Tabelle nur ein Textfeld "Adresse" modelliert hat, baust Du einen Trigger, der bei Inserts und Updates die PLZ algorithmisch extrahiert und in ein eigenes Feld kopiert. Du schreist auf? Klar. Offensichtlich ist die 1.NF verletzt, Adressen modelliert man anders. De facto ist die URL kein atomares Attribut, sondern zusammengesetzt aus Schema und mehr, wobei "mehr" bei HTTP aus Userid, Passwort, Host, Port, Pfad, Query und Fragment bestehen kann (RFC1738 etc). Wie ich neulich aus PLs Beitrag gelernt habe, kann es im Pfad sogar noch per Semikolon angehängte Pfadparameter geben. Dass wir sie in den meisten Fällen atomar behandeln, ändert nichts an der Tatsache, dass sie es nicht ist. Sobald man aber den Bedarf hat, Abfragen auf den Hostnamen zu machen, fällt die Nichtatomarität auf und die Tabelle ist für den geforderten Zweck nicht mehr in Erster Normalform. Übrigens zeigen deine Überlegungen zum Hostnamen, dass auch dieser nicht atomar ist. RFC 1738 definiert: ~~~ host = hostname | hostnumber hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit alphadigit = alpha | digit hostnumber = digits "." digits "." digits "." digits ~~~ Wobei das veraltet ist, hostnumber kann ja auch eine IPv6 Adresse sein und UTF-8 Domainnamen könnten auch fehlen. Ich hab nur gerade nicht die aktuelle RFC-Nummer zur Hand. Soweit zur Theorie. In der Praxis kann es durchaus vorkommen, dass man ein Attribut eigentlich atomar behandeln will (die URL eben), wenn es bei den meisten Abfragen als atomares Gebilde gebraucht wird. Es gibt nur ein paar blöde Sonderfälle, wo die Nichtatomarität auffällt und es kann zu aufwändig sein, nur für diese Sonderfälle das nichtatomare Attribut auszumodellieren. In dem Fall ist eine geplante Redundanz durchaus akzeptabel. Wie heißt es so schön: Redundanz ist das Schmierfett der Datenbank. Und wie beim Schmierfett macht man sich dabei die Finger dreckig. _Rolf_

> > Das nennt man Verletzung der Normalform und ist nach Möglichkeit zu vermeiden. > Das nenne ich Halbwissen! Besser als Drittelwissen. Also auf zum Nebenschauplatz. Obwohl - eigentlich ist es gar keiner, zum Herausparsen der Domain dürfte es ganz interessant werden. Stell Dir vor, die URL wäre nicht die URL, sondern die postalische Adresse und du möchtest nach PLZ abfragen. Aber weil Deine Tabelle nur ein Textfeld "Adresse" modelliert hat, baust Du einen Trigger, der bei Inserts und Updates die PLZ algorithmisch extrahiert und in ein eigenes Feld kopiert. Du schreist auf? Klar. Offensichtlich ist die 1.NF verletzt, die Adressen modelliert man anders. De facto ist die URL kein atomares Attribut, sondern zusammengesetzt aus Schema und mehr, wobei "mehr" bei HTTP aus Userid, Passwort, Host, Port, Pfad, Query und Fragment bestehen kann (RFC1738 etc). Wie ich neulich aus PLs Beitrag gelernt habe, kann es im Pfad sogar noch per Semikolon angehängte Pfadparameter geben. Dass wir sie in den meisten Fällen atomar behandeln, ändert nichts an der Tatsache, dass sie es nicht ist. Sobald man aber den Bedarf hat, Abfragen auf den Hostnamen zu machen, fällt die Nichtatomarität auf und die Tabelle ist für den geforderten Zweck nicht mehr in Erster Normalform. Übrigens zeigen deine Überlegungen zum Hostnamen, dass auch dieser nicht atomar ist. RFC 1738 definiert: ~~~ host = hostname | hostnumber hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit alphadigit = alpha | digit hostnumber = digits "." digits "." digits "." digits ~~~ Wobei das veraltet ist, hostnumber kann ja auch eine IPv6 Adresse sein. Ich hab nur gerade nicht die aktuelle RFC-Nummer zur Hand. Soweit zur Theorie. In der Praxis kann es durchaus vorkommen, dass man ein Attribut eigentlich atomar behandeln will (die URL eben), wenn es bei den meisten Abfragen als atomares Gebilde gebraucht wird. Es gibt nur ein paar blöde Sonderfälle, wo die Nichtatomarität auffällt und es kann zu aufwändig sein, nur für diese Sonderfälle das nichtatomare Attribut auszumodellieren. In dem Fall ist eine geplante Redundanz durchaus akzeptabel. Wie heißt es so schön: Redundanz ist das Schmierfett der Datenbank. Und wie beim Schmierfett macht man sich dabei die Finger dreckig. _Rolf_