Erstmal: Schönen Sonntag zusammen!
Das Spezielle an diesem Thread ist doch, dass das Problem ganz im Gegensatz zum gewählten Titel überhaupt nicht speziell ist!
Alle Lösungen von
@akretschmer funktionieren und sind mit minimalem Aufwand nachvollziehbar und auch übertragbar auf andere Systeme. Weil SQL eben doch ein Standard ist.
Code:
select * from hexe63 where current_date > begin and current_date < ende;
Code:
select * from hexe63 where '2022-05-01'::date > begin and '2022-05-01'::date < ende;
Code:
select * from hexe63 where '2022-05-30'::date between begin and ende;
Ausnahme ist lediglich die Nutzung von Range Types, die sind eher selten bei anderen DB Anbietern.
Code:
select * from demo where von_bis @> current_date;
Für erfahrene Nutzer sicher nicht spannend: das Prinzip (die Syntax) dieses Statements funktioniert in wirklich jedem relationalen DB System.
Code:
select * from tabelle t where <datumsvariable_oder_datumsfunktion> between t.start_datum and t.end_datum;
Ebenso die Varianten mit Kleiner, Größer, Gleich (<,>,=).
Interessant ist doch, dass und warum Anfänger damit nicht zurecht kommen. Hier in diesem Fall muss man ja wohl leider feststellen, dass
- die Handhabung von Datumstypen und Datumsfunktionen doch bei jedem Anbieter recht unterschiedlich ist (oder sagen wir, den Standard unterschiedlich abdeckt) und damit eben weniger (ANSI) Standard ist.
- (Anfängern) selten klar ist, wann und warum explizite oder implizite Datumskonvertierung erfolgt und wo die Probleme dabei liegen (prinzipbedingt oder herstellerspezifisch)
- ebenso wenig klar ist, dass „fehlende“ (gleichnamige ANSI) Standard Funktionen einfach selbst zu schreiben sind (oder tw. sogar als Kompatibilitätspakete zu anderen Anbietern installierbar wären)
- die Handhabung von Datumstypen per Variablen / Parametern in unterschiedlichen DB aus Perspektive der Clientprogrammierung von allein verschwinden, wenn sie optimal per parametrierter Abfrage erfolgen
- MS SQL als einziges mir bekanntes System eine Sonderrolle einnimmt, weil es keinen Unterschied zwischen der Abfragesprache und der Programmiersprache macht (und was das impliziert)
Was in diesem Thread auch noch aufgetaucht ist (und immer wieder auftaucht),
die fehlerhafte Anwendung von verketteten Bedingungen mit AND oder OR plus der Namensanalogie hier (AND) im BETWEEN Konstrukt.
Gut, also ein Großteil von Problem resultiert eigentlich nur aus dem Datumstyp und herstellerspezifischer Handhabung von Datumstypen.
Das gleiche Problem mit einer Zahlenreihe statt einer Datumsreihe wäre also auf Anhieb 100% kompatibel.
Warum schreib ich das alles? Man kann natürlich beklagen, dass in einem Forum unpassende Hilfestellung gegeben wird, ja, MS SQL ist natürlich nicht Postgres. Aber es ist nicht so, dass es hier um entfernte Galaxien geht, um grundlegend unterschiedliche Programmiersprachen wie C und Scheme oder Pascal.
Darüber hinaus ist es natürlich etwas befremdlich, wenn beklagt wird, dass überhaupt Hilfestellung gegeben wird(, die angeblich unpassend ist). Und
ernsthaft: Muss man wirklich kritisieren, dass jemand die hervorragenden Features eines kostenlos verfügbaren Datenbanksystems herausstellt und so tun als würden MS Kenner (Consultants, Berater, Freelancer, ..), die alle mit MS Produkten schön Geld verdienen, andere/Konkurrenz Systeme empfehlen bzw. über den Tellerrand schauen? (Das geschieht wohl vorwiegend, um sich etwas abzuschauen)
Ich habe an der Stellen jedenfalls umgekehrt kein Mitleid mit MS, seinen Vertretern und seinen Produkten. Sie sind teuer genug und müssen sich halt einem Wettstreit stellen, den man nicht mal als fair bezeichnen kann.
Mir scheint es da eher lächerlich, in dem Zusammenhang das Wort „Fanboy“ zu benutzen. (aus dem Munde eines Users namens t-sql). Mir ist in diesem Forum nur ein User bekannt, der nicht nur namentlich keine Unklarheiten über sich und seine Motive lässt.
Aber zurück: Ich stelle mal die These in den Raum, dass vielleicht gerade die Unterschiede der Systeme gar nicht so schlecht sind, um Sachverhalte und Funktionsprinzipien besser zu begreifen oder zu erklären. Immer vorausgesetzt, jemand will sie überhaupt begreifen und nicht nur eine Copy/ Paste Lösung absaugen.
Das Tolle ist doch, dass alle diese Systeme online im Netz für Tests verfügbar und vergleichbar sind, inklusive Dokumentation! Es ist wirklich ein Nobrainer, in Sekunden im Browser einen Lösungs-Vorschlag in einer „fremden“ DB auszuprobieren und zu vergleichen.
Und wenn man möchte, kann man sich in etwas mehr Sekunden eine komplett kostenlose Opensource DB installieren und testen, üben, entwickeln bis der Arzt kommt, ohne Lizenzrisiko und ohne Anwaltsbüro im Anschlag.
Wir sind hier vermutlich alle nicht mehr im Kindergarten und jeder User kann jederzeit anhand der Beiträge selbst entscheiden, was er mit den erlangten Informationen anstellt und welche Schlüsse er daraus zieht.
In diesem Sinne wünsche ich allen weiterhin eine sachliche, hilfreiche und erhellende Diskussion! Sportlich bleiben!
