Arrays und andere komplexe Daten mit PHP in einer MySQL-Datenbank speichern

Viele von euch werden wohl schon einmal vor dem Problem gestanden haben, dass sie ein Array oder ein Objekt in der Datenbank speichern mussten. Hier möchte ich ein paar Vorschläge unterbreiten, wie man das Problem nicht lösen sollte und wie es besser gehen kann.

Der schlechte Weg

Die einfachste und gleichzeitig auch schlechteste Methode wäre es, für jeden Index eines Arrays oder jede Eigenschaft eines Objekts eine neue Spalte zu erzeugen. Bei diesem Ansatz werden unter Umständen viele Zeilen erzeugt, die nicht immer einen Wert enthalten. Das ist zwar nicht so gravierend, aber durch diesen Ansatz erhöht sich auch die Anzahl der Spalten schnell auf eine unübersichtliche Anzahl. Zuletzt ist es hierbei bei jeder Änderung des Arrays oder Objekts notwendig die Datenbanktabelle anzupassen.

Eine bessere Lösung gefällig?

Eine etwas besser Lösung, die fast immer funktioniert aber nicht für alle Fälle optimal ist, wäre eine Serialisierung des Arrays oder Objekts. Hierbei werden die Daten mit der serialize() Funktion in einen String konvertiert und können somit direkt in eine VARCHAR oder TEXT Spalte speichert werden. Dabei muss der String natürlich noch durch die Funktion real_escape_string() (in diesem Beispiel von der MySQLi Klasse) “escaped” werden.

Speichern der Daten

// Das zu speichernde Array
$array = array('vorname' => 'Max', 'name' => 'Mustermann');
// Serialisieren der Daten
$string = serialize($array);
// Speichern der Daten
$mysqli->query('INSERT INTO table_name (array) VALUES ("'.$mysqli->real_escape_string($string).'")'))

Das Beispiel setzt natürlich voraus, dass die Variable $mysqli eine Instanz der MySQLi Klasse mit einer gültige Verbindung zu einer Datenbank enthält. Wir haben hier ein einfaches assoziatives Array, das serialisiert wird und anscheinend gespeichert wird. Die serialisierten Daten sehn in diesem Beispiel wie folgt aus:

Der zu speichernde String

a:2:{s:7:"vorname";s:3:"Max";s:4:"name";s:10:"Mustermann";}

Das Auslesen der Daten wird mit der Funktion unserialize() durchgeführt, die aus dem String wieder ein assoziatives Array erzeugt. Dazu lesen wir zuerst die Daten mit einem gewöhnlichen Query aus und konvertieren anschließend die Daten:

Auslesen der Daten

// Auslesen der Daten
$result = $mysqli->query('SELECT array FROM table_name');
$row = $result->fetch_assoc();
$string = $row['array'];
// Unserialisieren der Daten
$array = unserialize($string);

Diese Methode zum Speichern von komplexen Daten funktioniert recht gut, aber der serialisierte String benötigt dabei mehr Speicherplatz als für ein normales assoziatives Array eigentlich nötig wäre. Wie es eleganter geht zeige ich euch im nächsten Beispiel.

Die elegante Lösung mit JSON

Das Format JSON entspringt zwar der Skriptsprache JavaScript, aber es wird zu Zeiten von AJAX sehr oft auch serverseitig verwendet und erzeugt. Da die meisten serverseitigen Sprachen also auch JSON unterstützen bietet es sich auch für die Speicherung von komplexeren Datenstrukturen an. Die Anpassung des vorherigen Quellcodes beschränkt sich dabei auch auf eine einzige Zeile. Wir ersetzen lediglich die serialize() durch die json_encode() Funktion. Die Zeile 6 aus dem vorherigen Quellcode sieht dann folgt aus:

Speichern der Daten

...
$string = json_encode($array);
...

Hierbei werden die Datei des assoziativen Arrays in die JSON Notation konvertiert. Hierbei ist der resultierende String kompakter als bei der Serialisierung, da die Länge der einzelnen Arraywerte nicht und Datentypen nicht gespeichert werden:

Der zu speichernde String

{"vorname":"Max","name":"Mustermann"}

Beim Lesen der Daten aus der Datenbank müssen sie dann selbstverständlich auch wieder in das ursprüngliche Format zurück konvertiert werden. Dabei kommt wie ihr schon vermutet die Funktion json_decode() zum Einsatz. Diese erzeugt aber normalerweise ein Standard-Objekt. Um das in unserem Beispiel verwendete assoziative Array zu erhalten, wird als zweiter Paramater “true” übergeben. Der Änderung am Quellcode aus dem vorherigen Beispiel sieht dann wie folgt aus:

Auslesen der Daten

...
$array = json_decode($string, true);

Die Verwendung von JSON sichert nicht nur die Daten sondern auch die Schlüssel eines Arrays. Dabei spielt es keine Rolle, ob das Array assoziativ ist oder Zahlen als Schlüssel verwendet. Auch wird die Sortierung dabei nicht verändert. Wer lediglich die Werte eines Array speichern möchte, also keine Schlüssel benötigt, kann auch einen noch einfacheren Weg gehen.

Array in der Datenbank light

Der einfachste Werte mehrere Daten eines Array in einer Datenbank zu speichern sind die Funktionen explode() und implode(). Hierbei werden die einzelnen Werte des Arrays durch den “Delimiter”, den man als ersten Parameter angibt voneinander getrennt bzw. miteinander verbunden. Auch bei dieser Variante müssen in den beiden Beispiel-Quellcodes nur die Funktionen für die Umwandlung ausgetauscht werden. Zu beachte ist hierbei, dass der “Delimiter” nicht in den Werten vorkommen darf. Wer also beispielsweise ein Array mit Datumsangaben im Format 2010-01-23 mit implode verbinden möchte, darf nicht den Bindestrich als “Delimiter” verwenden.

Die Werte können wie auch zuvor in einer VARCHAR oder TEXT Spalte gespeichert werden. Sehr hilfreich sind die beiden Funktionen aber auch beim Speichern in einer Spalte mit dem Spaltentyp SET. Da hierbei aber die Werte zusätzlich von Anführungsstrichen umgeben sein müssen, muss der “Delimiter” auch die Anführungsstriche enthalten. Die implode Funktion würde in der Speicherfunktion dann wie folgt eingesetzt:

Speichern der Daten in einer SET Spalte

...
$string = implode('", "', $array);
...

Fazit

Wie ihr also seht, gibt es viele Wege komplexere Daten in einer Datenbank zu speichern. Das Beispiel mit JSON als Repräsentation sollte in jeder serverseitigen Skriptsprache funktionieren, die JSON unterstützt. Solltet ihr PHP verwenden müsst ihr natürlich auch sicherstellen, dass JSON bei euch aktiviert ist. Am einfachsten geht das wie immer mit Hilfe der phpinfo() Funktion, die in der Ausgabe einen “json” Abschnitt haben sollte.

Diejenigen von euch, die einen WordPress Blog haben und sich schon einmal die Datenbanktabelle angesehen haben, werden vermutlich die JSON Stringsserialisierten String schon gesehen haben. Den WordPress speichert z.B. Arrays eines Plugins automatisch in der JSON Notationserialisiert in der “options” Tabelle ab. Das macht es einem Pluginentwickler sehr einfach das Array zu speichern.

Aktualisierung: Dave hat mich darauf hingewiesen, dass WordPress natürlich nicht im JSON-Format speichert, sondern eben serialisierte Strings verwendet. Das sorgt bei eimem Umzug von WordPress immer zu Problemen, da man kein einfaches “Suchen/Ersetzen” machen kann, wenn sich die Länge der Strings unterscheidet. Hier verwende ich mittlerweile meistens die WP-CLI, die das schnell und sauber löst.

Ich hoffe, dass euch das kleine Tutorial weiterhelfen oder auf neue Ideen bringen konnte. Über Anregungen würde ich mich wie immer sehr freuen.

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugin, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

31 Kommentare » Schreibe einen Kommentar

  1. Schöne und interessante Übersicht. Was mir noch fehlt, ist ein Vergleich der Performance der verschiedenen Möglichkeiten bzw. Funktionen.

  2. Vielen Dank für diese hilfreichen Informationen. Wäre es möglich, ein paar Worte darüber zu verlieren, ob ein Objekt im Speicher mehr Platz braucht als dasselbe Objekt als JSON-String? Ich würde rein vom Bauchgefühl her dazu tendieren, diese Frage zu bejaen, da ich vermute, dass ein Objekt wie ein Baum im Speicher abgebildet wird, ein String hingegen nicht. Wie sehen Sie das? Könnte man damit die Verarbeitungsgeschwindigkeit größerer Objekte steigern?

    • Also ich bin da jetzt auch kein Experte, aber ich denke auch, dass der String weniger Platz im Speicher benötigt. Aber natürlich nur so lange er nicht mit json_decode() in ein Objekt oder Array umgewandelt wird. Wenn das Objekt aber erst zur Laufzeit umgewandelt wird (und nicht z.B. aus der Datenbank gelesen wurde), dann belegen aber wohl das Objekt UND der String Speicher.

      Zur Verarbeitungsgeschwindigkeit ist mir nicht ganz klar was mit “verarbeiten größerer Objekte” gemeint ist. Wenn das Objekt ein JSON-String ist, kann man damit wohl eher wenig anfangen. Daher kann man es auch nicht wirklich (inhaltlich) verarbeiten. Man könnte aber z.B. Objekte als String schneller kopieren, als das entsprechende Objekt.

      Ich hoffe mal, das konnte die Frage ein bisschen beantworten.

    • Vielen Dank für die Einschätzung. Ich gebe, der Begriff “Verarbeitungsgeschwindigkeit” ist ein wenig ungeschickt gewählt. Ich dachte dabei an solche Szenarien wie z. B. den Weitertransport eines großen Objekts mit vielen Eigenschaften, von denen einige selbst wieder Objekte sind. Wenn man diese Eigenschaften als JSON-Strings vorhält sowie auch das gesamte Objekt als JSON-String, so ließe sich doch vermutlich z. B. das Zwischenspeichern dieses Objektes in ein Session-Objekt für weitere Aktivitäten auf einer Webseite mit geringeren Speicherkosten erkaufen als wenn man dasselbe Objekt so wie es ist zwischenspeichern würde. Operationen auf Strings sollen ja sehr schnell verlaufen, weshalb ich den Zeitaufwand für das Endodieren bzw. Dekodieren der Objekte zu JSON-Strings als Vernachlässigbar einschätzen würde. Konnte ich jetzt deutlicher machen, was ich meine?

      • Also zur Zwischenspeicherung in der Session eignet sich das Umwandeln in einen JSON String natürlich sehr gut. Das Objekt als solches ist auch gar nicht direkt in der Session für eine spätere Verwendung speicherbar. Hierzu müsste es zumindest mit der serialize() Funktion umgewandelt werden. Aber dieser String ist größer als ein vergleichbarer JSON String. Daher hatte ich in dem Artikel die Serialisierung auch nur als “bessere Lösung” erläutert.

        So lange man aber nicht hunderte von Objekten auf einmal verarbeitet und speichert sollte es keine wirkliche Auswirkung haben, ob man das Objekt direkt verarbeitet oder nur die String-Repräsentation, denn bei einer Verarbeitungsgeschwindigkeit im Mikrosekunden-Bereich wird man das bei wenigen Objekten nicht merken.

  3. Was ist denn das für großes Mist? Das ganze hat nichts mehr mit SQL zu tun. Json ist dafür gedacht Daten auszutauschen zwischen Client und Server.

    Liest euch mal lieber sowas durch:
    Normalisierung von Datenbanken

    Auch haben HTML-Tags hier im Feld nichts zu suchen.

    • Danke für deinen Kommentar Rolf. Leider hast du wohl denn Sinn davon nicht verstanden. Das ist erstens kein “Mist” und hat zweitens sehr wohl etwas mit MySQL zu tun. Grundsätzlich sollte man Datenbanken immer normalisieren, aber eine Normalisierung macht auch nur bis zu einem bestimmten Grad Sinn und ist manchmal auch sehr kontraproduktiv. Wieso das so ist, steht im ersten Abschnitt des Artikels. Wenn man in einer Tabelle z.B. Objekte Speichern möchte, die sich in ihrer Struktur stark unterscheiden, macht es keinen Sinn, hunderte von Spalten oder zig Tabellen anzulegen, um die Werte atomar zu speichern. Oft ist man nämlich nicht an einzelnen Attributen des Objektes interessiert, sondern nur an dem Objekt im ganzen. Dafür werden dann z.B. oft Key-Value NoSQL-Datenbanken eingesetzt. Aber auch mit MySQL kann man sehr einfach solche Tabellen erstellen.

      Wie die Daten dann darin gespeichert werden, ist dem Nutzer selbst überlassen. Für mich hat sich das JSON-Format dabei durchgesetzt. Dieses ist nicht, wie du behauptest ein reines Austauschformat zwischen Server und Client, sondern in erster Linie eine Repräsentation eines Objektes in Form eines Strings. Auch wenn es aus der JavaScript-Welt kommt, wir es schon lange auch in anderen Programmiersprachen eingesetzt, da es im Gegensatz zu anderen Format wie z.B. XML sehr kompakt ist.

      Bevor du also neue Ideen gleich als Mist bezeichnest, solltest du dir vielleicht mal den Einsatzzweck genauer ansehen. Dann wirst auch du merken, dass es in diesem Fall die optimale Umsetzung ist und eine Normalisierung absolut keinen Sinn machen würde.

      Deine Anmerkungen zu den HTML Tags kann ich nicht nachvollziehen, wo wurden die denn bei dir angezeigt? Ich kann keine in meinem Code finden.

    • Um Objekte in Datenbanken zu speichern gibt es die NOSQL-Datenbanken, und viele rundern schon wieder zurück und gehen zurück zu normalen SQl-Datenbanken weil bei einfachen Abfragen die NOSQL-Datenbanken langsamer sind, und jetzt kommst du her und behauptest es wäre besser, schon vor 20 Jahren hat man es versucht Objecte ganz in Datenbanken zu speichern. (Ich habe sogar ein Buch über dieses Thema, und das ist über 10 Jahre alt) und es ist einfach nicht sinnvoll.

    • Noch eine kleine Anmerkung: Frau Müller heiratet jetzt und erhält einen Nachnamen, was wird wohl schneller sein? Nur den Nachnamen in der richtige Spalte einer Normalisierten Datenbank zu ändern oder bei deiner Methode?

    • Ich glaube du hast den Einsatzzweck noch immer nicht verstanden. Es geht hier nicht darum, in einer Tabelle gleichartige Objekte mit gleichen Eigenschaften zu speichern, sondern eben verschiedenartige. Ich versuche mal ein Beispiel zu finden:

      Nehmen wir an, du möchtest alle deine Elektronikartikel speichern. Diese haben gleiche Eigenschaften, wie “Hersteller”, “Modellbezeichnung”, “Anschaffungspreis” usw. Sie haben aber eben auch Eigenschaften, die nur sie alleine haben. So hat etwa ein DVD-Player z.B. Anschlüsse und unterstützte Formate, eine Kamera hat einen Brennweitenbereich und eine Displaygröße und eine Speicherkarte hat eine Speicherkapazität und eine Lese- und Schreibgeschwindigkeit. Wenn du nun also diese spezifischen Eigenschaften in strukturierter Form speichern möchtest und es dich bei einer Abfrage nicht interessiert, wie der Wert einer solchen Eigenschaft ist, dann ist eben das Speichern eines Objektes z.B. in Form eines JSON-Strings eine Möglichkeit.

      Wenn sich eine Eigenschaft ändert, dann muss ich zwar das gesamte Objekt konvertieren, den Wert ändern, das Objekt zurück konvertieren und den gesamten String aktualisieren. Aber das ist in diesem Zusammenhang vollkommen in Ordnung.

      Versuche diese Konstruktion mal mit einer normalisieren Datenbank umzusetzen, die dann genauso schnell arbeitet, wie in diesem Fall. Denn ohne mehrere zusätzliche Tabellen und etliche JOINs wirst du das nicht bewerkstelligen können.

      Und deine Aussage, dass NoSQL-Datenbanken langsamer wären als relationale Datenbanken ist ja wohl auch nicht fundiert. Hier muss ich zum Aufruf eines Objektes und seiner Eigenschaften nur einen einfachen Schlüssel suchen. Das ist in jedem Fall schneller als mehrere Tabellen über Fremdschlüssel zu joinen.

      Ist dir jetzt klar geworden, wieso man Ojekte in einer relationalen Datenbank speichern möchte und wieso der beschriebene Weg dabei sinnvoll ist? Er ist im übrigen nicht auf meinem Mist gewachsen. Wie ich ja schon im Artikel erwähnt habe, speichert WordPress z.B. alle Optionen von Plugins in dieser Form in einer Tabelle. Das ist nämlich auch ein gutes Beispiel für Objekte, die einige gleiche, aber sehr viele Unterschiedliche Eigenschaften besitzen. Und diese Objekte werden in der Regel am Stück ausgelesen und komplett benötigt und beim Speichern eben auch am Stück aktualisiert.

    • Ich sag es dir nochmal, die Idee ist so alt wie es SQL-Datenbanken gibt und was meinst du warum es sich nicht durchgesetzt hat. Deine Idee ist nicht schon uralt und hat sich nicht durchgesetzt und du meinst jetzt du hast recht wo sich schon Experten mit auseinander gesetzt haben?

      Mit den HTML-TAGS meine ich diese her unter dem Text-Feld “<a href=”” title=”” rel=”nofollow”>” die haben hier nichts zu suchen. Dafür gibt es BB-Code.

    • Noch ein Beispiel aus der Praxis, wo zu viel Normalisierung zu Problemen und Mehraufwand führt. Google hat in seiner Google Maps Geocode API in Version 2 die Angabe der Straße als einen zusammengesetzten String aus Straßenname und Hausnummer geliefert. In der neunen Version tun sie das nicht mehr. Wenn du also nun eine korrekte Adresse ausgeben möchtest, stehst du vor folgendem Problem: In Deutschland und einige anderen Ländern kommt zuerst der Straßenname und dann die Hausnummer. In Frankreich, den USA und vielen anderen Ländern ist es aber gerade umgekehrt. Als Programmierer stehst du nun also vor der riesigen Aufgabe, für hunderte von Ländern rauszufinden, wie genau die Ausgabe zu erfolgen hat und dies dann in deiner Anwendung umsetzen. Natürlich ist streng genommen das Speichern der Hausnummer in einer eigenen Spalte nicht verkehrt, aber es führt eben auch zu Problemen an anderer Stelle. Und solange ich keine Abfragen nach dem Schema “Gib mir alle Adressen, mit der Hausnummer 5” mache (was wohl nicht sehr gebräuchlich ist), kann man auch Straßenname un Hausnummer in einer Spalte speichern. Denn dann kann ich immer noch eine Abfrage “Gib mit alle Adressen in der Hauptstraße” machen und diese auch alphanumerisch sortieren.

    • OK, vermutlich willst du es einfach nicht verstehen. Was meinst du wohl, wieso NoSQL-Datenbanken gerade einen solchen Erfolg haben? Weil eben nicht alle beim Stand von vor 20 Jahren stehengeblieben sind. Es gibt Anwendungen für solche Lösungen, diese sind performater und flexibler als relationale Datenbanken und deshalb werden sie auch eingesetzt. Relationale Datenbanken sind eben auch nicht der Heilige Grahl der IT-Welt. Aber wenn du eben nur damit arbeiten möchtest und alle Anwendungen damit auch sinnvoll umsetzen kannst, dann ist das doch hervorragend.

      Zu den HTML-Tags: Falls du es nicht gemerkt hast, das hier ist ein Blog und eben kein Forum und genau deshalb hat HTML hier absolut etwas zu suchen. BB-Code ist eben eine spezielle Syntax von Forensoftware. Daraus wird am Ende auch nur HTML kompiliert. Und da wohl heute mehr Menschen HTML können als BB-Code (war vor 10 Jahren noch anders), kann hier jeder direkt HTML verwenden, wenn er es denn kennt. Wenn nicht, dann schreibt er eben nur normalen Text und Links werden dann trotzdem anklickbar.

  4. Noch eine Anmerkung am Rande:
    Wenn ich z.B. mit Klassen in PHP arbeite und ich habe eine Klasse welcher Objekte aus anderen Klassen enthält, funktioniert die JSON-Methode nicht.
    Daher empfehle ich allen die Klassenobjecte (z.B. Spielstände) in der DB als text speichern wollen dies über die serialize/unserialize – Methode zu lösen, außerdem können so auch Methoden sofort wieder verwendet werden.

    Bei mir schaut das ungefähr so aus:

    $game = new blackjack();
    $game = unserialize($save);  //$save enthält dabei die Ausgabe aus der DB aus dem Object $game
    
    • Guter Hinweis. DU hast natürlich recht, dass per JSON nur einfache Dateitypen gespeichert werden können. Ich werde das später im Text mal ergänzen.

      • Nee hatte die nicht vertauscht. Ich erstelle ja zuerst ein Object blackjack.
        Und dann überschreibe ich es mit dem Objekt aus der DB.

        Vielleicht muss ich das auch gar nicht, aber so sah es für mich schlüssiger aus und es funktioniert so auch bei mir ;-). Habe das halt so gemacht, weil ich nicht wusste ob er sonst auch die Methoden richtig übernimmt.

        $save ist ja nur der String aus der DB.
        $game das Spiel-Object an sich.

        • Ich habe meinen Denkfehler schon bemerkt und den Hinweis aus meinem Kommentar entfernt. Ich denke aber auch, dass du direkt das Objekt aus der Datenbank lesen kannst.

          • Ah ok super.
            Ich habe das grad mal getestet. Man kann wirklich direkt:
            $game = unserialize($save);
            schreiben.

            Dabei werden dann automatisch alle Methoden verfügbar. Nützlich.

  5. Hey Bernhard.

    Danke für die kurze Übersicht! genau was ich grad gesucht hab!

    @Rolf: wenn es funktioniert und viele Leute damit gut (und problemfrei) arbeiten können, macht es wohl (vollkommen unabhängig von Eurer “Experten-Unterhaltung”) per Definition Sinn.

    Ich werd auf jedenfall eine dieser Varianten nutzen. Die Ansätze von Rolf machen für mein Projekt nicht einmal Sinn, während ich die Anregungen aus diesem Beitrag gut nutzen kann.

    Normalisierte Grüße!
    Stefan

    • Freut mich, dass ich dir weiterhelfen konnte!

      Und die Diskussion mit Rolf war ein wenig mühselig, wie du wohl gemerkt hast. Er hat das hier wohl mit einem Forum für alte Hasen verwechselt und nicht als einen Blog für moderne Webentwicklung erkannt 🙂

  6. Hallo Bernhard,
    bei der Vorbereitung auf meinen Kurzvortrag heute Abnd ist mir ein kleiner Fehler in diesem – ansonsonsten sehr guten – Artikel aufgefallen:

    Diejenigen von euch, die einen WordPress Blog haben und sich schon einmal die Datenbanktabelle angesehen haben, werden vermutlich die JSON Strings schon gesehen haben. Den WordPress speichert z.B. Arrays eines Plugins automatisch in der JSON Notation in der “options” Tabelle ab.

    Nach meiner Beobachtung speichert WordPress Arrays nicht in der JSON-Notation, sondern mittels PHP serialize(). Die WP-eigene Funktion maybe_serialize greift auf serialize() zurück:

    function maybe_serialize( $data ) {
    	if ( is_array( $data ) || is_object( $data ) )
    		return serialize( $data );
    
    	if ( is_serialized( $data ) )
    		return serialize( $data );
    
    	return $data;
    }
    

    Beste Grüße
    David

    • Da hast du natürlich recht. Ich hatte damals vermutlich einfach nur die Werte von Plugins gesehen, die ihre Werte selbst schon nach JSON kodiert haben, bevor sie gespeichert wurden. Damals ist mir das nicht aufgefallen. Wow, ist ja schon 5 Jahre her 🙂 Ich passe den Absatz im Artikel mal an.

  7. Pingback: WordPress richtig zu anderer Domain umziehen

  8. Hallo, mir ist ein kleiner Fehler bei dem implode-Befehl aufgefallen:

    $string = implode('", "', $array); 
    

    erzeugt ein string mit dem Inhalt:

    'pattern1","pattern2","pattern3'
    

    Wie man sieht, sind die Anführungsstriche am Anfang und am Ende nicht drin.

    Besser:

    $string = '"'.implode('", "', $array).'"'
    

    Damit sollte es passen.

    Willi

  9. Klasse idee,

    nun stellt sich mir aber eine Frage:
    Ich trage in eine Tabelle alle Eisorten ein.

    a:14:{i:0;s:1:"2";i:1;s:1:"3";i:2;s:1:"4";i:3;s:1:"5";i:4;s:1:"6";i:5;s:2:"13";i:6;s:2:"14";i:7;s:1:"7";i:8;s:1:"1";i:9;s:1:"8";i:10;s:1:"9";i:11;s:2:"10";i:12;s:2:"11";i:13;s:2:"12";}
    

    Jetzt möchte ich über eine Abfrage erfahren, ob in dem Array mein Eissorte “Schokolade” (Es wäre Punkt 8) enthalten ist.
    Mein Fragearray wäre dann ähnlich aufgebaut:

    a:2:{i:0;s:1:"1";i:1;s:2:"13";}
    

    Ich arbeite nur mit ID’s, deswegen stehen dort keine Eissortennamen.

    Wie mache ich das vereinfacht?

    Mir fehlt gerade der richtige Ansatz. Einfach vergleichen geht ja kaum?

    Danke für eure Ansätze.

    • Du möchetest also wissen, wie du das in SQL lösen kannst? Gar nicht.

      Wenn man komplexe Daten wie hier beschrieben in der Datenbank ablegt, dann nur zu dem Zweck, sie später wieder genau so aus der Datenbank zu laden.

      Du kannst also auf Arrays, die so gespeichert sind, nur mit PHP weiterarbeiten. Hierzu müsstest du dann aber wohl alle Zeilen erst einmal auslesen und wieder in Arrays umwandeln.

      Ich denke mal dein Problem liegt in einem nicht ganz durchdachten Datenbankdesign. Wenn du wirklich auf ein “Eissorten-Array” suchen willst, dann solltest du wohl hierzu eine Verknüpfungstabelle anlegen.

      • Das kleine 1×1 der Informatik beginnt schon bei der Datenintegrität und die damit verbundene Konsistenz und Verfügbarkeit der Daten. Array’s oder ganze Objekte in Strings zu sequenzieren und dann in rationale Datenbanken abzulegen, ist wenig sinnvoll, wenn die Daten in Relationen zueinaner verarbeitet werden sollen. Objektorientierte Datenbanksysteme scheitern oftmals genau an dieser Verfügbarkeit, da die Relationen, die Daten und Funktionen trennen sollen, nicht so wie gewünscht ausgeschöpft werden können. Als höchstens sinnvoll erachte ich die Sequenzierung von flüchtigen Objekten oder Settings in rationalen Datenbanken. Wenn die Daten schon in der Datenbank mittels Views oder komplexen logischen Relationen verarbeitet werden sollen, kommst du nicht um eine Auflösung der Abhängigkeiten innerhalb eines Objekt-Strings, oder gespeicherten Tupels, drumrum. Für deine Verknüpfung kannst du verschiedene Array’s aufbauen, die miteinander verbunden werden können. Die Keys der Eissorten könntest du dann mit den Keys der Klarnamen verbinden. Das würde ich persönlich aber schon beim Aufbau der Arrays realisieren. Du hast deine Daten an Relationen angelehnt, siehe Keys, aber als Objekt-String sequenziert gespeichert. Grundsätzlich ist das ein sehr unschöner Ansatz, weil es nicht konsequent ist. Die Vermischung von Objektstrings mit rationalen Datenbanken, oder überhaubt von nicht aufeinander abgestimmen oder ineinander zweckdienlichen Systemen, wird in der Informatik als sehr unsauberer Ansatz bezeichnet.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.