MySQL Update on duplicate Key

Blickwinkelkanone · 17. Juni 2020

Hallo zusammen,

ich habe hier ein kleines Problem und sehe den Fehler nicht.

Es soll etwas in die Datenbank eingefügt werden.

Die Tabelle sieht so aus

ID (KEY)

room (unique)

name

seats

Die ID hole ich mir vorher aus der Datenbank und weise diese dem Datensatz zu. Die anderen werte kommen aus einem Formular. Alle Werte, die in $result kann kann ich ausgeben und sehen und scheinen korrekt gefüllt zu sein. Nur das Insert/UPdate funktioniert nicht.

Aber warum?

Hat jemand einen frischen Kopf und Augen für das Problem?

Danke sehr

Code

$statement = $db->prepare("INSERT INTO vs_rooms (id, room, name, seats) VALUES (:id, :room, :name, :seats) 
                                               ON DUPLICATE KEY UPDATE
                                               id = :id,
                                               room = :room,
                                               name = :name,
                                               seats = :seats");
                    $result = $statement->execute(array(
                        ':id' => $id_select,
                        ':room' => $room,
                        ':name' => $name,
                        ':seats' => $seats                        
                    ));

Alles anzeigen

Hat sich erledigt. Ich habe ei Doppelpunkt vergessen gehabt udn den einach nicht gesehen...

cottton · 17. Juni 2020

Zitat von Blickwinkelkanone

Hat sich erledigt.

Ok.

Zitat von Blickwinkelkanone

vs_rooms

Warum? Ich meine, warum kann man denn nicht einfach richtige Namen vergeben

BTW: Mehrzahl ist ungünstig.

Beispiel:

SQL

SELECT * 
FROM rooms
JOIN floors on rooms.id = floors.rooms_id 
WHERE rooms.name = '...'
;

Liest sich falsch, oder?

Eine Tabelle sollte in der Einzahl benannt werden:

SQL

SELECT * 
FROM room
JOIN floor on room.id = floor.room_id 
WHERE room.name = '...'
;

Also zB "user" statt "users", "car" statt "cars", ... .

Bei Spalten ist das was anderes.

In deinem Beispiel hast Du seats. Ich gehe davon aus, dass hier die Anzahl stehen wird. Oder doch nur, ob es Sitze gibt?

Würde eher seat_count empfehlen.

Du siehst sofort, worum es geht.

Und ... rooms.room - was ist das?

Code

[
    'id'    => 1,
    'room'  => '', // ?
    'name'  => 'Living Room',
    'seats' => 'Yes', // :D
]

Jaws · 17. Juni 2020

Zitat von cottton

Eine Tabelle sollte in der Einzahl benannt werden:

Also zB "user" statt "users", "car" statt "cars", ... .

Nein, "sollte" ist auf jeden Fall falsch und die Benennung nach Einzahl oder Mehrzahl entweder

a) eine Glaubensfrage, oder

b) ein firmeninterner Regelungsgegenstand , oder

c) eine Geschmacksfrage.

Bei mir z. B. werden Tabellen grundsaetzlich nach der Mehrzahl benannt, sofern dies moeglich ist. Die Begründung ist für mich auch logisch: Eine Tabelle, die viele XYZ verwalten soll, heisst dann eben xyzs (Mehrzahl) und nicht xyz (Einzahl). So kann man auch leicht zwischen einer Gruppe - z. B. Array $xyzs - und einem einzelnen Objekt - z. B. String $xyz - unterscheiden.

cottton · 18. Juni 2020

Zitat von Jaws

Nein, "sollte" ist auf jeden Fall falsch und die Benennung nach Einzahl oder Mehrzahl entweder

a) eine Glaubensfrage, oder

b) ein firmeninterner Regelungsgegenstand , oder

c) eine Geschmacksfrage.

Ja klar, kann man sich streiten, muss man aber nicht.

Das gibts im Netz genug.

Zitat von Jaws

Bei mir z. B. werden Tabellen grundsaetzlich nach der Mehrzahl benannt, sofern dies moeglich ist. Die Begründung ist für mich auch logisch: Eine Tabelle, die viele XYZ verwalten soll, heisst dann eben xyzs (Mehrzahl) und nicht xyz (Einzahl). So kann man auch leicht zwischen einer Gruppe - z. B. Array $xyzs - und einem einzelnen Objekt - z. B. String $xyz - unterscheiden.

Naja, das machst Du so lange, wie Du darfst. Also bis Dir dein Chef, oder Kunde was anderes sagt.

Ich werd mich hier bestimmt nicht deswegen streiten

Aber Dein Argument, dass es immer mehrere (rows) in einer Tabelle gibt, ist mMn keins. Alle Tabellen haben mehrere (rows). Und jetzt kannst Du das wieder gegen mich verwenden

Dein Argument, dass mann zwischen einer Gruppe und einem Object unterscheiden kann, ist auch komisch (nur meine Meinung).

Denn Das entscheidet doch dann der Code - also die Variablenbenennung.

BTW: Code und Objects -

wenn Du mit Models zu tun hast, dann wird es schnell seltsam:

manche Models sind clever geschrieben, und erwarten, dass der Tabellenname strtolower(classname) heißt.

Also Class UserLogin {} dann als user_login.

Die musst Du dann immer explizit angeben.

Du musst das Naming dann auch durch alle Ebenen durchziehen (oder ständig ändern, aber dann ist user mal user und auf einmal users oO?).

Bsp:

Code

Meiner Meinung nach "negativ" Bsp:
tabellen name:  users
pfad:
             src/
                 Model/     -- order hier schon Models? :D
                     Users  -- mehrzahl? Ist doch aber nur das model für einen User oO?

Meiner Meinung nach "positiv" Bsp:
tabellen name:  user
pfad:
             src/
                 Model/
                     User

Alles anzeigen

Auch ja - zwecks "user_login" - Thema Detailtabellen (oder halt Tabellen in Bezug auf andere):

Code

Meiner Meinung nach "positiv" Bsp:
tbl user
tbl user_login
tbl user_login_attempt

Meiner Meinung nach "negativ" Bsp:
tbl users
tbl users_log_ins
tbl users_log_ins_attempts

Ich will Dich nicht unbedingt Überzeugen. Aber ich finde, das sind schon gute Argumente =)

Jaws · 18. Juni 2020

Zitat von cottton

Ich will Dich nicht unbedingt Überzeugen. Aber ich finde, das sind schon gute Argumente =)

Ja, so hat jeder seine Argumente.

Wenn das im MVC-Naming so klappt, ist das selbstverstä#mdlich gerechtfertigt. Womit ich nicht sagen will, dass MVC an sich gerechtfertigt wäre, aber wenn das der Standard ist, der sich durchgesetzt hat, tja, was soll man machen.

Wenn man deine (Code-Beispiele für bestimmte Anwendungsfälle) mal weglässt und sich wieder auf die Sache konzentriert, sind auch die von dir gestellten Fragen leicht zu beantworten:

Werden im Ordner "Model" mehrere Models verwaltet, wird er zu "Models"

Der Ordner "User" in der obigen Struktur fällt ja schon völlig raus, weil er nur noch eine Eigenschaft eines Models ist. Nur weil etwas so oder so ähnlich benannt wird wie eine Tabelle, muss es nicht zwangsläufig dasselbe bedeuten.

Sinnvoller wäre es in der obigen Struktur, den Ordner "Usermodels" (Mehrzahl) anzulegen,. dann weiss man auch gleich, was eigentlich gemeint ist.

Aber Standards sind halt ein enges Korsett.

MySQL Update on duplicate Key

Jetzt mitmachen!

Teilen