Ankündigung

Einklappen
Keine Ankündigung bisher.

Update von zwei Tabellen

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Update von zwei Tabellen

    Ich habe gerade ein Brett vor dem Kopf und brauche Unterstützung für die Lösung meines Problems:

    Ich möchte zwei Tabellen gleichzeitig aktualisieren. In einer steht nur ein Datensatz, nämlich die Bestellnummer. In Der zweiten stehen ggfs. mehere Datensätze mit der Angabe der Bestellnummer. Wenn die Bestellnummer geändert wird, soll diese in der einen Spalte der einen Tabelle und in ALLEN Spalten der anderen Tabelle geändert werden. Zur Erklärung: In Tabelle 1 stehen die Bestelldaten, in Tabelle 2 stehen die bestellten Artikel drin.

    Mein Ansatz aktualisiert immer nur eine Zeile in jeder Tabelle, aber nicht alle Spalten von Tabelle 2. In meinem Beispiel soll für die Bestellung mit der ID32 die Bestellnummer geändert werden:

    PHP-Code:
    UPDATE `orderso, `itemsi SET o.po 'TEST'i.po 'TEST' WHERE (o.oid '32' AND o.po=i.po
    Mag mir jemand helfen???

  • #2
    Wo ist das Problem es erst mal mit zwei Updates nacheinander zu versuchen?

    Kommentar


    • #3
      Zitat von protestix Beitrag anzeigen
      Wo ist das Problem es erst mal mit Updates nacheinander zu versuchen?
      Kein Problem, das funktioniert. Aber ich möchte es gerne in einem Abwasch erledigen, was wohl auch möglich ist wenn ich wüßte was ich falsch mache.

      Kommentar


      • #4
        Code:
        UPDATE orders o
        LEFT JOIN items i ON o.po = i.po
        SET o.po = 'test', i.po = 'test'
        WHERE o.oid = 32
        Grade bemerkt: Es wird die Spalte mit dem JOIN Kriterium aktualisiert... sobald in "order" der Wert geändert wird, greift der JOIN nicht mehr (dh. es werden keine items mehre gefunden / geändert).

        Abhilfe schafft ein eigenständiges JOIN Kriterium, das nicht im Update enthalten ist. Dann werden auch alle Spalten in items aktualisiert.
        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar


        • #5
          Was du falsch machst sag dir die Datenbank. Dazu musst du die Fehler der DB abfragen und ausgeben.

          Kommentar


          • #6
            Zitat von Jenna Beitrag anzeigen
            Ich habe gerade ein Brett vor dem Kopf und brauche Unterstützung für die Lösung meines Problems:

            Ich möchte zwei Tabellen gleichzeitig aktualisieren. In einer steht nur ein Datensatz, nämlich die Bestellnummer. In Der zweiten stehen ggfs. mehere Datensätze mit der Angabe der Bestellnummer. ...
            Ist die Bestellnummer in der 1. Tabelle Primärschlüssel? Wenn nicht ist es ein falsches Datenmodell. Aber auch im anderen Fall ist es schlecht. In der 1. Tabelle sollte die Bestellnummer eindeutig sein, aber der Primärschlüssel sollte ein numerischer Autoincrement-Wert sein. Dieser, und nicht die Bestellnummer wird dann als FK in der 2. Tabelle gespeichert.

            Poste bitte einen db-Dump von den wichtigsten Tabellen in diesem Kontext mit Testdaten.

            Kommentar


            • #7
              Zitat von protestix Beitrag anzeigen
              Was du falsch machst sag dir die Datenbank. Dazu musst du die Fehler der DB abfragen und ausgeben.
              Du meinst es sicher nur gut, aber die Datenbank gibt ja keinen Fehler aus, weil meine Abfrage korrekt war. Sie gibt nur nicht das erwünschte Ergebnis!

              Zitat von lstegelitz Beitrag anzeigen

              UPDATE orders o
              LEFT JOIN items i ON o.po = i.po
              SET o.po = 'test', i.po = 'test'
              WHERE o.oid = 32
              Fantastisch, so geht es. Habe vielen Dank für Deine wertvolle Hilfe. Echt super, ich freue mich riesig!

              Kommentar


              • #8
                Zitat von Alf2016 Beitrag anzeigen
                Ist die Bestellnummer in der 1. Tabelle Primärschlüssel? Wenn nicht ist es ein falsches Datenmodell. Aber auch im anderen Fall ist es schlecht. In der 1. Tabelle sollte die Bestellnummer eindeutig sein, aber der Primärschlüssel sollte ein numerischer Autoincrement-Wert sein. Dieser, und nicht die Bestellnummer wird dann als FK in der 2. Tabelle gespeichert.

                Poste bitte einen db-Dump von den wichtigsten Tabellen in diesem Kontext mit Testdaten.
                Primärschlüssel ist die ID mit Autoincrement. - Grund ist, daß die Bestellnummern auch mal alphanumerisch sein könnten. Daß die Bestellnummer eindeutig ist, prüft mein Script vor dem Speichern durch Abfrage. Ich verstehe Deinen Einwand, aber ich bin erstmal so zufrieden wenn es funktioniert.

                Danke Euch allen und von meiner Seite aus: Bitte Thread schließen.

                Kommentar


                • #9
                  Bitte noch den Kommentar lesen, den ich nachträglich eingefügt habe...
                  Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                  Kommentar


                  • #10
                    Zitat von lstegelitz Beitrag anzeigen
                    Code:
                    UPDATE orders o
                    LEFT JOIN items i ON o.po = i.po
                    SET o.po = 'test', i.po = 'test'
                    WHERE o.oid = 32
                    Grade bemerkt: Es wird die Spalte mit dem JOIN Kriterium aktualisiert... sobald in "order" der Wert geändert wird, greift der JOIN nicht mehr (dh. es werden keine items mehre gefunden / geändert).

                    Abhilfe schafft ein eigenständiges JOIN Kriterium, das nicht im Update enthalten ist. Dann werden auch alle Spalten in items aktualisiert.
                    Ja, habe ich auch gerade beim Umsetzen gemerkt. Immerhin verstehe ich jetzt warum die Datenbank sich so verhält, dank Deiner Erklärung.

                    Kommentar


                    • #11
                      Zitat von Alf2016 Beitrag anzeigen
                      Ist die Bestellnummer in der 1. Tabelle Primärschlüssel? Wenn nicht ist es ein falsches Datenmodell.
                      Warum das denn?

                      Beispiel warum das nicht sein muss
                      Code:
                      Tabelle Bestellung
                      Id   Bestellnr   Datum-Zeit         etc.
                      2456 pk345/454   2019-01-13 10:14
                      2457 pk345/455   2019-01-13 10:23
                      
                      Tabelle Bestellte_Artikel
                      Id   Bestellung_Id Bestellnr  Artikel_nr Anzahl etc.
                      1201 2456          pk345/454  1001       2
                      1202 2456          pk345/454  4501       1
                      1203 2457          pk345/455  2345       1
                      Jetzt soll die Bestellung pk345/454 mit der Bestellung pk345/455 zusammen gefasst werden und unter einer Bestellnummer laufen.

                      Nach der Änderung
                      Code:
                      Tabelle Bestellung
                      Id   Bestellnr   Datum_Zeit         etc.
                      2456 pk345/455   2019-01-13 10:14
                      2457 pk345/455   2019-01-13 10:23
                      
                      Tabelle Bestellte_Artikel
                      Id   Bestellung_Id Bestellnr  Artikel_nr Anzahl etc.
                      1201 2456          pk345/455  1001       2
                      1202 2456          pk345/455  4501       1
                      1203 2457          pk345/455  2345       1
                      Man sieht genau wann bestellt wurde und wie es zusammengehört.

                      Kommentar


                      • #12
                        Zitat von Alf2016 Beitrag anzeigen
                        ..der Primärschlüssel sollte ein numerischer Autoincrement-Wert sein.
                        Dazu gibt es keine Vorschriften. Die einzige für Primärschlüssel lautet:
                        Eindeutigkeit

                        Der Schlüssel kann also ohne Auto, dekrement, random oder anders enstehen und er darf auch alphanumerisch, date ... sein. Im Zweifel wird sich die Datenbank selbst beim ein oder anderen Typen weigern.
                        Das kann man also weitgehend nach eigenem Bedarf, Lust und Laune gestalten.

                        Kommentar


                        • #13
                          Zitat von Perry Staltic Beitrag anzeigen
                          Dazu gibt es keine Vorschriften. Die einzige für Primärschlüssel lautet:
                          Eindeutigkeit

                          ...
                          Ob es dazu Vorschriften gibt, ist eine Frage, die ich denen überlasse, die Vorschriften brauchen um sich sicherer zu fühlen. Jedenfalls gibt es Gepflogenheit und mehr oder weniger gravierende Verstöße gegen diese. Und genau wie Dein "Select *" ist die Änderung eines Primärschlüssels ein Verstoß gegen diese Gepflogenheiten. Unter anderem, weil es die Eindeutigkeit gefährdet.

                          Kommentar


                          • #14
                            Ich komm nicht mehr mit!?!
                            Es gibt hier 13 Beiträge und nur einer ist von Perry Staltic. Dort hat er doch kein SELECT... Beispiel gebracht.
                            Und genau wie Dein "Select *"
                            Wo holst du das nur alles her?

                            SELECT * ist zudem einwandfreies SQL.
                            Das wir Anfängern raten, sich diese Schreibweise nicht anzugewöhnen, rührt aus ganz anderen Aspekten heraus.

                            Kommentar


                            • #15
                              Alf2016 also selbst wenn Vorschriften Dir egal sind und Du Dich lieber an "Gepflogenheiten" hälst:
                              Wie sieht denn die "Gefährdung" aus?

                              Es gibt keine!
                              Man definiert einen Primärschlüssel, von da an sorgt die DB dafür, dass keine Gefahr besteht. Egal welchen Typ der Schlüssel hat. Das ist ja das Tolle eines solchen Systems. Es garantiert die definierten Eigenschaften der Tabellen und Spalten. Und da wir hier von binären Systemen reden, von 0 und 1, schwarz und weiß, gibt es keine Gefahr. Es gibt keinen Wert der nahe am Uneindeutigen ist oder nahe daran, die Mechnismen der DB zu überlisten, auch nicht heimtückisch.

                              Aprops "sicher fühlen": Wenn die Vorschrift lockerer ist, als Deine Gepflogenheiten, wie ergibt Dein Einwand dann Sinn?

                              Kommentar

                              Lädt...
                              X