Mysql Abfrage
0 
Matthias Apsel
0 
dedlfix
0 
TS
0 dedlfix
0 0 dedlfix
0 Matthias Apsel
0
0
Mysql Abfrage
Hallo
Ich habe eine kleines Problem mit einer SQL Abfrage. In meiner Datenbank stehen Datum und Uhrzeit getrennt von einander in jeweils eigenen Spalten. Datum ist als Date und Uhrzeit als Time in der DB deklariert. Nun werden in der DB Einträge für die Zukunft gemacht, die Einträge werden mit Datum und Uhrzeit gemacht. Nun möchte ich eine Abfrage machen die mir vom Zeitpunkt aus wo die DB Abfrage gemacht wird alle Einträge in der Zukunft anzeigt, bzw. alle Einträge die in der Vergangenheit liegen weg lässt. Mit dem Datum funktioniert das ganz gut, nur mit der Uhrzeit nicht. Kann mir da jemand helfen? Wenn ich bei der Zeit now() nehme, lässt er auch die Uhrzeit in der Zukunft weg. Ich hoffe das ist verständlich 😐
tb_datum tb_zeit
2018-07-26 06:29:00
2018-07-30 18:10:00
2018-07-30 07:30:00
2018-07-30 13:37:00
2018-07-31 06:30:00
2018-08-01 00:00:00
2018-08-07 15:10:00
2018-08-07 22:38:00
2018-03-12 22:57:00
2018-08-06 23:24:00
2018-11-12 23:06:00
2018-08-10 23:07:00
2018-08-07 14:47:00
2018-08-07 11:48:00
2018-08-07 16:57:00
2018-08-08 22:23:00
2018-08-08 22:22:00
2018-08-07 17:10:00
2018-06-05 18:16:00
2018-09-14 18:17:00
2018-09-09 18:20:00
2018-09-09 19:38:00
2018-09-09 19:41:00
Und hier die Query dazu:
SELECT * FROM Datenbank WHERE tb_datum >= DATE(NOW()) AND tb_zeit >= DATE(NOW())
-
Hallo sascha321,
Ändere die DB so, dass aus den beiden Spalten eine vom Typ timestamp wird.
Bis demnächst
Matthias--
Rosen sind rot.-
Tach!
Ändere die DB so, dass aus den beiden Spalten eine vom Typ timestamp wird.
Wenn dann DATETIME. DATETIME ist für allgemeine Datums- und Zeitangaben vorgesehen. TIMESTAMP ist für Zeitstempel da, weswegen es auch eine eingebaute Update-Magie hat.
Ansonsten ist das Problem ein logisches. Die Zukunft beginnt heute zur aktuellen Uhrzeit und umfasst für alle zukünftigen Tage alle Uhrzeiten. Also lautet die Bedingung dass das Datum größer als heute sein muss oder gleich heute und die Uhrzeit größer als die aktuelle Zeit.
dedlfix.
-
Hello,
Der Wertebereich von Timestamp endet 2038. Das ist nicht mehr lange hin. Laut Manual kann Datetime auch automatisch gesetzt werden?
Bei der Formulierung der Abfrage müssen sicherlich ein paar Klammern gesetzt werden. damit alle DS nit Zeiten von heute(), die kleiner als jetzt() sind, ausgeblendet bleiben. Für alle anderen Tage ist die Zeit ja unerheblich.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Tach!
Der Wertebereich von Timestamp endet 2038. Das ist nicht mehr lange hin. Laut Manual kann Datetime auch automatisch gesetzt werden?
Ok, hätte ich vielleicht doch mal die Changelogs der jüngeren Versionen lesen sollen. Das Ändern ging früher nur mit Timestamps.
Bei der Formulierung der Abfrage müssen sicherlich ein paar Klammern gesetzt werden. damit alle DS nit Zeiten von heute(), die kleiner als jetzt() sind, ausgeblendet bleiben. Für alle anderen Tage ist die Zeit ja unerheblich.
So wie ich das formuliert habe, braucht es keine Klammern. AND hat Vorrang vor OR und damit gilt die Prüfung auf zukünftige Tage als ein eigenständiger logischer Term sowie die Püfung auf heute und zukünftige Uhrzeit als ein ebenso eigener Term.
dedlfix.
-
-
dedlfix
Ja ich weiss das es ein logisches Problem ist, aber ich weiss nicht wie ich das in der Query verpacken soll das es nachher so rauskommt wie ich es möchte. Kannst Du mir da helfen?
-
Tach!
Ja ich weiss das es ein logisches Problem ist, aber ich weiss nicht wie ich das in der Query verpacken soll das es nachher so rauskommt wie ich es möchte. Kannst Du mir da helfen?
Mehr als das Formulieren der Bedingung in natürlicher Sprache möchte ich nicht helfen. Den Code daraus erstellen ist nicht mehr allzuschwer, und das Erfolgserlebnis ist auch größer als beim Kopieren von Fertig-Code. Zudem ist es bereits so ausführlich formuliert, dass du quasi nur die Wörter durch Code austauschen musst.
dedlfix.
-
Hallo dedlfix, @sascha321
Mehr als das Formulieren der Bedingung in natürlicher Sprache möchte ich nicht helfen.
alle zukünftigen Tage ODER
der heutige Tag UND eine zukünftige UhrzeitWobei ich empfehle, aus den beiden Spalten eine zu machen. Dann kannst du einfach nach einer zukünfigen Zeit (die dann aus Datum und Uhrzeit besteht), fragen.
Bis demnächst
Matthias--
Rosen sind rot.-
Hallo Zusammen
das funktioniert leider nicht
alle zukünftigen Tage ODER der heutige Tag UND eine zukünftige Uhrzeit
Jetzt nimmt er doch entweder "alle zukünftigen Tage von heute an" ODER "den heutigen Tag und zukünftige Uhrzeit" welches von beiden gibt er mir denn dann aus?
-
Hallo sascha321,
alle zukünftigen Tage ODER der heutige Tag UND eine zukünftige Uhrzeit
Jetzt nimmt er doch entweder "alle zukünftigen Tage von heute an" ODER "den heutigen Tag und zukünftige Uhrzeit"
welches von beiden gibt er mir denn dann aus?
Beides. Dieses oder ist inklusiv.
Laut Eröffnungsbeitrag möchtest du alle Beiträge haben, die „vom Zeitpunkt aus wo die DB Abfrage gemacht wird alle Einträge in der Zukunft“ liegen.
Entweder ist es Zukunft, weil es sich um einen zukünftigen Tag handelt oder es ist Zukunft, weil es heute, zu einer zukünftigen Zeit ist.
Es ist rot oder klein ist eine wahre Aussage für etwas kleines, etwas rotes, etwas kleines rotes, sonst falsch.
Es ist entweder rot oder klein ist eine wahre Aussage für etwas kleines, etwas rotes, sonst falsch.
Bis demnächst
Matthias--
Rosen sind rot.-
Hallo
Sorry das ich mich jetzt erst melde. Falls jemand mal so eine Abfrage braucht, ich habe es so gelöst. Ob es technisch richtig ist weiss ich nicht, aber es tut.
select * from Tabelle where DATE(tb_datum) >= DATE_ADD(NOW(), INTERVAL 1 MINUTE) or TIME(fahrt_zeit) >= TIME(NOW()) and DATE(tb_datum) = DATE(NOW())Danke für die Hilfe
-
-
-
-
-
-
-
-
Ich habe eine kleines Problem mit einer SQL Abfrage. In meiner Datenbank stehen Datum und Uhrzeit getrennt von einander in jeweils eigenen Spalten. Datum ist als Date und Uhrzeit als Time in der DB deklariert.
Was du da als Uhrzeit-Typ bezeichnest, ist eigentlich keine Uhrzeit, sondern eine Zeitdauer (wie in "Die Maschine läuft seit 56:28:13 (56 Stunden, 28 Minuten und 13 Sekunden). Das ist also der falsche Datentyp, auch wenn man sicherlich irgendwo argumentieren kann, 12:00:00 wäre halt "zwölf Stunden in den Tag hinein".
Die Abfrage, über die du dir den Kopf zerbrichst, könnte ganz einfach so aussehen:
SELECT * FROM Datenbank WHERE tb_datum >= NOW()... würdest du deine Daten korrekt ablegen, also in einer einzelnen Spalte vom Typ Datetime.
Überlege dir, warum das nicht so sein soll. Du wirst ja sicher einen Grund für die zwei Spalten gehabt haben. Wäge dann ab, ob du diesen zusätzlichen Aufwand weiterhin betreiben willst.
Abfragen nach "suche alle Termine um 12 Uhr" kannst du auch mit hour() auf einer Datetime-Spalte erledigen.
Termine ohne Datum, also "jeden Tag um 12 Uhr", könntest du wahlweise am Datum 0.0.0000 eintragen oder dann tatsächlich mit einer separaten Time-Spalte.-
Hello,
Abfragen nach "suche alle Termine um 12 Uhr" kannst du auch mit hour() auf einer Datetime-Spalte erledigen.
... was dann aber die Verwendung eines Index unmöglich macht.
siehe dazu auch diesen Thread.Das ist also der falsche Weg! Nicht die Daten in einer Spalte zusammenlegen, sondern einen zusätzlichen Index über beide Spalten anlegen...
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Tach!
Was du da als Uhrzeit-Typ bezeichnest, ist eigentlich keine Uhrzeit, sondern eine Zeitdauer (wie in "Die Maschine läuft seit 56:28:13 (56 Stunden, 28 Minuten und 13 Sekunden).
Woraus entnimmst du das aus der Aufgabenstellung?
Abfragen nach "suche alle Termine um 12 Uhr" kannst du auch mit hour() auf einer Datetime-Spalte erledigen.
Termine ohne Datum, also "jeden Tag um 12 Uhr", könntest du wahlweise am Datum 0.0.0000 eintragen oder dann tatsächlich mit einer separaten Time-Spalte.Jetzt soll es doch wieder nur ein Zeitpunkt und keine Dauer sein?
Wie auch immer, Abfragen, die sich erst Teile von Feldern holen müssen (wie HOUR(...)), können nicht über einen eventuellen Index abgewickelt werden und benötigen einen Full-Table-Scan. Wenn also die Uhrzeit eine derartige Rolle in der Anwendung spielt und nicht nur Beiwerk zum Datum ist, dann kann man schon abwägen, ob ein separates Feld sinnvoll ist.
dedlfix.
-
Hello,
und es soll ja auch DBMS geben, die einen Index über zwei Spalten legen können, also über DATE + TIME. Das ist dann allerdings nur sinnvoll, wenn beide Spalten in der gleichen Notation (ANSI-sortable) gespeichert werden.
Dann bleiben die Daten atomar, beide Spalten können ihren eigenen Index haben und trotzdem gibt es einen Komnbinationsindex über beide Spalten, der dann ggf. beim Query explizit genannt werden muss.
Hab' ich mir zumindest mal sagen lassen ;-P
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Was du da als Uhrzeit-Typ bezeichnest, ist eigentlich keine Uhrzeit, sondern eine Zeitdauer (wie in "Die Maschine läuft seit 56:28:13 (56 Stunden, 28 Minuten und 13 Sekunden).
Woraus entnimmst du das aus der Aufgabenstellung?
Wieso willst du die Definition von SQL-Typen seiner Aufgabenstellung entnehmen?
Das war eine allgemeine Feststellung zum Typ Time, basierend auf der Erfahrung, dass es immer wieder Leute gibt, die Datum und Uhrzeit ohne Grund trennen - und weil auch im vorliegenden Fall kein Grund für die Trennung zu erkennen ist.
Meine Erwähnung, dass man Time durchaus auch als Uhrzeit benutzen kann, hast du natürlich unterschlagen, denn mit dem Zitieren hast du es ja nicht so, du nimmst lieber das, was dir gerade in den Kram passt.
Abfragen nach "suche alle Termine um 12 Uhr" kannst du auch mit hour() auf einer Datetime-Spalte erledigen.
Termine ohne Datum, also "jeden Tag um 12 Uhr", könntest du wahlweise am Datum 0.0.0000 eintragen oder dann tatsächlich mit einer separaten Time-Spalte.Jetzt soll es doch wieder nur ein Zeitpunkt und keine Dauer sein?
Würdest du anständig zitieren anstatt Dinge aus dem Zusammenhang zu reissen, müsstest du nicht so dämliche Fragen stellen. Das:
Überlege dir, warum das nicht so sein soll. Du wirst ja sicher einen Grund für die zwei Spalten gehabt haben.
... steht vor den beiden obigen Absätzen.
Nochmal für dich: Ich kenne den Grund nicht, aus dem er zwei Spalten benutzt. Aus der Aufgabenstellung heraus sehe ich jedenfalls keinen Grund für eine Trennung. Er sollte sich die Trennung daher meiner Meinung nach überlegen.
Zwei mutmaßliche Gesichtspunkte für eine Trennung habe ich mit Kommentar als Denkanstoß angefügt. Nicht mehr, nicht weniger.Aber wenn man will, kann man sich natürlich auch dummstellen und aus zwei Vorschlägen, in welche Richtung es gehen könnte, absolute Wahrheiten lesen, so wie du es gerade machst.
Wie auch immer, Abfragen, die sich erst Teile von Feldern holen müssen (wie HOUR(...)), können nicht über einen eventuellen Index abgewickelt werden und benötigen einen Full-Table-Scan.
Keine Abfrage, die weitere, indexfähige Felder enthält, benötigt einen Full-Table-Scan. Wo entnimmst du der Aufgabenstellung, dass es bei ihm auf Full-Table-Scans hinauslaufen muss?
-
Tach!
Was du da als Uhrzeit-Typ bezeichnest, ist eigentlich keine Uhrzeit, sondern eine Zeitdauer (wie in "Die Maschine läuft seit 56:28:13 (56 Stunden, 28 Minuten und 13 Sekunden).
Woraus entnimmst du das aus der Aufgabenstellung?
Wieso willst du die Definition von SQL-Typen seiner Aufgabenstellung entnehmen?
Dass du dich auf die Definition gemäß Datentyp beziehst und nicht auf die Art der Verwendung seitens des OP ging für mich nicht ganz klar aus deiner Aussage hervor. Zudem sagt das Handbuch:
MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or 'HHH:MM:SS' format for large hours values). TIME values may range from '-838:59:59' to '838:59:59'. The hours part may be so large because the TIME type can be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative).
Das ist also nicht nur eine Zeitdauer, sondern ganz klar auch eine Uhrzeit. Eher klingt es so, dass die Dauer die nebensächliche Anwendung, so wie das da formuliert ist.
Auf den Rest gehe ich nicht weiter ein, dein Diskussionsstil lässt sehr zu wünschen übrig. Es besteht kein Grund ins Persönliche zu gehen, wenn man mal was anders verstanden hat, als es gemeint war.
dedlfix.
-
-
-