PHP Problem bei SQL Abhängigkeiten

[Blackbenji]

Problem bei SQL Abhängigkeiten [fixed]

Hallo,

ich verzweifle mal wieder an meinem Projekt. Das Projekt ist ein CMS, Content Entrys lassen sich mit "Tags" (Kategorien) versehen.

Dafür habe ich 3 Tabellen:

a) content_table = enthalten id, headline, content, datetime ....
b) tag_name = enthält id, tag_name
c) tag_content = enthält id_content, id_tag

das sieht dann wie folgt aus:

1 | testeintrag | testeintrag 1234567 | 2012-08-05 21:28

1 | google
2 | apple
3 | microsoft
4 | amazon
5 | heise

1 | 2
1 | 3
1 | 1

soweit so gut, das lässt sich auch alles ausgeben.
mein problen betrifft nun das updaten der tabelle tag_content.

mein template zeigt alle möglichen tags an. nun möchte ich aber aus dem content_id 1 den tag_id 3 löschen und 5 hinzufügen.

ich stelle mich dabei aber ziemlich dämlich an.

            for($x=0; $x<count($checkbox); $x++) {
                    $querry="UPDATE ".GLOBAL_TAG_CONTENT_DB." Set tag_id = $checkbox[$x] WHERE content_id = '".$id."' ";
                    mysql_query($querry) or die ("MySQL-Fehler: " . mysql_error());
            }

dieser versuch updatet leider alle einträge mit dem jeweils letztem wert.

auch die frage: was ist wenn ein neuer eintrag hinzu kommt? habe ich noch nicht bedacht ...

hätte jemand anstöße für mich?

 

[gh0st2k]

Der einfachste Weg ist vermutlich alle Einträge für einen Content Element zu löschen und die Tags neu zu schreiben, sofern ich das richtig verstehe, dass man die gewünschten Tags beim Editieren markieren / abwählen kann.

 

[x0re]

DELETE FROM tag_content WHERE id_content = 1 AND id_tag = 3;
INSERT INTO tag_content SET id_content = 1, id_tag = 5;

 

[voodoo44]

DELETE FROM tag_content WHERE id_content = 1 AND id_tag = 3;
INSERT INTO tag_content SET id_content = 1, id_tag = 5;

Übernimm die Bedingung vom DELETE-Statement und mach daraus ein Update.

Der einfachste Weg ist vermutlich alle Einträge für einen Content Element zu löschen und die Tags neu zu schreiben, sofern ich das richtig verstehe, dass man die gewünschten Tags beim Editieren markieren / abwählen kann.

Das sollte der einfachste Weg sein. Somit kannst du einfach über dein Array foreachen und das ganze so in die Datenbank werfen. Dafür kannst du einfach eine Methode oder Funktion schreiben, die vorher ein Delete macht und danach wieder alle Datensätze einfügt. Das sollte das ganze auch etwas besser abstrahieren und dynamischer machen.

 

[dude90]

1 | 2
1 | 3
1 | 1

Wenn das deine ganzen Einträge in der tag_content sind, dann ist es auch klar das zum Schluss in allen Spalten das selbe drinnen steht.
Du guckst ja nur ob die erste Spalte =id ist und das ist bei allen 3 der Fall.
Die erste Spalte ist doch die content_id oder?

Du musst im Where noch eine zusätzliche Bedingung machen.
z.B. WHERE content_id =id AND x=id_tag

DELETE FROM tag_content WHERE id_content = 1 OR id_tag = 3;

kleiner Fehler
Ist natürlich richtig.
Man sollte erst denken und dann schreiben.

 

[voodoo44]

Wieso sollte man dort ein OR einsetzen? Dann updated man ja auch Felder, die nicht der aktuellen content-id entsprechen ...

In deinem Beispiel modifiziere ich also alle Tabellen mit:
x - 3 und 1 - x .... unpraktisch!

 

[Blackbenji]

@gh0st2k: die idee habe ich umgesetzt. funktioniert auch wunderbar!

vielen dank.

 

[AlbertLast]

Perfektionieren könntest du in dem du das noch mittel Transaktion Handling machst,
weil auf die harte methode alles löschen und wieder anlegen gibt es zumindest theoretisch eine zeit
wo eine seite bei dir keine tags hat und wenn sie in der zeit aufgerufen wird hast du/der user pech. Mit Transaktionshandling gäbe es kein Moment wo eine content taglos wäre.

 

[voodoo44]

Und wie lange wird dort eine Seite taglos sein? 0.001 Sekunden?!
Der größere Vorteil an Transaction-Handling ist imho doch eher, dass er bei ggf. fehlgeschlagenen SQL-Statements automatisiert ein Rollback auf die letzte funktionierende Version gemacht werden kann.

Wie kommst du denn darauf, dass das bei Transaktionen nicht der Fall wäre? Auch bei einer Transaktion müssen die Abfragen nacheinander durchgeführt werden - nur sammelst du sie vorher in einer Art "Pipe" und ballerst sie beim commit schlichtweg durch in die DB. Hast du da bitte Literatur zur Hand, die deine Aussage bestätigt?

 

[Daaron]

Transaktionen sind atomare Operationen und haben somit, anders als das sequentielle Durchführen einzelner Operationen, kein Problem mit Race Conditions.

 

[AlbertLast]

wenn man sich den wiki eintrag zu Transaktion anschaut: http://de.wikipedia.org/wiki/Transaktion_(Informatik)

Sieht man schon das Zauberwort ACID und die Consistency sorgt dafür, dass man von einer konsistenten Form in die nächsten wechselt.
Daher ist eine Transaktion weniger als Pipe zu sehen als mehr ein Versionswechsel, die Zeit wo die Daten gelöscht sind und noch nicht wieder hinzugefügt wurden, wäre nämlich ein inkonsistenter zustand dieser Punkt wird Transaktionshandling halt übersprungen.

Aber du hast recht der Zeitraum von diesem Zustand ist nur sehr gering aber das hatte ja schon vorher gesagt, das mehr ein theoretisches Problem ist.