Ankündigung

Einklappen
Keine Ankündigung bisher.

kombinierte tabellen, jedoch mit gleicher id?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • kombinierte tabellen, jedoch mit gleicher id?

    ich habe 2 tabellen:
    produkte:
    - prod_id
    - prod_image,
    - prod_status

    product_details:
    - prod_id
    - lang_id
    - prod_name
    - prod_desc

    wenn ich nun ein produkt anlege, so sollen die daten in die beiden tabellen eingetragen werden.
    ABER: muss ich wirklich zuerst die daten in die tabelle "produkte" einlesen, dann eine abfrage machen um die "prod_id" zu bekommen und dann die restlichen daten in die tabelle "product_details" einfügen?
    denn wie bekomme ich sonst die prod_id in die 2. tabelle rein?

    oder hab ich da einen denkfehler?

  • #2
    Du kannst die ID nach dem einfügen einfach über mysql_insert_id() abholen.

    Kommentar


    • #3
      Welchen Sinn macht eine Trennung in 2 Tabellen, wenn es sich lediglich um 7 Spalten handelt? Keinen!

      Kommentar


      • #4
        danke. auf mysql_insert_id() hatte ich komplett vergessen.
        @zergling: es handelt sich 1. um mehrere spalten, hatte hier zur veranschaulichung nur weniger gepostet und das hauptkriterium: die spalten sind vom admininterface frei erweiterbar.

        Kommentar


        • #5
          das hauptkriterium: die spalten sind vom admininterface frei erweiterbar
          Dann stimmt aber mit dem Datenbank-Konzept etwas nicht. Die Spaltenanzahl sollte nicht erweiterbar sein.

          Sinnvoll für deine 2. Tabelle:

          ID | ProduktID | (Eigenschaftsname) | Eigenschaft

          Oder besser noch eine 3. Tabelle für die Bezeichnungen der Eigenschaften (weil ja mehrere Objekte die gleichen Eigenschaften haben können) und dann alles in der anderen Tabelle zusammenführen.
          Aber keine dynamisch erweiterbare Spalten!

          Kommentar


          • #6
            Zitat von webbi
            Dann stimmt aber mit dem Datenbank-Konzept etwas nicht. Die Spaltenanzahl sollte nicht erweiterbar sein.
            Das kann durchaus sinnvoll sein. Wenn du z.B. ein mehrsprachiges CMS hast und eine Tabelle für die Begriffe in mehreren Sprachen, also z.B.
            ID | deutsch | englisch | französisch
            und der Administrator eine neue Sprache hinzufügt, dann wird auch die Tabelle erweitert, z.B
            ID | deutsch | englisch | französisch | spanisch

            Und eine dritte Tabelle braucht es nach meiner Meinung nicht, da zwischen der produkte- und der detail-Tabelle eine 1:n Beziehung besteht. Was ich eher sehe, ist ein Problem mit der Zuteilung der Attribute. Jedes Attribut, das eindeutig unique von der ID abhängt, d.h pro Artikel nur einmal vorkommen kann - z.B. der Name - gehört in die produkte-Tabelle, alle anderen zu den Details (jetzt mal vereinfacht dargestellt)

            Kommentar


            • #7
              @webbi. hatte mich verschrieben. natürlich werden nicht die spalten erweitert, sondern die sprachen. sonst wäre der vorschlag von zergling ja ok gewesen, dann hätte ich prod sprache einfach eine neue spalte hinzugefügt. lieber aber mache ich das in einer neuen tabelle mit der lang_id.
              war ein tippfehler. der sinn sollte aber auch so hervorgegangen sein, denn die lösung mit den spalten erweitern ist nicht sehr gut.

              Kommentar


              • #8
                Zitat von Promaetheus
                sonst wäre der vorschlag von zergling ja ok gewesen, dann hätte ich prod sprache einfach eine neue spalte hinzugefügt.
                Das habe nicht ich empfohlen, sondern lazydog. Von dynamischer Spaltenerweiterungen halte ich grundsätzlich nichts. Der Variable teil sind immer die Zeilen, nie die Spalten.
                Wenn doch wurde schon das Design verbockt.

                Um wieviele Spalten handelt es sich denn und sind alle Pflicht? Ansonsten könntest du wieder überlegen, eine Users Tabelle mit id | username | pflichtfelder | .. und eine UserSettings mit den optionalen Werten, aufgebaut nach user_id | key | value (zB 1 | "Anrede" | "Prof. Dr.") ..(wobei du Anrede auch wieder rausnormalisieren müsstest

                Ansonsten kann eine Aufteilung bei zuviel Pflicht-Spalten durchaus auchmal Sinn machen.

                Kommentar


                • #9
                  Wozu mysql_insert_id()? Ist doch eine MySQL-Funktion, die PHP da anspricht und die kann man doch auch direkt aufrufen.

                  Beispiel aus dem MySQL-Manual:
                  Code:
                  INSERT INTO foo (auto,text)
                      VALUES(NULL,'text');              # generate ID by inserting NULL
                  INSERT INTO foo2 (id,text)
                      VALUES(LAST_INSERT_ID(),'text');  # use ID in second table
                  Basti

                  Kommentar


                  • #10
                    und wie soll das hier funktionieren?
                    Code:
                    INSERT INTO foo (id, artikelnummer)  // id insert automatic
                         VALUES(NULL, 'artnr');
                    // 2 sprachen:
                    INSERT INTO foo2 (id, artikelname, artikelbeschreibung)
                         VALUES(LAST_INSERT_ID(), 'name1', 'beschreibung1');
                    INSERT INTO foo2 (id, artikelname, artikelbeschreibung)
                         VALUES(LAST_INSERT_ID(), 'name2', 'beschreibung2');
                    bleibt die id da bestehen? wird der wert erst verworfen wenn ein neuer datensatz in foo eingetragen wird?

                    Kommentar


                    • #11
                      ich bin mir nicht sicher, aber ich denke dazu sollte man die tabellen sperren, damit zwischen den queries nicht andere threads eine zeile einfügen und somit LAST_INSERT_ID ändern.

                      Kommentar


                      • #12
                        Hi.

                        Jo, dann musst du wohl doch PHP hernehmen...

                        @"xardie":
                        Wozu locken? Die Zuordnung ist durch die ID gegeben. Da kann dir doch zwischenreinschreiben, wer will, ohne diese zu gefährden.

                        Basti

                        Kommentar


                        • #13
                          mit einem hattest du Recht @Pro, es wäre Off-Topic geworden, mit dem Rest nicht du hast ne PM

                          Kommentar


                          • #14
                            Zitat von Basti
                            @"xardie":
                            Wozu locken? Die Zuordnung ist durch die ID gegeben. Da kann dir doch zwischenreinschreiben, wer will, ohne diese zu gefährden.
                            ich hab das bloß auf die mysql version mit LAST_INSERT_ID bezogen. wenn zwischen den beiden queries
                            Code:
                            INSERT INTO foo (auto,text) 
                                VALUES(NULL,'text');              # generate ID by inserting NULL 
                            INSERT INTO foo2 (id,text) 
                                VALUES(LAST_INSERT_ID(),'text');  # use ID in second table
                            ein weiterer thread einen INSERT in foo macht, sollte auch LAST_INSERT_ID auf den wert gesetzt werden, welche dann im ersten thread auch den neuen wert hat -> man macht den zweiten insert mit der falschen ID.

                            So genau kenne ich die abläufe in mysql/php jetzt nicht, wenn man die beiden INSERTS in einem query aufruf macht kann es gut sein dass es klappt. Aber an für sich ist das ist ein klassischer threading fehler.

                            Kommentar


                            • #15
                              Zitat von xardie
                              ich hab das bloß auf die mysql version mit LAST_INSERT_ID bezogen. wenn zwischen den beiden queries
                              Code:
                              INSERT INTO foo (auto,text) 
                                  VALUES(NULL,'text');              # generate ID by inserting NULL 
                              INSERT INTO foo2 (id,text) 
                                  VALUES(LAST_INSERT_ID(),'text');  # use ID in second table
                              ein weiterer thread einen INSERT in foo macht, sollte auch LAST_INSERT_ID auf den wert gesetzt werden, welche dann im ersten thread auch den neuen wert hat -> man macht den zweiten insert mit der falschen ID.
                              Wenn eine andere Verbindung Daten in die Datenbank schreibt, bleibt die aktuelle Verbindung davon unberührt, da sich LAST_INSERT_ID() genau wie mysql_insert_id() lediglich auf die aktuelle Verbindung bezieht.
                              Wenn du aber davon ausgehst, dass beide INSERT-Queries mit der gleichen Verbindung vorgenommen werden, ist ein LOCK der Tabellen genauso überflüssig. Dabei musst du dann lediglich die ID des ersten Eintrages erst in einer Variablen zwischenspeichern, wie dies auch schon vorher beschrieben wurde.

                              Kommentar

                              Lädt...
                              X