Datum Feld nach aktuellem Jahr und Monat selektieren

[Krosty]

Hallo Forum,

ich habe eine Statistik Tabelle und möchte gerne dort alle Werte des Aktuellen Monats selektieren und mir dann Exportieren.
Ich hänge am Selektieren schon fest, der Export ist klar.
Da ich das Automatisch per Nacht machen möchte und nicht jeden Monat / Jahr das Skript anpassen möchte, würde ich gerne das aktuelle Datum des Systems nehmen, ob nu getdate oder Sysdate ist egal, und von dort die Infos weiternutzen.


Mein Feld auf das Ich selektieren will ist ein Feld Typ Datum Inhalt ist 2022-05-31 für 31.5.2022
Meine Vorstellung wäre
Select * from Tabelle where Datum Like 'YYYY-MM-%'

Ich fehlt aber das wissen wie ich aus getdate Jahr und monat Extrahiere und das dann
vermutlich so

select getdate(), 
datepart(yy, getdate() ) year,
datepart(month, getdate() ) month, 
datepart(day, getdate() ) day,

aus In der SQL Query mit Datum rechnen
und wie ich das dann in Where verwende.

Danke vorab fürs Licht ins Dunkel bringen.

 

[ukulele]

Dein DATETIME-Format ist schon die richtige Ausgangsbasis, du suchst

SELECT * FROM tabelle WHERE convert(DATE,spalte) = convert(DATE,getdate());

Es gibt natürlich viele Wege auf mit BETWEEN oder einzelnen Abgleichen auf Jahr, Monat, Tag oder so, aber LIKE würde bedeuten erst in eine Zeichenkette zu konvertieren, das ist ziemlicher Mist.

 

[Krosty]

Like = Mist in dem Fall, hab ich gelernt kann ich verstehen.

Das war aber hilfreich, convert ist mir neu,
ich habe mir jetzt den SQL so zusammen gebaut / gegoogelt.

Select
    *
From
   tabelle
    WHERE convert(DATE,spalte) between DATEADD(mm, DATEDIFF(mm, 0, GETDATE()), 0) and DATEADD (dd, -1, DATEADD(mm, DATEDIFF(mm, 0, GETDATE()) + 1, 0))

Jetzt fehlt mir noch, wenn es der 1. Tag des Monats ist, dann nimm den Vormonat
geht das.
Oder sollte ich das Skript am besten immer um 23:50 laufen lassen.
Hintergrund ist, ich weiß aktuell nicht wann die Statistik aufgebaut wird.

 

[ukulele]

Achso du wolltest nicht den Tag sondern den Monat, da hab ich mich vertan. Das mit dem Vormonat am ersten des Monats wird ein bisschen verwirrend aber geht natürlich:

SELECT *
FROM tabelle
WHERE datepart(day,getdate()) > 1
AND datepart(year,getdate()) = datepart(year,spalte)
AND datepart(month,getdate()) = datepart(month,spalte)
OR datepart(day,getdate()) = 1
AND datepart(year,dateadd(day,-1,getdate())) = datepart(year,spalte)
AND datepart(month,dateadd(day,-1,getdate())) = datepart(month,spalte);

 

[dabadepdu]

Ich würde immer versuchen, Where Kriterien so zu formulieren, dass die Originalspalten nicht „verformt“ werden.

Also statt:
„where convert(<meineOriginaleDatumsSpalte>) = ..“
eher:
„where <meineOriginaleDatumsSpalte> = ..Konvertierung und Datumsarithmetik auf der anderen Seite der Gleichung.. bzw. so, dass Originalspaltenwerte erhalten bleiben, egal auf welcher Seite“

Das mal als Grundprinzip, damit vorhandene Indizierung auch genutzt werden kann. Bei kleinen DB oder Abfragen mit wenigen DS ist es wurscht, aber was nicht ist, kann ja noch werden.



Hier sind ein paar Beispiele:

SQL Server 2019

| (No column name) | | :----------------| | Microsoft SQL Server 2019 (RTM-CU6) (KB4563110) - 15.0.4053.23 (X64) <br> Jul 25 2020 11:26:55 <br> Copyright (C) 2019 Microsoft Corporation<br> Express Edition (64-bit) on Windows Server 2019 Standard 10.0 \<X64> (Build 17763: ) (Hypervisor)<br> |

dbfiddle.uk

 

[Tommi]

Hallo Krosty,

je nachdem, welche Version des SQL-Servers du verwendest kann die Where-Klausel auch kürzer geschrieben werden. Mal abgesehen davon, dass die oben vorgeschlagene Logik natürlich funktioniert, habe ich immer versucht Umwandlungen möglichst kurz zu halten, damit es besser lesbar ist.

Mit der Funktion EOMONTH, die ein datetime ebenfalls direkt in ein Datums-Format umwandelt, kannst du immer den letzten eines Monats ermitteln. Egal, welcher Tag in einem Monat grade anliegt, die Funktion gibt immer das Datum des letzten Tags im Monat zurück.
Dadurch kann man die Where-Bedingung dann auch wie folgt formulieren:

SELECT *
FROM table

WHERE EOMONTH(column) = EOMONTH(DATEADD(day, -1, GETDATE()))

Für mich wäre das einfacher lesbar - aber das ist natürlich subjektiv.

Viele Grüße,
Tommi

 

[ukulele]

Ich würde immer versuchen, Where Kriterien so zu formulieren, dass die Originalspalten nicht „verformt“ werden.

Löblich, in diesem Fall sehr unleserlich. Ist es wirklich so das bei datepart() auf die Spalte schon kein Index genutzt wird?

 

[dabadepdu]

Löblich, in diesem Fall sehr unleserlich. Ist es wirklich so das bei datepart() auf die Spalte schon kein Index genutzt wird?

Was ist unleserlich, meine Worte, mein SQL?
Ich habe geschrieben, dass ich versuchen würde dieses Problem zu vermeiden, grundsätzlich. Ob es in diesem Fall bei MSSQL eintritt, weiß ich nicht. Ich benutze es nicht, außer mein AG würde mich "zwingen".
Vom Prinzip her kann die Funktion datepart ähnlich wie like von links nach rechts arbeiten und damit einen fixen Anfang des Spaltenwerts noch über ein Indexrangescan holen. Dann geht es mit Monat, Tag, .. weiter, vielleicht ist MSSQL so toll bzw. gibt es so geniale Indizes dort.
Aber wenn ich den Index frage, gib mir bitte von Deinen Verweisen nur die Werte, die in der Mitte oder hinten irgendwo auf August zeigen, dann würde mich interessieren, wie das geht.

Wie gesagt, sowieso wurscht bei ein paar Tausend DS. Wer es wissen will und MSSQL nutzt, kann testen, ob es bei vielen DS einen Unterschied macht bzw. den Ausführungsplan befragen.
Und falls es um die Leserlichkeit des SQL geht:
Ein SQL Fragement, das ausdrückt:

where <meineDateTimeSpalte> between <ausgerechneterBereich>
oder
where <meineDateTimeSpalte> < <ausgerechneterDateTimeGrenzwert>
[code]
finde ich jetzt nicht so dramatisch lesbar. Die Berechnung dürfte grob etwas Gleichungsarithmetik sein, alles was den reinen Datetime Wert vermurkst, muss halt auf die andere Seite. Dem Kunden dürfte die Lesbarkeit ziemlich sch.. egal sein. Wenn er nichts lesen kann, weil er die Antwort erst abwarten muss, dürfte es schon mehr interessieren.