Erstens, das will man wirklich nicht. Eine Spalte in einem RDBMS soll atomar sein, da sie genau eine Information enthält. Der Versuch, mehr als ein Datenelement in einer Spalte zu speichern, verstößt gegen die erste Normalform.
Wenn Sie dies unbedingt tun müssen, müssen Sie die Daten in eine Form konvertieren, die als einzelnes Datenelement gespeichert werden kann, normalerweise als Zeichenfolge. Sie könnten den serialize()-Mechanismus von PHP, XML-Parsing (wenn die Daten ein Dokumentbaum sind), json_encode() usw. verwenden.
Doch wie fragt man solche Daten effektiv ab? Die Antwort ist, dass Sie das nicht können.
Auch wenn jemand anderes Ihr Projekt zu einem späteren Zeitpunkt übernimmt, werden Sie ihn wirklich ärgern, weil es schrecklich ist, mit serialisierten Daten in einer Datenbank zu arbeiten. Ich weiß es, weil ich solche Projekte geerbt habe.
Habe ich schon erwähnt, dass du das wirklich nicht willst? Sie müssen Ihr Design überdenken, damit es einfacher in atomaren Zeilen gespeichert werden kann. Verwenden Sie für diese Daten zB eine andere Tabelle und setzen Sie diese über Fremdschlüssel in Beziehung zum Stammsatz. Sie werden aus gutem Grund relationale Datenbanken genannt.
AKTUALISIEREN :Ich wurde nach den Anforderungen an die Datenspeicherung gefragt, z. B. ob eine einzelne Zeile in Bezug auf die Speicherung billiger wäre. Die Antwort ist, in typischen Fällen nein, ist es nicht, und in Fällen, in denen die Antwort ja ist, ist der Preis, den Sie dafür bezahlen, nicht wert.
Wenn Sie eine 2-spaltige abhängige Tabelle verwenden (1 Spalte für den Fremdschlüssel des Datensatzes, zu dem die Probe gehört, eine für eine einzelne Probe), dann benötigt jede Spalte im schlimmsten Fall 16 Bytes (8 Bytes für eine Schlüsselspalte mit langer Ganzzahl, 8 Bytes). für eine Gleitkommazahl mit doppelter Genauigkeit). Für 100 Datensätze sind das 1600 Bytes (Db-Overhead wird ignoriert).
Bei einem serialisierten String speichert man im besten Fall 1 Byte pro Zeichen im String. Sie können nicht wissen, wie lang die Zeichenfolge sein wird, aber wenn wir annehmen, dass 100 Proben mit allen gespeicherten Daten durch einen erfundenen Zufall alle zwischen 10000,00 und 99999,99 liegen, wobei immer nur 2 Ziffern nach dem Dezimalkomma stehen, dann haben Sie ' Betrachten wir 8 Bytes pro Sample. In diesem Fall haben Sie nur den Overhead der Fremdschlüssel eingespart, sodass sich der erforderliche Speicherplatz auf 800 Byte beläuft.
Das basiert natürlich auf vielen Annahmen, wie zum Beispiel, dass die Zeichenkodierung immer 1 Byte pro Zeichen ist, die Strings, aus denen die Samples bestehen, nie länger als 8 Zeichen sind usw.
Aber natürlich gibt es auch den Overhead des Mechanismus, den Sie verwenden, um die Daten zu serialisieren. Die absolut einfachste Methode, CSV, bedeutet das Hinzufügen eines Kommas zwischen jedem Sample. Das fügt der gespeicherten Zeichenfolge n-1 Bytes hinzu. Das obige Beispiel wäre also jetzt 899 Bytes, und das mit dem einfachsten Codierungsschema. JSON-, XML- und sogar PHP-Serialisierungen fügen mehr Overhead-Zeichen als diese hinzu, und Sie werden bald Zeichenfolgen haben, die viel länger als 1600 Byte sind. Und das alles unter der Annahme einer 1-Byte-Zeichencodierung.
Wenn Sie die Samples indizieren müssen, wächst der Datenbedarf gegenüber Strings sogar noch überproportional, da ein String-Index in Bezug auf die Speicherung viel teurer ist als ein Floating-Point-Spaltenindex.
Und wenn Ihre Proben anfangen, mehr Ziffern hinzuzufügen, steigt die Datenspeicherung natürlich weiter an. 39281.3392810 wird auch im besten Fall nicht in 8 Bytes als String speicherbar sein.
Und wenn die Daten serialisiert sind, kann die Datenbank sie nicht manipulieren. Sie können die Proben nicht sortieren, irgendwelche mathematischen Operationen mit ihnen durchführen, die Datenbank weiß nicht einmal, dass es sich um Zahlen handelt!
Um ehrlich zu sein, Speicher ist heutzutage lächerlich billig, Sie können mehrere TB-Laufwerke für winzige Summen kaufen. Ist die Lagerung wirklich so kritisch? Wenn Sie nicht Hunderte von Millionen von Aufzeichnungen haben, bezweifle ich, dass dies der Fall ist.
Vielleicht möchten Sie sich ein Buch mit dem Titel SQL Antipatterns
ansehen
