nicht angemeldet
MySQL Code um Zelle zu berechnen
Rolf b
TS
MudGuardHallo,
gibt es eigentlich auch die Möglichkeit eine MySQL Tabelle so anzulegen, dass einige Werte von Spalten automatisch berechnet werden? Klar mit einem PHP Script könnte man so etwas u.a. machen, aber geht so etwas auch direkt in PHPMyAdmin mit SQL Code sozusagen?
Beispiel: Ich erstelle eine MySQL Tabelle mit 3 Spalten. ID, URL, Domain.
Wenn eine URL hinzugefügt wird, soll in der Spalte "Domain" automatisch die Domain der URL eingefügt werden. Könnte ich für diese Spalten einen Code verwenden, der die Domain aus der URL zieht und einfügt? Evtl. ist es ja möglich auf einen PHP Code aus der Zelle zu verweisen, der dann ausgeführt wird?
LG eBody
-
Joa geht, musst nur gucken wie weit du mit de Funktionen von MySQL kommst
https://wiki.selfhtml.org/wiki/Datenbank/MySQL_Triggers_und_Stored_Functions
-
Sieht sehr interessant aus, vielen Dank für den Hinweis.
Gruß eBody
Joa geht, musst nur gucken wie weit du mit de Funktionen von MySQL kommst
https://wiki.selfhtml.org/wiki/Datenbank/MySQL_Triggers_und_Stored_Functions
-
-
Könnte ich für diese Spalten einen Code verwenden, der die Domain aus der URL zieht und einfügt?
Das geht wohl. Allerdings steht die Frage nach dem Nutzen-Aufwand-Verhältnis, da der Vorgang nicht ganz simpel ist und mehrere Schritte, insbesondere eine geschickte Verkettung von String-Operationen erfordert - während es z.B. in PHP nur eines regulären Ausdrucks bedarf.
Ronald Schaukrug
-
... oder parse_url()
-
... oder parse_url()
Richtig.
Ronald Schaukrug
-
-
-
Das nennt man Verletzung der Normalform und ist nach Möglichkeit zu vermeiden.
Es sei denn, du brauchst die Domain als eigenes Feld, um damit spätere Abfragen effizienter ausführen zu können.
Trigger sind eine Möglichkeit. Sie wirken aber meines Wissens wie ein zweites SQL Statement, d.h. der Satz landet erstmal ohne Domain in der DB und DANN rennt der Trigger los und kann dran rumfingern. Müsste man genauer betrachten, kann auch davon abhängen ob Du Transaktionen verwendest.
Oder Du könntest Stored Procedures für INSERT und UPDATE verwenden und das Recht auf INSERT/UPDATE nur dieser Procedure granten. Die Procedure kümmert sich dann um die DOMAIN Spalte. Der Rest der Welt bekommt das EXECUTE-Recht für diese Procedure sowie SELECT und DELETE. Wobei - ich kenne die genauen Berechtigungsmöglichkeiten bei MySQL nicht, ich extrapoliere aus meinen Kenntnissen bei MS-SQL und IBM DB2.
Wenn Du genau eine Stelle in deinen Programmen hast, wo die Tabelle geschrieben wird, dann kannst du es aber auch ganz primitiv dort machen. Falls das an vielen Stellen passiert - hm, dann frag Dich, ob das sein muss ;-)
Rolf
-
Hallo und guten Tag,
Das nennt man Verletzung der Normalform und ist nach Möglichkeit zu vermeiden.
Das nenne ich Halbwissen!
Nur weil der zweite Wert aus dem ersten durch einen Algorithmus zu berechnen ist, ist die Normalform noch nicht verletzt, da hier eine N:1-Abbildung durchgeführt wird, also keine eindeutige Umkehrfunktion existiert!Da MySQL keine berechneten Indexe kennt, ist es durchaus legitim eine weitere Spalte mit einem konsolidierten Wert anzulegen. Wenn dann z. B. nach diesem Wert sortiert oder gefiltert werden soll, kann das sehr sinnvoll sein. Zufällig habe ich gerade die gleiche Aufgabe auf dem Tisch.
Zu berücksichtigen sind aber die Randbedingungen, die aber eigentlich nichts mit Datenbank zu tun haben, sondern mit URLs:
www.liebesfalle.dekann eine ganz andere Domain sein, alsliebesfalle.dehttps://liebesfalle.dekann ganz andere Ergebnisse liefern, alshttp://liebesfalle.de- usw.
Grüße
TS-
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 "." digitsWobei 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
-
Tach!
Wie ich neulich aus PLs Beitrag gelernt habe, kann es im Pfad sogar noch per Semikolon angehängte Pfadparameter geben.
Da hast du wohl was falsch verstanden. Es gab mal in HTML 4 die Empfehlung, Key-Value-Paare im Querystring nicht mit & sondern mit ; zu trennen, damit man sich das Umschreiben zu & im HTML-Kontext sparen kann. Hat sich nur keiner großartig darauf eingelassen. In PHP kann sie jedenfalls verwenden, weil man da das Parse-Verhalten über arg_separator.input einstellen kann.
dedlfix.
-
- http://doriantaylor.com/policy/http-url-path-parameter-syntax
- http://www.jtmelton.com/2011/02/02/beware-the-http-path-parameter/
Glaube schon, dass ich die beiden Artikel verstanden habe. Es geht da wirklich um den Path, nicht um den Query-Anteil der URL. Ohne PLs Hinweis wäre mir das komplett unbekannt gewesen. Und das kann echt eine Tretmine sein.
Rolf
-
Tach!
- http://doriantaylor.com/policy/http-url-path-parameter-syntax
- http://www.jtmelton.com/2011/02/02/beware-the-http-path-parameter/
Glaube schon, dass ich die beiden Artikel verstanden habe. Es geht da wirklich um den Path, nicht um den Query-Anteil der URL.
Nunja, pl nimmt es mit den Begrifflichkeiten ja oft nicht so genau, aber abgesehen davon, dass
;wirklich auch im Path vorkommen können, dies nicht sehr bekannt ist, und Angular 2 sich grad anschickt, sie wieder populär zu machen - jedenfalls "Parameterliste" und "; statt &" klingt für mich nicht nach Path sondern nach Querystring und der Empfehlung in HTML 4.dedlfix.
-
-
Hi,
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).
nein, bei HTTP kann kein Userid und Passwort vorkommen. Siehe die von Dir genannte RFC1738, Abschnitt 3.3): "No user name or password is allowed."
cu,
Andreas a/k/a MudGuard-
Sorry, da hab ich mich vom allgemeinen Schema reinlegen lassen.
Ich hatte mich durchaus drüber gewundert, aber nach den Path-Parametern wäre ich auch bereit gewesen, FTP-Credentials in HTTP-URLs hinzunehmen...
Rolf
-
-
-