[SQL allgemein] Verknüpfte Tabellen erst nach Abfrage bekannt...

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

  • [SQL allgemein] Verknüpfte Tabellen erst nach Abfrage bekannt...

    Hallo,

    ich habe folgendes Problem: In einer Tabelle stehen Shop-Daten (produkt_ID, katalog_ID, anzahl, user_ID, datum). Nun will ich zur Ausgabe natürlich nicht nur die Produkt_ID ausgeben, sondern auch alle anderen Daten zu diesem Produkt (Preis, Produktname, Produktbeschreibung etc.). Diese stehen in vielen verschiedenen Katalog-Tabellen. Das wäre an sich ja alles noch kein Problem, nur dass ich zum Zeitpunkt der Abfrage nicht weiss, aus welcher Tabelle ich diese zusätzlichen Daten ziehen muss. Die Information steckt nämlich in der katalog_ID.

    Ich habe bisher 3 Ansätze, die mich aber alle nicht wirklich zufrieden stellen:

    1.: Eine Abfrage für die Shop-Daten, eine weitere pro Datensatz. Das würde bedeuten, dass ich bei 100 Produkten, 101 Abfragen hätte.

    2.: Eine Abfrage für die Shop-Daten, verknüpft mit allen anderen Katalog-Tabellen, abhängig von der katalog_ID. Das sähe dann z.B. so aus:
    SELECT
    produkt_ID, katalog_ID, produktbeschreibung, preis
    FROM
    shoptabelle
    LEFT JOIN katalog1 ON katalog1.produkt_ID = shoptabelle.produkt_ID AND katalog_ID = 1
    LEFT JOIN katalog2 ON katalog2.produkt_ID = shoptablelle.produkt_ID AND katalog_ID = 2
    LEFT JOIN ...
    Das sieht an sich schon ganz gut aus, da ich ja nur eine Abfrage hätte. Das Problem ist aber, dass es nicht nur ein oder zwei weitere Kataloge gibt, sondern um die 100. Es würde also eine riesen Abfrage entsehen.

    3.: Ich mache eine Abfrage für die Shop-Daten sortiert nach katalog_ID und mache dann immer eine zusätzliche Abfrage für alle Produkte von katalog1, katalog2, usw. Das würde bedeuten, dass ich maximal die Anzahl der Kataloge + 1 Abfragen hätte.

    Z.Z. benutze ich die dritte Variante, wäre aber sehr glücklich über Verbesserungsvorschläge !

    Vielen Danke, Roogla

  • #2
    wasfür ein DB-Design und genau hier sollst du anfangen.

    Kommentar


    • #3
      Hmm.....gib mal ein Ansatzpunkt, was du bei dem Design anders machen würdest ? Was die Katalog-Tabellen angeht, habe ich keine Möglichkeit, die anders unterzubringen. Die bekomme ich von den Lieferanten so. Die einzige Möglichkeit, die ich noch sehe, wäre, die benötigten zusätzlichen Daten aus den Katalog-Tabellen mit in der Shop-Tabelle zu speichern.
      Finde ich persönlich aber nicht so schön (Redudanz ?!?).

      Bye Roogla

      Kommentar


      • #4
        es kann doch nicht sein, dass du zwar ein kat_id hast, aber nicht weisst, zu welcher Tabelle kat_id gehört. Also mach was, dass die kat_id auch eindeutig zu einer Tabelle verweist.

        Kommentar


        • #5
          Hmm..ich glaube, da hab ich mich wohl ein wenig schlecht ausgedrückt :-) Natürlich weiss ich, welche katalog_ID zu welcher Tabelle gehört.

          Ich habe also folgende Daten (woher auch immer ich die kriege, ist jetzt zweitrangig):
          katalog_ID / Tabelle
          1 / katalogtabelle1
          2 / katalogtabelle2
          3 / katalogtabelle3
          .
          .
          100 / katalogtabelle100

          Jetzt habe ich eine Tabelle mit den Shop-Daten:
          produkt_ID / katalog_ID / user_ID
          000542 / 01 / 1
          987234 / 01 / 2
          782360 / 03 / 2
          000542 / 75 / 1
          629764 / 99 / 5

          So...jetzt weiss ich, welches Produkt zu welchem Katalog gehört. Aber die einzige Möglichkeit, alle Daten mit einer Abfrage hinzukriegen, waere die, die ich unter 2. in meinem ersten Post beschrieben habe.

          Ich hoffe, jetzt ist es ein wenig klarer

          Roogla

          Kommentar


          • #6
            trotzdem ist es ein Unding, hunderte von Kat-Tabelle zu verwalten anstatt eine. Wenn die Daten von Lieferant kommen muss du ja auch lokal bei dir importieren. Warum nich alles in einer Tabelle? Egal, du muss dich damit herum ärgern, nicht ich

            die Beste und die schnellste Lösung ist, dass du clientseitig löst, somit sprichst du jeweils nur 2 Tabellen an und dadurch viel schneller ans Ziel kommst., da sonst muss die DBMS bei jedem DS in Shopdaten 100te von Tabellen durchsuchen um zu prüfen, ob der Join gültig ist,

            Kommentar


            • #7
              Hallo!
              Bei 100 JOINs ist die Performance verheerend, auch wenn es nur ein SQL ist...

              Mach doch ALLE Kataloge in EINE Tabelle.
              Wenn Du die Daten so bekommst heisst das ja nicht, dass Du sie auch so verarbeiten musst.

              Kommentar

              Lädt...
              X