[SQL] Datensätze aneinander hängen (sonstige Sprachen, auch PHP)

[thread]20129[/thread]

[SQL] Datensätze aneinander hängen

Tags: SQL Ähnliche Threads

Leser: 14

Articles: hide open all | hide show old branches

+8 replies
MarkusH

2016-07-30 11:50
User since
2012-04-08
161 Artikel
BenutzerIn
Hallo zusammen,

ich habe drei Tabellen, aus denen ich Daten zusammenführen will.
Die folgende SQL-Anweisung liefert ein mögliches Ergebnis.
Code: (dl )

1 2 3

SELECT * FROM Shooters, Clubs, Shots WHERE Shooters.fidClubs = Clubs.idClubs AND Shots.fidShooters = Shooters.idShooters
Es gibt nur einen kleinen Schönheitsfehler.
Wenn in der Tabelle Shots z.B. 10 Einträge gefunden werden, dann werden auch 10 Zeilen in folgender Form ausgegeben:
Shooter.Name, Shooter.Club, Shooter.Result1
Shooter.Name, Shooter.Club, Shooter.Result2
Shooter.Name, Shooter.Club, Shooter.Result3
usw.

Ist es mit einer Änderung der SQL-Anweisung machbar, dass die Ergebnisse in folgender Form ausgegeben werden?
Shooter.Name, Shooter.Club, Shooter.Result1, Shooter.Result2, Shooter.Result3, usw.
$q =~ /(bb|[^b]{2})/
- +3 replies
- Raubtier
  
  2016-07-30 13:06
  User since
  2012-05-04
  1054 Artikel
  BenutzerIn
  Hm... Spontan fällt mit dazu nur GROUP_CONCAT ein, allerdings bekommst du die Ergebnisse das als einen gejointen String, d.h. es kommt raus:
  
  Code: (dl )
  
  Shooter.Name, Shooter.Club, "Shooter.Result1, Shooter.Result2, Shooter.Result3"
  
  Du hast also nicht variabel viele Spalten. Bin kein SQL-Experte, aber mir wäre nicht bekannt, dass man variabel viele Spalten haben kann.
  - +2 replies
  - MarkusH
    
    2016-07-31 10:38
    
    User since
    2012-04-08
    161 Artikel
    BenutzerIn
    
    Hallo,
    das wäre nicht weiter schlimm, da ich die Datensätze in diesem Feld sowieso komplett zerlegen muss.
    
    Allerdings funktioniert GROUP_CONCAT nicht bei Access Datenbanken, wie mir gerade Onkel Google mitteilt.
    Einzelne Datensätze wären auch nicht weiter schlimm. Möchte mir aber gerne die Überprüfung sparen, dass Shooter.Name schon existiert.
    $q =~ /(bb|[^b]{2})/
    - Linuxer
      
      2016-08-01 11:18
      
      User since
      2006-01-27
      3870 Artikel
      HausmeisterIn
      
      Vielleicht mit einer Variante dessen, was hier vorgeschlagen wurde?
      meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
      Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- Gast janus
  
  2016-07-31 10:51
  
  Ja, statt * benenne die Feldnamen full qualified und verwende as (alias). Statt der Union würde ich jedoch einen join aufsetzen, das gibt mehr Übersicht und Handlungsfähigkeit. Formatierungen würde ich jedoch erst auf der Ausgabe-Ebene per Template vornehmen und nicht in die Abfrage einbauen.
  Last edited: 2016-07-31 11:01:25 +0200 (CEST)
- +3 replies
- Muffi
  
  2016-08-01 09:06
  
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  
  Die simpelste Lösung ist wohl für jede Ergebniszeile einen eigenen Select für die Results zu machen.
  1 + 1 = 10
  - +2 replies
  - Raubtier
    
    2016-08-01 12:14
    User since
    2012-05-04
    1054 Artikel
    BenutzerIn
    
    Aus leidvoller Erfahrung würde ich immer von zu vielen kleinen SELECTs abraten, das ist nämlich meist deutlich langsamer als ein größeres SELECT.
    
    Daher ist es wahrscheinlich am besten, das Array von Shooter.Result in Perl zu basteln.
    
    Also pseudocodemäßig vielleicht so:
    
    Code (perl): (dl )
    
    1 2 3 4
    
    my %nameClub2Result; while (my $row = $sth->fetchrow_hashref) { push @{$nameClub2Result{$row->{"Shooter.Name"}}{$row->{"Shooter.Club"}}}, $row->{"Shooter.Result"}; }
    - Muffi
      
      2016-08-01 13:23
      
      User since
      2012-07-18
      1465 Artikel
      BenutzerIn
      
      Und ich würd immer davon abraten zu pauschalisieren ;)
      Nö, Scherz beiseite:
      Einzelselects werden meist langsamer sein als ein kompletter join.
      
      Aber auch das MUSS nicht so sein. Einzelselects lassen sich z.B. von der DB viel einfacher cachen als komplexe joins.
      Einfache Einzelselects gehen auch viel schneller durch den Queryoptimizer.
      Es kommt also immer drauf an.
      Auch darauf, wie man "langsam" definiert. Wenn man damit Echtzeit meint wohl eher ja. Wenn man damit Serverbelastung meint siehts auch schon wieder anders aus. Das Meiste an Langsamkeit ist einfach Latenz. Die Belastung ist garnicht so schlimm. Und wenn, dann skalieren kleine Einzelselects viel besser. Da kann ich ganz einfach eine Table auf nen anderen Server auslagern. Mit nem join wird das doof.
      
      Die beste Methode: ausprobieren. Aus dem Bauch raus würd ich sagen, dass alles bis so um die tausend Queries kein Problem darstellen sollte.
      Das rutscht selbst mit Perl und DB im LAN unter seiner Sekunde durch. (edit: Erfahrungswerte allerdings mit mysql)
      Last edited: 2016-08-01 13:29:24 +0200 (CEST)
      1 + 1 = 10

View all threads created 2016-07-30 11:50.