monatliche fortlaufende Auswertung in SQL

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von MemoAnMichSelbst.

    monatliche fortlaufende Auswertung in SQL

    Hallo,

    Ich soll eine Auswertung erstellen, die erstellte ID's aus einem Monat nimmt und sie mit den Folgemonaten vergleicht.

    Meine DB sieht in etwa so aus:

    ID | Creation Date| State
    1 07.2014 NEW
    2 07.2014 NEW
    3 07.2014 NEW
    4 07.2014 NEW
    5 08.2014 NEW
    6 08.2014 Completed
    7 09.2014 Completed
    8 09.2014 NEW
    1 09.2014 Completed

    Ich soll nun heraus finden, welche IDs in einem bestimmten Monat erstellt worden sind, zB. 07/2014
    Das ist auch kein Problem, nur soll ich diese ID's mit den ID's der nächsten Monate vergleichen können.
    a) Wieviele IDs sind noch nicht completed in den Folgemonaten ausgehend von den erstellten IDs vom 07/2014.

    Die Auswertung sollte für das obige Bsp ca so ausehen:

    Date | Remaining
    07.2014 0
    08.2014 5
    09.2014 4

    Bitte um Hilfe,

    Lg

    masteink schrieb:


    ID
    		CREATION DATE
    		STATE
    1
    		07.2014
    		NEW
    2
    		07.2014
    		NEW
    3
    		07.2014
    		NEW
    4
    		07.2014
    		NEW
    5
    		07.2014
    		NEW
    6
    		08.2014
    		Completed
    7
    		09.2014
    		Completed
    8
    		09.2014
    		NEW
    1
    		09.2014
    		Completed


    Fangen deine ID's wirklich wieder bei 1 an?!
    Was ist dann Primary Key in deiner DB?

    Werden die ID's vorher bestimmt? Also sagt man z.b. in 09.2014 gibt es 5 Stück oder woher stammen die?!

    masteink schrieb:

    Ich soll nun heraus finden, welche IDs in einem bestimmten Monat erstellt worden sind, zB. 07/2014
    Das ist auch kein Problem, nur soll ich diese ID's mit den ID's der nächsten Monate vergleichen können.
    a) Wieviele IDs sind noch nicht completed in den Folgemonaten ausgehend von den erstellten IDs vom 07/2014.
    Solche Analysen lassen sich am einfachsten im typisierten Dataset machen, indem man Filter-Ausdrücke bildet und zuweist: DataExpressions: Filter und berechnete Spalten im Dataset

    Allerdings wird dein Ausbilder das nicht lieben, denn 1) er kennt es nicht, 2) es ist zu einfach, und 3) es ist ohne nennenswertes Sql.

    Ein weiteres Problem ist, du müsstest erstmal die typDataset-Technologie erlernen, und Databinding. Und dann, wie man ein typDataset aus einer Datenbank befüllt, oder gar erst generiert, und dann befüllt.
    guggemol typisierter Db-Zugriff mit Connectoren

    Wie gesagt: Diese Tipps sind nur nützlich, wenn du selbst lernen willst, effektiv und zumindest annähernd nach Stand der Technik Datenbank-Programmierung zu erlernen.
    Wenn dein Ausbilder das nicht kennt, ist halt schlecht.

    Also...
    Das ist ausm Kopf geschrieben!!!!
    Ich gehe mal davon aus, dass deine Tabelle "Test" heißt... Also müsstest das bei dir wohl anpassen...

    SQL-Abfrage

    1. SELECT Count(Test.ID) AS Offen, Test.CreationDate
    2. FROM Test
    3. WHERE Test.State= 'NEW'
    4. AND (SELECT State
    5. FROM Test AS Test_1
    6. WHERE Test_1.ID = Test.ID
    7. AND Test_1.State = 'Completed') Is Null
    8. GROUP BY Test.CreationDate;


    Mal davon ab, dass die Datenhaltung die ihr da zu betreiben scheint ein Graus ist...
    Ich hoffe hab mich nicht verdaddelt.
    Er soll im Grunde die Anzahl (Count) an IDs mit dem zugehörigen CreationDate suchen, welche den Status "NEW" haben und wo er keinen weiteren Eintrag mit einem Status "Completed" findet, bei der Suche nach der ID.

    EDIT:
    PS. Dein obiges Beispiel ergibt jetzt für mich keinen Sinn... Wieso sind für den 07.2014 keine mehr "Remaining" wo doch nur für eine der IDs ein Completed zu sehen ist. (die 1)

    nach Stand der Technik Datenbank-Programmierung zu erlernen.

    Das ist nu wieder etwas weit aus dem Fenster gelehnt... Es macht Sinn es zu kennen, ist aber nur ein kleiner Bereich der Datenbänkerei und zudem extrem Programmiersprachenabhängig. Die 4GL Sprachen, welche in meisten großen Systemen (ERP Systeme meine ich jetzt) genutzt werden arbeiten anders.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „MemoAnMichSelbst“ ()

    Ich sehe da immernoch das Problem mit dem Datum, weil es kein Datum ist... Zumindest wenn es wirklich so da steht wie im Eröffnungspost, wird es wohl eher nen VARCHAR sein... Dann würd das Rechnen wegfallen mit dem Vormonat... Oder sehr kompliziert werden, wenn es um den Jahreswechsel geht.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D

    @MemoAnMichSelbst
    Jap wenn das ein Varchar ist bin ich raus :P Dann sollte man sich überlegen die Datenbank neu zu designen...

    EDIT:
    Habe ein Beispiel für MS SQL gemacht:

    Tabelle erstellen:

    SQL-Abfrage

    1. CREATE TABLE [dbo].[tbTicket](
    2. [idTicket] [int] IDENTITY(1,1) NOT NULL,
    3. [CreationDate] [datetime] NOT NULL,
    4. [State] [varchar](64) NOT NULL,
    5. CONSTRAINT [PK_tbTicket] PRIMARY KEY CLUSTERED
    6. (
    7. [idTicket] ASC
    8. )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    9. ) ON [PRIMARY]


    Mit Inhalt befüllen

    SQL-Abfrage

    1. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('01.25.2015','New')
    2. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('11.04.2015','New')
    3. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('11.03.2015','Completed')
    4. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('10.10.2015','New')
    5. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('10.02.2015','New')
    6. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('01.01.2015','Completed')
    7. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('10.25.2015','Completed')
    8. INSERT INTO [dbo].[tbTicket] ([CreationDate],[State]) VALUES ('10.20.2015','Completed')


    Entsprechend Completed auslesen:

    SQL-Abfrage

    1. SELECT COUNT(idTicket) AS 'QuantityCompleted'
    2. FROM [dbo].[tbTicket]
    3. WHERE DATEPART(m, CreationDate) = DATEPART(m, DATEADD(m, -1, getdate()))
    4. AND [State] = 'Completed'


    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „Lingo“ ()

    Schön ist es nicht, definitiv. Damit kann man nicht rechnen ^^
    Man könnte noch mit SELECT CONVERT versuchen zu einem Ziel zu gelangen, aber wenn man das Problem schon eher beseitigen kann, wäre das natürlich besser.

    masteink schrieb:

    Meine DB sieht in etwa so aus


    Wenn du sie erstellt hast, solltest du den Datentyp von dem Feld mal zu 'datetime' ändern.
    Option Strict On!

    Bevor man hier noch groß auf Ideen kommt, wäre es gut wenn der TE mal Stellung bezieht, um welche Datenbank es sich handelt und damit welche SQL Statements überhaupt unterstützt werden...
    Wie die Tabelle wirklich aufgebaut ist... nicht so Pseudodaten, sondern gescheite Daten mit den jeweiligen Datentypen...
    Wie die Idizes sind... Und ob er ggf. die Datenhaltung sogar noch selber bestimmen kann. Es könnte ja sein, dass es bislweilen nur ein Konzept ist.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D

    Ein Foreign Key sollte mehrmals vorkommen. Nur dann macht er sinn.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D

Facebook
Telefonspende