Drei Reihen in einer ausgeben?

[Rayse]

Ich würde gerne mit einer Select Anweisung von allen drei Reihen mit "projectid = 1" die "issuetypeid" mit dem zugehörigen "issuecount" und "issuecountactive" ausgeben. Idealerweise sollte dies in einer Zeile ausgegeben werden. Ist das irgendwie Möglich oder brauche ich dafür mehrere SELECTs? Gruß Rayse

 

[NetAktiv]

Wozu willst das in einer Zeile ausgeben, wenn die dann eh alle Felder der drei Zeilen hat (nur die projid halt nur 1x). Ansonsten schau dir mal SQL JOIN an (über die Projektid und issuetype) oder falls du was auswerten willst Aggregatfuntionen wie SUM, MAX, ...

 

[Rayse]

Nee ich wollte nichts addieren. Es geht darum das ich von "bug", "feature" und "task" die counter brauche. Ich dachte das man das vllt in einer Zeile ausgeben kann, scheint aber nicht zu gehen. Das ganze benötige ich in einer bestehenden Applikation, wo bereits ein Query existiert. Allerdings besteht die Ausgabe in diesem Query nur aus einer Zeile, was sich durch das zusätzliche Join mit meiner Tabelle dann auf drei Zeilen ausdehnen würde und dann funktioniert der weitere Quellcode nicht. Ich hatte gedacht das man da vllt mit der "AS" Clause was machen kann, aber hab ich mich wohl geirrt. Komme ich wohl nicht drum herum ein weiteres Query einzuführen, gerade das wollte ich nämlich verhindern. Dank Dir für Deine Antwort.

 

[NetAktiv]

doch das geht mit dem join über id genau wie ich es dir gesagt habe. die genaue syntax kann ich auch nicht aus dem ärmel schütteln, aber in etwas so
select id, T1.count as bug_count, T2.count as feature_count, T3.count as task_count
from table as T1
inner join table as T2 on T1.id = T2.id
inner join table as T3 on T1.id = T3.id

 

[Rayse]

Okay danke, hab's hin bekommen auch wenn da wahrscheinlich noch reichlich Optimierungspotenzial besteht.

SELECT T1.issuecount AS bugcount, T2.issuecount AS featurecount, T3.issuecount AS taskcount  FROM `pt_projecttype` as T1  INNER JOIN pt_projecttype AS T2 ON (T1.projectid = T2.projectid AND T2.issuetypeid = 'feature')  INNER JOIN pt_projecttype AS T3 ON       (T1.projectid = T3.projectid AND T3.issuetypeid = 'task')  WHERE T1.projectid = 1 LIMIT 1

PS.: Beschissen gelöst hier mit dem WYSIWYG Editor. Da funktioniert gar nichts!

 

[NetAktiv]

Okay danke, hab's hin bekommen auch wenn da wahrscheinlich noch reichlich Optimierungspotenzial besteht.

Das ist ja zunächst mal die Hauptsache und wenn du immer nur wenige Datensätze durch ein entsprechendes WHERE holst würde ich mir auch keine Gedanken machen.

Beschissen gelöst hier mit dem WYSIWYG Editor. Da funktioniert gar nichts!

Der hat eigentlich nur Probleme mit CR/LF beim Cut&Paste, soweit mir das aufgefallen ist.

 

[NetAktiv]

mir ist noch was eingefallen, wenn du Bedenken wegen der Performance hast. Zum einen könntest einen Index auf Id und Type legen und zum anderen könntest die Abfrage als View in der DB ablegen. Wenn es dann Probleme gibt dann kannst dir immer noch etwas überlegen. Wenn die Counter beispielsweise nicht zeitnah gebraucht werden, dann könnte man im Batch (täglich, stündlich, ...) eine neue Tabelle füllen, die die gewünschte Struktur hat und in der die Abfrage durchführen.

 

[Rayse]

Stimmt, eine zusätzliche Tabelle die die aktuellen Counter beinhaltet wäre natürlich auch eine Möglichkeit. Den Index verändern kann ich nicht, da wie gesagt auf eine bestehende Applikation zugegriffen wird. Bisher läuft es auch so ganz gut, dennoch werde ich die Idee mit der weiteren Tabelle mal ausprobieren. Danke noch mal an dieser Stelle.

 

[NetAktiv]

Ein Index ändert ja eigentlich nichts für bestehende Applikationen, es würde nur spezielle Suchen beschleunigen und ein wenig Platz für den Index verbrauchen. Eventuell ist ja auch schon in Index auf den Feldern.

 

[mermshaus]

Ich wäre vorsichtig mit übertriebenen Optimierungen winziger Anwendungsteile. Das steht häufig in keinem Verhältnis.

 

[ka9de]

Zumal SQL (ich denke da unterscheidet sich mysql nicht) Querys auch selbst noch optimiert.

 

[Rayse]

Das war mir neu, danke ka9de (Danke Button funktioniert ebenfalls nicht...).

 

[mermshaus]

Wobei SQL lediglich die Sprache zur Formulierung von Datenbankabfragen ist. Die Optimierung übernimmt das DBMS (Datenbankmanagementsystem), also etwa MySQL.

In diesem Fall hier ist die gezeigte Tabelle übrigens meines Erachtens schon eine Art Cache, in dem „Primärdaten“ für einen bestimmten Ausgabekontext optimiert abgelegt werden. Spalten wie „issuecount“ symbolisieren ja eigentlich ein COUNT(*).

 

[NetAktiv]

Oder eine Application erhöht die Count-Werte und damit sind sind es normale Nutzdaten. Ich würde mir auch keine großen Gedanken machen, so lange auf der Join-Id ein Index liegt und es pro Id nur wenige Typen gibt, also wenn die zum Join verwendeten Felder vernünftig sind.

Davon abgesehen optimiert ein DBMS eventuell eine Abfrage indem es beispielsweise bei komplexen Suchen die Reihenfolge der temporären Zwischenergebnisse optimal bestimmen kann. Aber wenn man einen Query auf einem Feld macht, das keinen Index hat, dann kann das leicht zu einem Full Table Scan führen und bei Hundertausenden von Datensätzen können dann auch bei namhaften Datenbanken etliche Suchsekunden ins Land ziehen. Die Datenbank kann nichts optimieren, außer die Tabelle ins Memory zu ziehen und beim nächsten Query im Memory zu suchen. Wenn so etwas häufig vorkommt, dann könnte es eine Datenbank anhand erfasster Statistiken erkennen (ich meine Oracle macht sowas) und dann einen (internen) Index anlegen.

Aber erst mal testen und erst dann was ändern, wenn die Ergebnisse nicht ausreichend sind.

 

[mermshaus]

Oder eine Application erhöht die Count-Werte und damit sind sind es normale Nutzdaten.

Ja, wäre denkbar, glaube ich aber nicht. Ich vermute stark, es existiert mindestens eine weitere Tabelle, die für alle Bugs/Features/Issues einen expliziten Eintrag enthält.

Na ja, wie auch immer.

Aber erst mal testen und erst dann was ändern, wenn die Ergebnisse nicht ausreichend sind.

Genau, das ist der beste Tipp. Gerade dann, wenn auf einem „Fremdschema“ gearbeitet wird, das man nicht unbedingt verändern möchte.

Ansonsten gibt es schon ein paar „Faustregeln“ wie der von NetAktiv im Grunde bereits angesprochene Tipp: „Im WHERE-Teil immer mindestens eine Spalte haben, auf der ein Index liegt.“

Wenn ich aber mal von den Bezeichnern in der gezeigten Tabelle ausgehe: Die Tabelle hat sicher nicht so ganz viele Einträge.

Egal, Schluss mit den Spekulationen. Was ich eigentlich anmerken wollte:

Wenn ich eine Kleinigkeit optimieren kann, dazu aber meinen Code verkompliziere, weil ich 100 weitere Zeilen schreiben und eine Tabelle anlegen muss oder sowas, würde ich mir das sehr gut überlegen. Ja, das ist jetzt pauschal. :)