Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi SQL oder nicht SQL ... (https://www.delphipraxis.net/84029-sql-oder-nicht-sql.html)

mschaefer 10. Jan 2007 11:53

Datenbank: FB • Version: 1.5 • Zugriff über: ...

SQL oder nicht SQL ...
 
Moin, moin,

habe ein Datenbankabfrageproblem wo ich derzeit kapitulieren muß. Es existiert eine Liste mit Kennungen:

Nr Kennung Felder
--------------------
1 AAAAAA Feldnr 2
2 AAAAAA Feldnr 2
3 AAAAAA Feldnr 2
4 BBBBBB Feldnr 2
5 BBBBBB Feldnr 2
6 BBBBBB Feldnr 2
7 BBBBBB Feldnr 2
8 BBBBBB Feldnr 2
9 CCCCCC Feldnr 2

ich hätte gerne die Datensätze, bei denen sich die erste Spalte zur vorhergehenden ändert, also hier:
Nr Kennung Felder
--------------------
1 AAAAAA Feldnr 2
4 BBBBBB Feldnr 2
9 CCCCCC Feldnr 2

ist das irgendwie mit SQL zu lösen?

Grüße // Martin

s14 10. Jan 2007 11:57

Re: SQL oder nicht SQL ...
 
Hallo, das müsste doch mit "DISTINCT" möglich sein?

smudo 10. Jan 2007 11:58

Re: SQL oder nicht SQL ...
 
Das sollte mit Group und Max funktionieren.
Distinct geht nicht, da Nr sich ändert.

Edit: Habs mal aufgeschrieben
SQL-Code:
select Max(Nr), Kennung, Felder
from KENNUNGEN
group by Name, Felder

mschaefer 10. Jan 2007 12:13

Re: SQL oder nicht SQL ...
 
Ja DISTINCT filtert in allen Feldern identische Datensätze. Richtig ist, das dann nur eine Zeile bleibt. Leider sind das keine identischen Datensätze, sondern die weiteren Felder ändern sich eher beliebig.

Ok werde mal ein Group by mit Max ansetzen. Danke !

Grüße // Martin

s14 10. Jan 2007 12:13

Re: SQL oder nicht SQL ...
 
Stimmt, einen hab ich aber noch :-)

Damit das Ergebniss mit der Vorgabe übereinstimmt sollte:

SQL-Code:
select Min(Nr), Kennung, Felder
verwendet werden. :???:

mschaefer 10. Jan 2007 12:45

Re: SQL oder nicht SQL ...
 
Schade,

es ist leider kniffliger: Das Max und das Min wirken sich in der Gruppierung nicht aus.
Ich müßte nach Max(Kennung) Gruppieren können. Das läßt das Group aber nicht zu.....

Wenn ich nur nach der Kennung selektiere und das Distinct anwende dann habe ich die Datensäteze dich haben möchte, aber leider nicht die rechts folgenden Felder.
SQL-Code:

   SELECT DISTINCT
            Kennung
   FROM    MyTable
   GROUP BY Kennung
Grüße // Martin

s14 10. Jan 2007 12:54

Re: SQL oder nicht SQL ...
 
Ich habe die Tabelle mit Deinen Daten nachgebaut, _Test genannt und mit:

SQL-Code:
select Min(Nr) as Nr, Kennung, Felder
from _Test
group by Kennung, Felder
genau das Ergebnis, wie in Deinem ersten Post, erhalten.

Allerdings verwende ich einen MS SQL-Server, vielleicht liegt es daran?

Hansa 10. Jan 2007 12:55

Re: SQL oder nicht SQL ...
 
Geht das nicht mit DISTINCT ? :shock: Brauche das (bisher) zwar nicht, aber ich denke, das ist für so was da ? Falls es wirklich nicht geht, dann denke mal über den Einsatz einer SP mit Rückgabewerten nach (darin käme dann das max ins Spiel). Dann eben diese Rückgabewerte ausgeben.

mschaefer 10. Jan 2007 13:10

Re: SQL oder nicht SQL ...
 
Hallo

Wollte die Gruppierung auf die Kennung laufen lassen. Habe keine Datensatznr. in der Tabelle. War für mich oben im Beispiel eher als Zeilenzähler gedacht. Da liegt genau der Wurm. Das Max, Min funtkioniert auf einen numerischen Wert und meine Kennung war bis eben :mrgreen: nicht numerisch! Bei nicht numerischen Kennungen würde ich nur das Konvertieren in eine Nummer sehen. Dafür bräuchte man wieder eine Funktion.

Es geht daher tatsächlich mit dem Group By und ich brauche nicht Hansa´s (nett mal wieder was von Dir zu hören) Allround-Keule SP.


Danke Euch noch mal! Grüße // Martin

mschaefer 10. Jan 2007 14:47

Re: SQL oder nicht SQL ...
 
So jetzt hat die Aufgabenstellung gewechselt:

Jetzt brauche ich die ersten fünf Datensätze einer jeden Gruppe in der Datenmenge!
Das war es dann wohl mit SQL und Group By. Ohne SP soll es wohl heute nicht sein....


SQL-Code:

SELECT PER GROUP TOP 5 
              Kennung, Field_2, Field_3
    FROM     MyTable
    GROUP BY Kennung
    ORDER BY Kennung, Field_2 desc
.. das gibt es leider nicht...

Grüße // Martin

Hansa 10. Jan 2007 16:50

Re: SQL oder nicht SQL ...
 
Doch, das geht schon. :mrgreen:

mschaefer 10. Jan 2007 17:32

Re: SQL oder nicht SQL ...
 
Mit welcher Version arbeitest Du denn (FB 5+) :mrgreen: ???

Hansa 10. Jan 2007 17:43

Re: SQL oder nicht SQL ...
 
Zitat:

Zitat von mschaefer
Mit welcher Version arbeitest Du denn (FB 5+) :mrgreen: ???

ne, bin schon bei FB V8.0. :mrgreen:

Denkanstoß :

SQL-Code:
SET TERM ^ ;

CREATE PROCEDURE MWSTSATZSP8 (
    mwstsatz smallint,
    datum date)
returns (
    mwstsatz_out decimal(15,2))
as
BEGIN
  SELECT FIRST 1 MWSTWERT FROM MWST8 WHERE
    (MWSTSATZ=:MWSTSATZ) AND (ABDATUM <= :DATUM)
  ORDER BY ABDATUM DESC INTO :MWSTSATZ_OUT;
  IF (MWSTSATZ_OUT IS NULL) THEN MWSTSATZ_OUT = 0;
  SUSPEND;
END^

SET TERM ; ^

smudo 11. Jan 2007 08:56

Re: SQL oder nicht SQL ...
 
Ich liebe Stored Procs :thumb:

Edit:
Hey, FB V8.0 ist schon raus? Muss ich gleich mal testen. :zwinker:

mschaefer 12. Feb 2007 12:14

Re: SQL oder nicht SQL ...
 
Moin, moin,

die Stored-Proc hat dann auch tatsächlich mit V2 gelaufen, aber Hansa ist ja einige Zeitzonen voraus.

GROUP BY - Frage die 3.

Da es oben schon um Group by ging mach ich jetzt keinen neuen Thread auf. Habe eine Abfrage auf eine Datei wo Umsätze per Monat ausgelesen werden sollen. Also etwas vereinfacht folgendes:

TABELLE "Umsatz" hat die Felder "Monat", "Umsatz"

SQL-Code:
SELECT
     SUM  (Umsatz) AS Monatsumsatz
    ,COUNT (Umsatz) AS Umsatzanzahl
     FROM Tabelle Umsatz
     GROUP BY Monat
Funktionier auch soweit, dass die Umsätze nach Monaten aufsummiert werden.

...
Jan 0 0 // erscheint leider nicht
...
Mai 7200 23
Juni 9400 34
Juni 12000 40
...

Wenn jetzt aber einen Monat kein Umsatz war, dann erscheint dieser Monat nicht in der Gruppe mit einer Nullzeile, sondern wird einfach ausgelassen. Kann man dieses der Abfrage abgewöhnen.

Grüße // Martin

mkinzler 12. Feb 2007 15:05

Re: SQL oder nicht SQL ...
 
Nur wenn du den Monat per Outer-Join hinzufügst

Hansa 12. Feb 2007 18:49

Re: SQL oder nicht SQL ...
 
Ich glaube eher, er meint einen Monat ohne Umsatz. Ist denn in der Tabelle dann überhaupt ein Monat hinterlegt ? :shock: Glaubs eher nicht. :zwinker:

mkinzler 12. Feb 2007 18:52

Re: SQL oder nicht SQL ...
 
Ja deshalb ja dazujoinen

alex517 12. Feb 2007 19:16

Re: SQL oder nicht SQL ...
 
Hallo Martin,

Zitat:

Zitat von mschaefer
Wenn jetzt aber einen Monat kein Umsatz war, dann erscheint dieser Monat nicht in der Gruppe mit einer Nullzeile, sondern wird einfach ausgelassen. Kann man dieses der Abfrage abgewöhnen.

Wenn keine "Monate" da sind, können auch keine in der Ergebnismenge auftauchen.
Aber man kann sich ja welche "basteln".

SQL-Code:
CREATE PROCEDURE SP_JJMM (
    VON_JJ INTEGER,
    VON_MM INTEGER,
    BIS_JJ INTEGER,
    BIS_MM INTEGER)
RETURNS (
    JAHR INTEGER,
    MONAT INTEGER)
AS
begin
  JAHR = VON_JJ;
  MONAT = VON_MM;
  WHILE (JAHR * 100 + MONAT <= BIS_JJ * 100 + BIS_MM) DO
  BEGIN
    suspend;
    MONAT = MONAT +1;
    if (MONAT > 12) THEN
    BEGIN
      MONAT = 1;
      JAHR = JAHR +1;
    END

  END
end
Dann hat man im Ergebnis auch den Monat:
SQL-Code:
SELECT
  JJMM.JAHR,
  JJMM.MONAT,
  COALESCE(SUM (U.BETRAG), 0) AS Monatsumsatz,
  COUNT (U.ID) AS Umsatzanzahl
FROM
  SP_JJMM(2005, 10, 2007, 5) JJMM
  left outer join Umsatz U on (U.JAHR = JJMM.JAHR and U.MONAT = JJMM.MONAT)
GROUP BY
  JJMM.JAHR,
  JJMM.MONAT


alex

Hansa 12. Feb 2007 19:22

Re: SQL oder nicht SQL ...
 
Jetzt mal langsam. Hierum gehts :

Zitat:

Zitat von Hansa
Ist denn in der Tabelle dann überhaupt ein Monat hinterlegt ?

Ich gehe von Betriebsferien im Juli und Aug. aus. Wär doch gut. :mrgreen:

Sieht die Tabelle nun so aus :

Delphi-Quellcode:
1  11,22
2  45,99
3  546,00
4  444,50
5  55,00 
6  9,55
7  0
8  0
9  2343,66 
...
oder so :

Delphi-Quellcode:
1  11,22
2  45,99
3  546,00
4  444,50
5  55,00 
6  9,55
9  2343,66 
...
Wollte den zweiten Fall ansprechen und nicht den ersten. Sind schon mal Betriebsferien, dann wird wohl keiner einmal im Monat trotzdem hingehen alles hochfahren und irgendwie den Monaten 7 und 8 in der DB sagen : Umsatz war alles 0. :mrgreen:

In einem solchen Fall würde ein Join nichts nützen. Martin, sage mal welcher der beiden Fälle der reale ist. Passt gut zur Ursprungsfrage : ersteren würde ich mit SQL lösen, den zweiten nicht.

Ah, Alex. Muss ich in Ruhe mal angucken. Das hier bleibt trotzdem jetzt so stehen.

alex517 12. Feb 2007 19:24

Re: SQL oder nicht SQL ...
 
Zitat:

Zitat von Hansa
Ah, Alex. Muss ich in Ruhe mal angucken. Das hier bleibt trotzdem jetzt so stehen.

Sorry Hansa, war die falsche SP, deshalb editiert.

omata 12. Feb 2007 19:33

Re: SQL oder nicht SQL ...
 
Warum so komplizert?

Leg dir eine Tabelle mit den Monaten an...

Tabelle Monate...
SQL-Code:
CREATE TABLE Monate (
  monat INT NOT NULL ,
  Bezeichnung varchar (50) NOT NULL ,
  CONSTRAINT [PK_Monate] PRIMARY KEY (monat_id) ON PRIMARY
) ON PRIMARY
Inhalt...
Code:
Monat Bezeichnung
1     Januar
2     ...
3
4
5
6
7
8
9
10
11
12
Und hol dir deine Daten...
SQL-Code:
SELECT *
FROM (SELECT *
      FROM monate, (SELECT DISTINCT jahr
                    FROM umsatz
                    WHERE jahr BETWEEN 2005 AND 2006) x) x
LEFT JOIN umsatz u
  ON    x.jahr = u.jahr
     AND x.monat = u.monat
ORDER BY x.jahr, x.monat
Gruss
Thorsten

Hansa 12. Feb 2007 20:14

Re: SQL oder nicht SQL ...
 
Omata, was ist bei einer Monatstabelle denn gewonnen ? Siehe meine Betriebsferien. :mrgreen: Den Urlaub zu unterbrechen, um einen 0-Umsatz einzugeben, das hätte ich gespart. Stattdessen müsste ich doch 2-mal zurückfliegen, um eben nur einen überflüssigen 0-Umsatz-Monat anzulegen. :P Gut, man könnte natürlich jetzt schon Monate bis zur Rente anlegen. Am Speicherplatz sollte es kaum liegen. :mrgreen:

mkinzler 12. Feb 2007 20:16

Re: SQL oder nicht SQL ...
 
Hansa, du scheint das Problem nicht zu verstehen. Nur weil in einem Monat kein Umsatz generiert wird, existiert dieser Monat doch trotzdem!

omata 12. Feb 2007 20:26

Re: SQL oder nicht SQL ...
 
@Hansa: Ich kann deinen Einwand leider nicht nachvollziehen.

Man kann die Jahre einschränken, auf Monate könnte man das auch noch ohne weiters. Und was mit deinen komischen Betriebsferien ist weiss ich auch nicht. Mir ging es nur darum die Daten, die in der Datenbank stehen auszulesen und darzustellen.

Wie auch immer, ihr könnt meinen Beitrag ja überlesen...

Gruss
Thorsten

Hansa 12. Feb 2007 21:21

Re: SQL oder nicht SQL ...
 
Zitat:

Zitat von omata
...Wie auch immer, ihr könnt meinen Beitrag ja überlesen...

Warum denn ? Hier soll doch diskutiert werden, oder nicht mehr ? :shock: Du meinst also, eine Tabelle, in der lediglich 12 Monate stehen und sonst nichts ? Also nicht leere Monate mit rumschleppen, wo Umsatz=0 (Betriebsferien) und das Jahr für Jahr ? Hmm, geht das so ? :gruebel:

mkinzler 12. Feb 2007 21:23

Re: SQL oder nicht SQL ...
 
Wenn er aber eine Umsatzliste pro Monat haben will, will er eine pro Monat und nicht pro Monat der Werte besitzt. Das Jahr hat 12 Monate egal wieviel Monate ein Betrieb vielleicht Ferien hat oder nicht.

omata 12. Feb 2007 21:30

Re: SQL oder nicht SQL ...
 
Klar können wir diskutieren.

Ich dachte das mit den leeren Monaten war gerade gewollt. Damit eventuelle Lücken aufgefüllt werden. Man kann natürlich noch einbauen, das Monate die in der Zukunft liegen noch nicht ausgegeben werden. Ich weiss jetzt gerade nicht wie ich an das aktuelle Datum in FB komme.

Für MSSQL würde das so aussehen...
SQL-Code:
SELECT *
FROM (SELECT *
      FROM monate, (SELECT DISTINCT jahr
                    FROM umsatz
                    WHERE jahr BETWEEN 2005 AND 2006) x) x
LEFT JOIN umsatz u
  ON    x.jahr = u.jahr
     AND x.monat = u.monat
WHERE x.jahr < YEAR(GETDATE())
   OR (x.jahr = YEAR(GETDATE()) AND x.monat <= MONTH(GETDATE()))
ORDER BY x.jahr, x.monat
Gruss
Thorsten

mkinzler 12. Feb 2007 21:33

Re: SQL oder nicht SQL ...
 
Zitat:

Ich weiss jetzt gerade nicht wie ich an das aktuelle Datum in FB komme.
CURRENT_DATE

mschaefer 19. Feb 2007 06:13

Re: SQL oder nicht SQL ...
 
Zunächst mal vielen Dank für die interessante Diskussion. Hattte einige Tage Computersperre (anderea Aufgaben). Selbst habe ich tatsächlich keine Monatstabelle. Das ist aber änderbar und dann ist die Möglichkeit per Join eine gute Lösung. Die Stored-Proc Lösung hat mich schon beeindruckt. Da ich möglichst DB unabhängig arbeiten soll, wird es wohl eine reine Join-Lösungwerden.

Das Problem ist ja übrigens sehr allgemein. Überall wo Vorlagen ausgefüllt werden sollen müssen auch Nullzeilen mit ausgegeben werden.Projekte pro Monat, Umsatz pro Mitarbeiter, neue Artikel pro Filiale...
Eigentlich ist es ein sehr allgemeines Problem und ich bedanke mich für die Vorschläge

Viele Grüße // Martin


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:37 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz