Doppelte Einträge vermeiden...

[Mike²]

Hallo Zusammen,

nachdem ich mich jetzt ein wenig durch die Suche gearbeitet habe, hänge ich immer noch an meinem Problem fest.

Ich lasse mir in meinen PHP-Script durch folgenden Code Eintragungen in meine DB machen:

PHP-Code:

   mysql_query("INSERT INTO tabelle (userid, first, last, name, type, punkte, summe) VALUES ('$UserID', '$First', '$Last', '$Name', '$Type', '$Punkte', '$Summe') or die("<br>Fehler beim verarbeiten der Datenbank. Fehlermeldung: ".mysql_error()); 


Funktioniert auch optimal.
Nur ist das Problem, das bei jedem Eintrag eine komplett neue Zeile eingefügt wird.

Die Variable '$Name' soll aber in Zusammenhang mit der '$UserID' nur einmal vorkommen.
D. h. die Datenbank sollte zuerst überprüft werden, ob der Wert '$Name' bereits vorhanden ist.
Und wenn ja, dann nur ein UPDATE der Zeile ausfüren und nicht die Zeile zusätzlich einfügen.

Ich hoffe, ich konnte es verständlich rüberbringen.

Gruß Mike²

[xabbuh]

Hast du dir schon mal die Klausel INSERT ... ON DUPLICATE KEY UPDATE oder REPLACE angesehen?

[Mike²]

Ja, das habe ich bereits.
Doch es wird immer von einem Unique im Feld gesprochen.
Dies kann ich ja aber wegen den verschiedenen UserID´s nicht machen. Oder?

Ich hab mir so was in etwa vorgestellt:

PHP-Code:

if(??? UserID & Name bereits vorhanden ???)
{
mysql_query("UPDATE tabelle (userid, first, last, name, type, punkte, summe) VALUES ('$UserID', '$First', '$Last', '$Name', '$Type', '$Punkte', '$Summe')");
}
else
{
mysql_query("INSERT INTO tabelle (userid, first, last, name, type, punkte, summe) VALUES ('$UserID', '$First', '$Last', '$Name', '$Type', '$Punkte', '$Summe')");
} 


Ist das auch so realisierbar???

[KTB]

Klar ist das so realisierbar. Du musst dann blos vorher durch die Tabelle laufen und nach dem Datensatz suchen. Wenn du ein leeres Ergebnis zurück bekommst, "INSERT" sonst "UPDATE".

[xabbuh]

Was spricht dagegen einen UNIQUE-Index über die Spalte name zu legen?

[Mike²]

Zitat von KTB

Klar ist das so realisierbar. Du musst dann blos vorher durch die Tabelle laufen und nach dem Datensatz suchen. Wenn du ein leeres Ergebnis zurück bekommst, "INSERT" sonst "UPDATE".

Jetzt ist nur noch die Frage, wie ich sowas realisiere? Kleiner Denkanstoß?

Zitat von xabbuh

Was spricht dagegen einen UNIQUE-Index über die Spalte name zu legen?

Wenn ich nen Unique über die Spalte "name" lege, kann der Wert ja nur einmal komplett gleich vorhanden sein.
Ich möchte es aber in Abhänigkeit der UserID, d.h. jeder User kann den Wert einmal besitzen.

[xabbuh]

Zitat von Mike²

Wenn ich nen Unique über die Spalte "name" lege, kann der Wert ja nur einmal komplett gleich vorhanden sein.
Ich möchte es aber in Abhänigkeit der UserID, d.h. jeder User kann den Wert einmal besitzen.

Du willst also, dass lediglich die Kombination aus UserID und Name eindeutig sein muss? Dann lege doch einen UNIQUE-Index über diese beiden Spalten:

CREATE UNIQUE INDEX id_name ON tabelle (UserID, Name);

[Mike²]

Zitat von xabbuh

Du willst also, dass lediglich die Kombination aus UserID und Name eindeutig sein muss? Dann lege doch einen UNIQUE-Index über diese beiden Spalten:

CREATE UNIQUE INDEX id_name ON tabelle (UserID, Name);

Also das ist wohl nicht ganz das, was ich suche.
Es soll ganz einfach ein Unique des "Name"-Wertes vorhanden sein der sich auf die UserID bezieht.
Vielleicht bringe ich das nicht verständlich genug rüber... :-(
Aber ohne ne Abfrage wird das nicht klappen.
Wirklich niemand nen Ansatz?

[xabbuh]

Zitat von Mike²

Es soll ganz einfach ein Unique des "Name"-Wertes vorhanden sein der sich auf die UserID bezieht.
Vielleicht bringe ich das nicht verständlich genug rüber... :-(

Scheinbar nicht. Woran machst du fest, ob ein Name eindeutig ist? Am besten zeigst mal ein paar Beispieldatensätze, was bei dir Eindeutigkeit bedeuten würde und was nicht.

[Mike²]

Eigentlich ist es ganz simpel:
Die Daten werden durch einen Parser ausgelesen und sollen in die DB geschrieben werden.
In etwa sieht das dann so aus:

userid | name                 | gebdatum   | ort       | famstand
-----------------------------------------------------------------
12110  | ottowalkes           | 10.01.2000 | koeln     | ledig
12110  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet
12110  | armoldschwarzenegger | 27.12.2005 | stuttgart | verwitwet
12110  | michaeljackson       | 05.04.1955 | newyork   | verliebt
12110  | rudivoeller          | 11.11.2000 | bagdad    | geschieden
12110  | angelamerkel         | 01.01.1891 | potsdam   | offen für alles
12110  | oliverkahn           | 19.07.2006 | muenchen  | ledig

Sollte ein ander User eventuell gleiche Daten eingeben (BSP):

userid | name                 | gebdatum   | ort       | famstand
-----------------------------------------------------------------
18451  | ottowalkes           | 10.01.2000 | koeln     | ledig
18451  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet

Dann erscheint das ganze in der DB so:

userid | name                 | gebdatum   | ort       | famstand
-----------------------------------------------------------------
12110  | ottowalkes           | 10.01.2000 | koeln     | ledig
12110  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet
12110  | armoldschwarzenegger | 27.12.2005 | stuttgart | verwitwet
12110  | michaeljackson       | 05.04.1955 | newyork   | verliebt
12110  | rudivoeller          | 11.11.2000 | bagdad    | geschieden
12110  | angelamerkel         | 01.01.1891 | potsdam   | offen für alles
12110  | oliverkahn           | 19.07.2006 | muenchen  | ledig
18451  | ottowalkes           | 10.01.2000 | koeln     | ledig
18451  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet

Hat jetzt aber User 12110 seine Daten aktuallisiert und füttert die DB erneut mit (BSP):

userid | name                 | gebdatum   | ort       | famstand
-----------------------------------------------------------------
12110  | ottowalkes           | 10.01.2000 | dortmund  | ledig (Umgezogen von Köln nach Dortmund)
12110  | rudivoeller          | 11.11.2000 | bagdad    | verliebt (Nicht mehr geschieden sondern verliebt)

Erscheint es in meiner DB so:

userid | name                 | gebdatum   | ort       | famstand
-----------------------------------------------------------------
12110  | ottowalkes           | 10.01.2000 | koeln     | ledig
12110  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet
12110  | armoldschwarzenegger | 27.12.2005 | stuttgart | verwitwet
12110  | michaeljackson       | 05.04.1955 | newyork   | verliebt
12110  | rudivoeller          | 11.11.2000 | bagdad    | geschieden
12110  | angelamerkel         | 01.01.1891 | potsdam   | offen für alles
12110  | oliverkahn           | 19.07.2006 | muenchen  | ledig
18451  | ottowalkes           | 10.01.2000 | koeln     | ledig
18451  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet
12110  | ottowalkes           | 10.01.2000 | dortmund  | ledig 
12110  | rudivoeller          | 11.11.2000 | bagdad    | verliebt

Doch ich hätte die beiden Zeilen gerne nur aktualisiert:

userid | name                 | gebdatum   | ort       | famstand
-----------------------------------------------------------------
12110  | ottowalkes           | 10.01.2000 | dortmund  | ledig
12110  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet
12110  | armoldschwarzenegger | 27.12.2005 | stuttgart | verwitwet
12110  | michaeljackson       | 05.04.1955 | newyork   | verliebt
12110  | rudivoeller          | 11.11.2000 | bagdad    | verliebt
12110  | angelamerkel         | 01.01.1891 | potsdam   | offen für alles
12110  | oliverkahn           | 19.07.2006 | muenchen  | ledig
18451  | ottowalkes           | 10.01.2000 | koeln     | ledig
18451  | sylversterstallone   | 15.06.1981 | berlin    | verheiratet

Es müßte also vor jedem Eintrag überprüft werden, ob der Name bereits vorhanden ist.
Und wenn ja, dann soll diese Zeile nur aktualisiert werden.
D.h.: Jeder "name" kann bei jeder "userid" vorkommen, aber jedesmal nur ein mal.

Ich hoffe es ist jetzt verständlich...

PS:
Die Daten hab ich mal schnell erfunden, also keine Sorge.
Angela ist nicht so alt :-)