Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
dev:all:examples [17.09.2014 22:15] – [INSERT / UPDATE] Manuela v.d.Decken | dev:all:examples [26.06.2018 07:15] (aktuell) – [...rund um die Datenbank] Manuela v.d.Decken | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== So funktioniert das... ====== | ====== So funktioniert das... ====== | ||
- | [[dev: | + | [[dev: |
- | Eine Sammlung von Codebeispielen... bli bla blubber.. hier kommt noch Text | + | Eine Sammlung von Codebeispielen, die gleichzeitig auch wieder Regeln definieren, wie im Zusammenhang mit WebsiteBaker programmiert/ |
Zeile 10: | Zeile 10: | ||
---- | ---- | ||
- | + | ===== ...gut zu wissen | |
- | ===== Rund um die Datenbank ===== | + | * **[[dev: |
- | Die ganzen Beispiele in diesem Bereich sind im neuen Stil von WB-2.8.4 ausgeführt. Bei älteren Versionen ist meist nur $oDb durch $database und $oDb-> | + | ===== ...rund um die Datenbank |
- | ==== SQL-Statements richtig aufgebaut | + | * **[[dev:all: |
- | Das ist schon < | + | * **[[dev:all:examples: |
- | Also am besten erst ein mal die grundlegensten Regeln: | + | * **[[dev:all:examples:sql-1|Der richtige Einsatz von SQL-Abfragen]]** |
- | * Statements dürfen nicht in der Argumentenklammer einer Funktion/ | + | |
- | | + | |
- | | + | |
- | * alle Feld- und Tabellennamen müssen in **`** Backticks eingeschlossen werden. | + | |
- | * Statements dürfen nicht mit **”**text**”**, | + | |
- | SQL-Statements sollten auch optisch so aufgebaut werden, dass sie problemlos und schnell gelesen und erfasst werden können. Die zeilenweise Aufteilung nach Action-Schlüsselwörtern ist an der Stelle sehr sinnvoll. Ist eine Zeile zu lang (Codingstandards) dann mit Einrückung auf mehrere Zeilen verteilen. Bei der Feldauswahl im SELECT-Bereich ist zu beachten, dass der Server komplette Datensätze (SELECT *) deutlich schneller liefern kann, als eine Auswahlliste von einzelnen Feldern. | + | |
- | Um den Aufbau von Statements zu demonstrieren, | + | |
- | === SELECT | + | |
- | Alle vier Beispiele geben ein Result-Objekt mit allen Datensätzen der zum aktuellen Zeitpunkt sichtbaren Sections zurück | + | |
- | <code php Beispiel-1.php> | + | |
- | $iTimestamp = time(); // make sure to use the identical time everywhere | + | |
- | $oResult = $oDb-> | + | |
- | </ | + | |
- | <code php Beispiel-2.php> | + | |
- | $iTimestamp = time(); // make sure to use the identical time everywhere | + | |
- | $sql = ' | + | |
- | $sql .= 'WHERE `page_id`=' | + | |
- | $sql .= 'ORDER BY `block`, `position`'; | + | |
- | $oResult = $oDb-> | + | |
- | </ | + | |
- | <code php Beispiel-3.php> | + | |
- | $iTimestamp = time(); // make sure to use the identical time everywhere | + | |
- | $sql = ' | + | |
- | | + | |
- | . 'FROM `' | + | |
- | . 'WHERE `page_id`=' | + | |
- | | + | |
- | | + | |
- | . 'ORDER BY `block`, `position`'; | + | |
- | $oResult = $oDb-> | + | |
- | </ | + | |
- | <code php Beispiel-4.php> | + | |
- | $iTimestamp = time(); // make sure to use the identical time everywhere | + | |
- | $sql = ' | + | |
- | . 'WHERE `page_id`=' | + | |
- | | + | |
- | | + | |
- | . 'ORDER BY `block`, `position`'; | + | |
- | $oResult = $oDb-> | + | |
- | </ | + | |
- | Welche Beispiele lassen sich leichter lesen, verstehen und bei Bedarf auch leichter ändern? | + | |
- | === DELETE === | + | |
- | Bei dieser Abfrage kann man eigentlich nichts falsch machen... | + | |
- | Aber auch hier gilt: Erst das Statement in einer Variablen aufbauen und diese dann an die Query-Methode übergeben. | + | |
- | <code php DELETE-1.php> | + | |
- | $sql = ' | + | |
- | . 'WHERE `user_id`=' | + | |
- | $oDb-> | + | |
- | </ | + | |
- | === INSERT / UPDATE === | + | |
- | In diesem Bereich wird es langsam interessant. Es gibt mehrere verschiedene Arten die Statements für INSERTs und UPDATEs aufzubauen. Speziell im Bereich der Werteübergabe.\\ | + | |
- | Bei **allen** Arten von INSERTs gilt jedoch die SQL-Strikt Regel, dass **allen** Feldern eines Datensatzes Werte zugewiesen werden müssen. Ausgenommen hiervon sind nur die Felder, die in der Tabelle bereits mit einem Default-Wert vordefiniert sind. | + | |
- | Immer wenn Daten in die Datenbank geschrieben werden sollen, sind bestimmte Sicherheitsregeln | + | |
- | * Es muss sichergestellt sein, dass nur der richtige Datentyp übergeben wird. | + | |
- | * Es muss sichergestellt sein, dass jeder übergebene Wert zuvor überprüft wurde und gültig ist. | + | |
- | * Es dürfen nicht Werte aus Superglobalen Arrays, speziell aus // | + | |
- | * Stringvariable müssen vor der Übergabe '// | + | |
- | * Enthält eine Tabelle ein // | + | |
- | :!: Im Umfeld von WebsiteBaker ist für INSERT und UPDATE | + | |
- | + | ||
- | Erst ein Beispiel wie ein Statement (obwohl syntaktisch richtig) **nicht** aussehen darf: | + | |
- | <code php insert-01.php> | + | |
- | // das ist übrigens ein Original-Statement aus WB-2.8.3-SP1 'add user' | + | |
- | $sql = " | + | |
- | </ | + | |
- | So hingegen muss ein Statement nach den zuvor beschriebenen Regeln aussehen: | + | |
- | <code php insert-02.php> | + | |
- | $sql = ' | + | |
- | . 'SET `group_id`=' | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | </ | + | |
- | Ein UPDATE sieht im Prinzip genau so aus: | + | |
- | <code php SET-1.php> | + | |
- | $sql = ' | + | |
- | . 'SET `display_name`=\'' | + | |
- | | + | |
- | . 'WHERE `user_id`=' | + | |
- | </ | + | |