Ankündigung

Einklappen
Keine Ankündigung bisher.

ID aus zweiter Datenbank abfragen, mit Alternative

Einklappen

Neue Werbung 2019

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

  • ID aus zweiter Datenbank abfragen, mit Alternative

    Hi,
    ich habe eine Hauptdatenbank mit Rechnungen, welche eine Spalte "Contact" enthält und eine weitere Datenbank, welche die Kontakte verwaltet.
    In der Spalte "Contact" soll entweder die ID eines zugehörigen Kontakts aus der zweiten Datenbank hinterlegt werden, über welche aus der Contact-Datenbank der Name des entsprechenden Kontakts geladen wird, oder alternativ soll (falls es sich nicht um eine ID-nummer handelt) in der Spalte auch direkt der Name des Kontakts angegeben werden können. Letzter Fall dient für einmalige Kunden, für die sich die Anlage eines eigenen Kundenkontos nicht lohnt, sondern einfach nur der Name gespeichert wird.

    Wie kann ich das in ein Select-Statement packen, dass er entweder nach dem Schlüssel sucht, um die Spalte "Name" aus der Zweitdatenbank zurückzugeben, oder alternativ einfach den Spalteninhalt selbst (Name) zurückgibt.

    Gruß

  • #2
    Warum eigentlich zwei Datenbanken?

    Kommentar


    • #3
      Mit LEFT JOIN und CASE WHEN solltest du das abbilden können.
      Besser wäre aber, zwei verschiedene Felder zu nutzen für Fremdschlüssel bzw. Kontakt als String.
      Vor den Tabellennamen immer den Datenbanknamen setzen.
      sorry, shift-taste kaputt

      Kommentar


      • #4
        Hi,
        zwei Tabellen, weil ich für wiederkehrende Kontakte noch weitere Angaben speichere.

        Mit folgendem Statement funktioniert es. Kann ich daran noch etwas optimieren?

        Code:
        select
        Task.Title,
        (case
        when Task.Contact regexp "^[0-9]+$" then User.Title
        else Task.Contact
        end)
        from Task left join User on (User.Id=Task.Contact) where Task.Id=1 and
        (case
        when Task.Contact regexp "^[0-9]+$" then User.Id=Task.Contact
        else 1
        end);
        Table "Task" ist die oben als Haupttabelle bezeichnete, "User" die Nebentabelle mit der Spalte "Title" für den Namen. Die Spalte "Contact" der Haupttabelle ist die Verknüpfung, welche ggf den Schlüssel enthält.

        ​​​​​​​Gruß

        Kommentar


        • #5
          Ps. Danke für den Tipp mit Left join und Case When

          Kommentar


          • #6
            Wie kann ich denn im nächsten Schritt nun die Spalte "Contact" als Array gemischt aus ID-nummern oder direkten Strings aufbauen? Ziel ist, dass ich in der Spalte beispielsweise den Wert "3,Max Muster,5" setzen, um dann die Namen hinter den IDs 3 und 5, sowie den direkten Namensstring "Max Muster" zurückbekomme.

            Mit folgendem Statement kann ich die Namen aus der Zweittabelle laden per ID-Schlüssel, allerdings wie kann ich zusätzlich die Fieldelemente zurückgeben, die reine Strings sind?

            Code:
            select Task.Title, User.Title
            from Task join User
            where Task.Id=1 and 
            find_in_set( User.Id ,Task.Contact);

            Kommentar


            • #7
              Ich würde sagen, die Werkzeuge kennst Du schon und hast Dich dafür bedankt. Left Join liefert die nötige Lockerung, Case die Unterscheidung.

              Insgesamt finde ich es allerdings ziemlich gruselig, was Du da machst. Solche Statements baut man vielleicht, wenn es um Reparatur, Migration, Import geht, aber für den Normalbetrieb?
              Wieso modelierst Du das nicht explizit? Und wieso machst Du überhaupt dieses Theater? Um ein paar Byte zu sparen?
              Was auch immer Deine Anwendung macht, schon auf Ebene der Kunden/Kontakte, machst Du ziemliche Verrenkungen. Wie soll es bei tieferen Ebenen werden? Mir scheint es etwas übereifrig.
              Du sprichst davon, dass es sich "nicht lohnt". Welche Währung wäre das? Jedenfalls nicht Arbeitsstunden.

              Auch wenn man mit SQL viele "verrückte" Sachen machen kann, man will es nicht. Jede Varianzerhöhung kostet Performance, jeder zusätzliche Join.
              "Streamlined" ist so ein tolles neues Wort, das eigentlich ganz gut passt. Das will man erreichen.

              Ein Beispiel:
              Die Kandidaten, die sich momentan "nicht lohnen" und nur in direkter BeNamung auftauchen, brauchen vielleicht morgen oder übermorgen ein Merkmal, das Zahlung, Stückelung oder was weiß ich an Sonderlocken darstellt. Wo speicherst Du das? Böse Ahnung: noch ein Komma, noch ein Wert hinter dem Namen, der statt ID in dem Feld steht?

              Noch eins:
              Ein join, der in einer Standardmenge bereits eine Funktion benötigt benötigt um Zuordnungen zu finden, das ist kein guter Ansatz.

              Kann sein, dass es alles wurscht ist, weil Du nie mehr als 50000 Kunden in Deinem System hast und jede Geschirrspülmaschine diese Datenmengen bewältigt. Vielleicht probierst Du auch nur ein paar Sachen aus.
              Aber vielleicht willst Du auch was lernen. Also nicht krum nehmen die Kritik, einfach mal sacken lassen oder auch mal ein Tutorial durchgehen.

              Kommentar

              Lädt...
              X