ib: SQL Abfrage von Zeilen auf Spalten

Hallo,

ich habe eine SQL Abfrage, die Werte von einem Kopierer ausliest. Pro Tonerfarbe gibt es eine Zeile mit einem Wert darin. Also im Prinzip 4 (könnten aber auch mehr sein, weil manche noch weitere Werte auslesen) Zeilen pro Maschine. Wie kann ich nun anstatt 4 (oder mehr Zeilen) die Werte in Spalten angezeigt bekommen?

Vielen Dank

Wie kann ich

  1. Tach!

    Wie kann ich nun anstatt 4 (oder mehr Zeilen) die Werte in Spalten angezeigt bekommen?

    Du solltest immer dazusagen, für welches DBMS du die Lösung suchst. Manche Dinge lassen sich mit den Mitteln von Standard-SQL nicht unbedingt lösen, sondern benötigen individuelle Wege des jeweiligen DBMS. (Und aussagekräftige Tags wählen. Die vom Forum vorgeschlagenen sind kein Muss, besonders dann nicht, wenn sie mit der Frage kaum etwas zu tun haben.)

    MySQL hätte da GROUP_CONCAT() in Verbindung mit einer Gruppierung. Das ergibt dann aber nur kommaseparierte Werte in einer Spalte. Für getrennte Spalten fallen mir da grad nur Subquerys ein. Je eine pro Spalte.

    dedlfix.

    1. tut mir lid, ist mssql

      habe mit privot probiert, aber da komme ich gar nicht klar.

      1. Hallo,

        habe mit privot probiert, aber da komme ich gar nicht klar.

        kein Wunder, die Technik heißt ja auch Pivot...

        Gruß
        Kalk

  2. Das Problem ist, dass Du nicht weißt wieviele Spalten Du haben willst. SQL Queries können beliebig viele Zeilen haben, aber bei Spalten ist sie Sache anders.

    Wenn Du Dich auf eine bestimmte Farbpalette festlegen kannst und genau weißt, wie die Farben identifizierbar sind, kannst Du Dir mit Subselects helfen.

    Mal angenommen, der Kopierer liefert Dir dies:

    SELECT Farbe, Menge FROM kopierer
    
    Farbe	  Menge  
    Magenta   50  
    Cyan      90   
    Yellow    10  
    Black     94  
    Paper     1175
    

    Dann müsste dies hier funktionieren:

    SELECT '3. Stock links' as Name,
           (SELECT Menge FROM kopierer WHERE Farbe = 'Magenta') AS Magenta,
           (SELECT Menge FROM kopierer WHERE Farbe = 'Cyan'   ) AS Cyan,
           (SELECT Menge FROM kopierer WHERE Farbe = 'Yellow' ) AS Yellow,
           (SELECT Menge FROM kopierer WHERE Farbe = 'Black'  ) AS Black
    

    und du bekommst

    Name             Magenta   Cyan      Yellow    Black
    3. Stock links   50        90        10        94
    

    Ist nicht wirklich effizient, weil Du die Kiste für jede Farbe einzeln fragen musst, aber mit SQL geht meines Wissens nicht mehr.

    Update: Nach etwas googlen habe ich diesen Stackoverflow-Artikel gefunden, wo im Prinzip das Gleiche passiert, aber mit Bedingungsausdrücken im SELECT statt Subselects. Geht vermutlich auch.

    HTH
    Rolf

    1. Hallo Ingrid,

      ich habe gerade mal das PIVOT-Statement vom SQL Server durchgelesen. Auch da scheint man vorher wissen zu müssen, wie viele Spalten man haben will, und da MS von "diese Syntax ist einfacher" spricht, scheint es sich hier um Syntaxzucker für die CASE / SUM Akrobatik aus dem Stack-Overflow Artikel zu handeln.

      ib, wenn Du mir eine Muster-Tabelle gibst mit realen Spaltennamen und Werten, kann ich mal versuchen, dazu ein Pivot-Statement zu schnitzen.

      Gruß
      Rolf

    2. Update: Nach etwas googlen habe ich diesen Stackoverflow-Artikel gefunden, wo im Prinzip das Gleiche passiert, aber mit Bedingungsausdrücken im SELECT statt Subselects. Geht vermutlich auch.

      Was auch geht: Die Tabelle mit sich selbst joinen.

      CREATE TABLE `kopierer` (
        `farbe` varchar(32) NOT NULL DEFAULT '',
        `menge` int(11) NOT NULL DEFAULT '0'
      ) ENGINE=MyISAM DEFAULT CHARSET=utf8
      
      
      select
        mag.menge   as Magenta,
        cya.menge   as Cyan,
        yel.menge   as Yellow,
        bla.menge   as Black
        from kopierer mag
      join kopierer cya
      join kopierer yel
      join kopierer bla
      where mag.farbe = 'Magenta' 
        and cya.farbe = 'Cyan' 
        and yel.farbe = 'Yellow' 
        and bla.farbe = 'Black'
      
  3. Hallo,

    ich habe eine SQL Abfrage, die Werte von einem Kopierer ausliest. Pro Tonerfarbe gibt es eine Zeile mit einem Wert darin. Also im Prinzip 4 (könnten aber auch mehr sein, weil manche noch weitere Werte auslesen) Zeilen pro Maschine.

    Ich würde die Daten anders speichern, nämlich als Objekte. Wobei: Jeder Kopierer ist ein Objekt "Entity" und hat beliebig viele Attribute bzw, Farben mit jweils einer dazugehörigen Mengenangabe bzw. Wert. Hierzu reicht eine Tabelle mit 3 Spalten: Entity, Attribute, Value (ent,att,val).

    MfG

    1. Tach!

      ich habe eine SQL Abfrage, die Werte von einem Kopierer ausliest. Pro Tonerfarbe gibt es eine Zeile mit einem Wert darin. Also im Prinzip 4 (könnten aber auch mehr sein, weil manche noch weitere Werte auslesen) Zeilen pro Maschine.

      Kopierer -> Farbe -> Wert

      Ich würde die Daten anders speichern, nämlich als Objekte. Wobei: Jeder Kopierer ist ein Objekt "Entity" und hat beliebig viele Attribute bzw, Farben mit jweils einer dazugehörigen Mengenangabe bzw. Wert. Hierzu reicht eine Tabelle mit 3 Spalten: Entity, Attribute, Value (ent,att,val).

      Entity -> Attribute -> Value

      Was ist daran "anders", mal abgesehen von den Spaltennamen?

      dedlfix.

      1. Abgesehen davon klingt das, was der OP beschreibt, nach einem vom Hersteller vorgegebenen Servicesystem, dessen Werte anderswo und anderswie dargestellt werden sollen. Da hat man auf die vorgefundene Speicherung wenig Einfluss.

        Über pls Prinzip, SQL-Datenbanken auf Objektspeicher zu reduzieren, will ich jetzt lieber nicht reden. Die Meinungen dazu sind eh bekannt ;-)

        Rolf

        1. Über pls Prinzip, SQL-Datenbanken auf Objektspeicher zu reduzieren, will ich jetzt lieber nicht reden. Die Meinungen dazu sind eh bekannt ;-)

          Was weißt Du denn über meine Prinzipien? Es ist nicht besonders klug von Dir, derartige Anspielungen zu machen!

          1. Lag ich so falsch? Dann bitte ich um Entschuldigung.

            Ich weiß nur das, was ich in anderen Beiträgen von dir gelesen habe und da hast du eifrig und gegen viele Widerstände für EAV als optimales Datenbankschema gestritten.

            Rolf