Datensatz in einer anderen Tabelle in einem Feld speichern

[Michel Koller]

Guten Tag

Ich entwickle ein Tool mit PHP 5 und MySQL , nun ist es notwendig das ich
einen relativ langen
schon bestehenden Datensatz in einer anderen Tabelle in einem einzigen Feld
abspeichern und auch wieder abrufen kann.

Muss ich dabei eine normale Mysql abfrage machen und den Array den es dann
gibt (zB $row) irgendwie in der anderen Tabelle in ein einziges Tabellenfeld
abzuspeichern?

Muss ich denn Array serialisieren oder welche Lösungen wären da noch
möglich?
Falls Serialisieren, davon habe ich noch keine Ahnung, mir wäre es lieber
ich könnte
den Array im Feld so abspeichern das ich ihn später einfach wieder auslesen
könnte.

Bin um jeden Tipp Dankbar
herzliche Grüsse
M.Koller

[Dominik Echterbruch]

Michel Koller wrote:
>
> Ich entwickle ein Tool mit PHP 5 und MySQL , nun ist es notwendig das ich
> einen relativ langen
> schon bestehenden Datensatz in einer anderen Tabelle in einem einzigen Feld
> abspeichern und auch wieder abrufen kann.

Das hört sich nach einem *sehr* kaputten Design an. Sicher, dass es
nicht noch andere Möglihckeiten gibt?

> Muss ich dabei eine normale Mysql abfrage machen und den Array den es dann
> gibt (zB $row) irgendwie in der anderen Tabelle in ein einziges Tabellenfeld
> abzuspeichern?

Zwei Möglichkeiten: Entweder via CONCAT die Spalten zu einem langen
String zusammenführen oder die Zeile normal abfragen und in PHP
serialisieren.

> Falls Serialisieren, davon habe ich noch keine Ahnung,

PHP-Handbuch, Stichwort "serialize".
Oder was in letzter Zeit immer beliebter wird: json_encode.

> mir wäre es lieber
> ich könnte
> den Array im Feld so abspeichern das ich ihn später einfach wieder auslesen
> könnte.

Tja, dann würde er aber nicht mehr in einem Feld stehen ;)

Grüße,
Dominik
--
Wo kämen wir hin, wenn alle sagten, wo kämen wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge.
Autor: Kurt Marti (http://de.wikiquote.org/wiki/Kurt_Marti)

[Niels Braczek]

Michel Koller schrieb:

> Ich entwickle ein Tool mit PHP 5 und MySQL , nun ist es notwendig das ich
> einen relativ langen
> schon bestehenden Datensatz in einer anderen Tabelle in einem einzigen Feld
> abspeichern und auch wieder abrufen kann.

Das ist nur sinnvoll, wenn in diesem Feld nie gesucht wird. Ich verwende
das zB. bei Versionierung zur Speicherung des alten Datensatzes.

> Muss ich dabei eine normale Mysql abfrage machen und den Array den es dann
> gibt (zB $row) irgendwie in der anderen Tabelle in ein einziges Tabellenfeld
> abzuspeichern?

Ja. Das direkt in MySQL zu machen ist extrem aufwändig, zumindest in
meinem Fall.

> Muss ich denn Array serialisieren oder welche Lösungen wären da noch
> möglich?

Logisch - du musst aus dem Datensatz einen String machen. Ich habe dafür
json_encode() benutzt, serialize() ist aber ebenso brauchbar dazu.

MfG
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Michel Koller]

> Das hört sich nach einem *sehr* kaputten Design an. Sicher, dass es
> nicht noch andere Möglihckeiten gibt?

Zuerst mal vielen Dank für die Antworten.

Es ist halt so das sich der eine, sagen wir mal Datensatz(a) ständig
verändert.
Und zu einem bestimmten Zeitpunkt (wo der User einen ganz anderen Datensatz
(sagen wir dazu Datensatz(b)) erstellt in einer anderen Tabelle) muss der
Datensatz(a) so
wie er in diesem Moment besteht, dem User zugewiesen werden.

Und das wiederholt sich dauernd der Datensatz(a) verändert ständig seine
Daten und kann dann
in seiner anderen Form wieder dem selben User DAZU zugewiesen werden.

Sodass später ein User den eigentlich selben Datensatz mehrfach(aber mit
anderen Daten gefüllt),
'besitzt'.

Ich möchte kein "Kaputtes Design", evt ist es sauberer wenn der Datensatz(b)
erstellt wird,
das dann eine Kopie des datensatz(a) gemacht wird, und einfach mit der ID
des Users in eine andere Tabelle kopiert wird.

schöne grüsse
M.Koller

[Dominik Echterbruch]

Michel Koller wrote:
>
> Es ist halt so das sich der eine, sagen wir mal Datensatz(a) ständig
> verändert.
> Und zu einem bestimmten Zeitpunkt (wo der User einen ganz anderen Datensatz
> (sagen wir dazu Datensatz(b)) erstellt in einer anderen Tabelle) muss der
> Datensatz(a) so
> wie er in diesem Moment besteht, dem User zugewiesen werden.

Ich verstehe das wie folgt:

Ein Benutzer erstellt einen Datensatz und irgendetwas passiert, was den
Datensatz verändert (z.B. automatische Zuweisung von Messdaten). Zu
beliebigen Zeitpunkten kann der Benutzer Momentaufnahmen des Datensatzes
speichern. Der ursprüngliche Datensatz verändert sich laufend weiter,
aber die Momentaufnahme bleibt in diesem Zustand bestehen und wird dem
Benutzer zusätzlich zugewiesen.

Richtig verstanden?

Leider weiß ich nicht, unter welchen Umständen sich die einzelnen
Datensätze verändern, daher kann ich kein Kochrezept anbieten. Aber
grundsätzlich würde ich es wohl so lösen, dass es nur eine Tabelle gibt,
in der alle Datensätze vorgehalten werden.

Kommt ein neuer Datensatz hinzu, ist er für die Veränderung von außen
freigegeben. Möchte ein Benutzer eine Momentaufnahme, dupliziere ich den
Datensatz und versehe ihn mit einem Flag, dass es eine Momentaufnahme
ist und wem sie zugeordnet ist.

Und das sollte es an sich gewesen sein. Mir fällt auf Basis deiner
bisherigen Angaben kein vernünftiger Grund ein, warum man dafür auf eine
getrennte Tabelle ausweichen und dort zu allem Überfluss auch noch alles
in eine Spalte kippen sollte. Das macht doch alles unnötig kompliziert
und nimmt dir viel zu viele Möglichkeiten, mit den Daten anschließend
noch zu arbeiten. Erst recht, wenn sich die Struktur der Tabelle mal
ändern sollte.

[Ulf [Kado] Kadner]

Hallo Dominik Echterbruch! Du schriebst folgendes:

> PHP-Handbuch, Stichwort "serialize".
> Oder was in letzter Zeit immer beliebter wird: json_encode.

Ich finde serialize und der json-Kram sollte nicht ohne Vorwarnung
zusammen ganannt werden. serialize kann z.B. im Gegensatz zu json_encode
auch private Member serialisisieren. Serialize und json_* haben
vollkommen unterschiedliche Einsatzszenarien. Das ist wichtig!

MfG, Ulf

[Michel Koller]

Vielen Dank Domenik

> Ich verstehe das wie folgt:
>
> Ein Benutzer erstellt einen Datensatz und irgendetwas passiert, was den
> Datensatz verändert (z.B. automatische Zuweisung von Messdaten). Zu
> beliebigen Zeitpunkten kann der Benutzer Momentaufnahmen des Datensatzes
> speichern. Der ursprüngliche Datensatz verändert sich laufend weiter, aber
> die Momentaufnahme bleibt in diesem Zustand bestehen und wird dem Benutzer
> zusätzlich zugewiesen.
>
> Richtig verstanden?

Ja ganz genau so. Momentaufname ist das Stichwort.

Grundsätzlich waren 2 Tabellen gedacht (Tabelle(A) und Tabelle (B))

In der ersten Tabelle sind die Daten des Users zB der Hockeyspieler in
diesem Datensatz
steht zB sein momentaner Klub und seine Rückennummer, Schuhgrösse etc sowie
zB die Saison 2009/10.

Nun die 2.Tabelle dort sind die Datensätze mit den Resultaten drin.

Nun trägt der Hockeyspieler nach jedem Spiel sein Resultat ect ein (erzeugt
also einen Datensatz in Tabelle B),
und dort müssen halt auch immer die Daten von Tabelle A mitdabeisein (eben
die Momentaufname).

Also erzeugt der Hockeyspieler nach jedem Spiel einen neuen Datensatz in
Tabelle B, in Tabelle A ändert er seinen
Datensatz nur wenn er den Klub wechselt oder seine Füsse gewachsen sind.

Danke für die Tipps und Gruess
M.Koller

[Dominik Echterbruch]

Michel Koller wrote:
> Vielen Dank Domenik
^
Da gehört ein i hin.

> Grundsätzlich waren 2 Tabellen gedacht (Tabelle(A) und Tabelle (B))
> In der ersten Tabelle sind die Daten des Users zB der Hockeyspieler in
> diesem Datensatz
> steht zB sein momentaner Klub und seine Rückennummer, Schuhgrösse etc sowie
> zB die Saison 2009/10.
>
> Nun die 2.Tabelle dort sind die Datensätze mit den Resultaten drin.

OK, also eigentlich ein völlig anderes "Problem". Aber die Lösung ist
ähnlich gelagert.

> Nun trägt der Hockeyspieler nach jedem Spiel sein Resultat ect ein (erzeugt
> also einen Datensatz in Tabelle B),
> und dort müssen halt auch immer die Daten von Tabelle A mitdabeisein (eben
> die Momentaufname).

Gut.

> Also erzeugt der Hockeyspieler nach jedem Spiel einen neuen Datensatz in
> Tabelle B, in Tabelle A ändert er seinen
> Datensatz nur wenn er den Klub wechselt oder seine Füsse gewachsen sind.

Dann wollen wir mal. Das mit den beiden Tabellen ist in dem Fall schon
richtig und sollte auf jeden Fall so bleiben. Was du jetzt machst, ist,
die Datensätze in B mit jeweils einem Datensatz aus A zu verknüpfen. Ich
benenne die Tabellen mal etwas um, damit es besser zu lesen ist:

spieler(_id_, schuhgroesse, rueckennummer, verein, alt)
ergebnis(_id_, spieler_id, datum, gegner, tore_gegner, tore_eigene)

In spieler trägt der Spieler seine Daten ein. Wenn sich daran etwas
ändert, wird der aktuelle Datensatz als "alt" markiert und ein neuer
Datensatz mit den geänderten Daten angelegt. Auf diese Weise bleiben die
Änderungen immer nachvollziehbar.

In ergebnis trägt der Spieler immer die Partiedaten ein. Beim Speichern
wird die ID des Datensatzes aus spieler in spieler_id eingetragen, die
gerade NICHT als alt markiert ist. Damit gehört zu jedem Datensatz in
ergebnis genau der Datensatz aus spieler, der zu dem Zeitpunkt aktuell war.

Abgefragt wird das Ganze dann mit einem simplen JOIN.
SELECT * FROM ergebnis e INNER JOIN spieler s ON s.id = e.spieler_id

[Michel Koller]

Hallo Dominik

> Dann wollen wir mal. Das mit den beiden Tabellen ist in dem Fall schon
> richtig und sollte auf jeden Fall so bleiben. Was du jetzt machst, ist,
> die Datensätze in B mit jeweils einem Datensatz aus A zu verknüpfen. Ich
> benenne die Tabellen mal etwas um, damit es besser zu lesen ist:
>
> spieler(_id_, schuhgroesse, rueckennummer, verein, alt)
> ergebnis(_id_, spieler_id, datum, gegner, tore_gegner, tore_eigene)
>
> In spieler trägt der Spieler seine Daten ein. Wenn sich daran etwas
> ändert, wird der aktuelle Datensatz als "alt" markiert und ein neuer
> Datensatz mit den geänderten Daten angelegt. Auf diese Weise bleiben die
> Änderungen immer nachvollziehbar.
>
> In ergebnis trägt der Spieler immer die Partiedaten ein. Beim Speichern
> wird die ID des Datensatzes aus spieler in spieler_id eingetragen, die
> gerade NICHT als alt markiert ist. Damit gehört zu jedem Datensatz in
> ergebnis genau der Datensatz aus spieler, der zu dem Zeitpunkt aktuell
> war.
>
> Abgefragt wird das Ganze dann mit einem simplen JOIN.
> SELECT * FROM ergebnis e INNER JOIN spieler s ON s.id = e.spieler_id

Vielen dank, ich denke du hast mir geholfen den bestmöglichen weg zu meinem
Ziel zu finden,
ich vermute das so die Datenbank am wenigsten belastet wird.

vielen Dank und Gruss
Mihel Koller

[Michael Fesser]

.oO(Dominik Echterbruch)

>Dann wollen wir mal. Das mit den beiden Tabellen ist in dem Fall schon
>richtig und sollte auf jeden Fall so bleiben. Was du jetzt machst, ist,
>die Datensätze in B mit jeweils einem Datensatz aus A zu verknüpfen. Ich
>benenne die Tabellen mal etwas um, damit es besser zu lesen ist:
>
>spieler(_id_, schuhgroesse, rueckennummer, verein, alt)
>ergebnis(_id_, spieler_id, datum, gegner, tore_gegner, tore_eigene)
>
>In spieler trägt der Spieler seine Daten ein. Wenn sich daran etwas
>ändert, wird der aktuelle Datensatz als "alt" markiert und ein neuer
>Datensatz mit den geänderten Daten angelegt. Auf diese Weise bleiben die
>Änderungen immer nachvollziehbar.

Statt des 'alt'-Flags könnte man auch ein TIMESTAMP-Feld nehmen, welches
automatisch das Erstelldatum des Datensatzes bekommt. Dann braucht man
beim Anlegen eines neuen Datensatzes kein zusätzliches UPDATE mehr, um
den vorherigen als alt zu markieren.

Micha