Benutzer mit den meisten Antworten
nur die Uhrzeit aktualisieren???

Frage
Antworten
-
Für alle die vielleicht das gleiche Problem haben, habe folgende Lösung im Netz gefunden:
UPDATE MyTable SET <mein_Feld> = DATEADD(HOUR, 23,DATEADD(MINUTE, 58, CAST(FLOOR(CAST(<mein_Feld> AS FLOAT)) AS DATETIME))) where <meine_Bedingung>
Gruesse, NUNUI
- Als Antwort markiert Nunui Dienstag, 29. Mai 2018 00:33
-
"wenn diese Operation typisch bzw häufiger auftritt, man doch besser generell Datum und Zeit in verschiedenen Spalten getrennt speichern sollte"
Das kann ich so nicht pauschal bestätigen, da es genug Anwendungsbereiche gibt, in denen SQL dann nicht mehr sinnvoll anzuwenden ist.
Man denke nur an Min/Max-Funktionen. Ein Max(DateTime) ist nicht dasselbe wie ein Max(Date), Max(Time).
Abfragen und Joins für between Zeitraum sind dann unmöglich ohne die Felder wieder zusammen zu führen, was dann einen Tablescan verursacht.Leider findet man dies dann häufiger in den Datenbanken (z.T. historisch bedingt, als es DateTime noch nicht gab) und wundert sich dann über Abfragezeiten und komplexe Konstrukte.
Für die Lösung oben geht auch folgendes:
cast(cast(MyDateTime as date) as datetime) + cast('12:23:49' as datetime)
Der Inner-Cast schneidet die Uhrzeit ab, der Outer-Cast hängt die Zeit 00:00:00 dran.
Ansonsten sollte man Informationen immer so speichern, wie sie im Zusammenhang stehen.
Der 2. Ausdruck erzeugt ein Datetime ohne Datum.
- Bearbeitet Der Suchende Dienstag, 29. Mai 2018 07:59
- Als Antwort markiert Nunui Dienstag, 29. Mai 2018 17:11
Alle Antworten
-
Ob Datumfeld oder Textfeld: Man macht immer ein Update für die gesamte Spalte.
Ausnahme, für varchar(max)-Felder kann man mit der .WRITE -Erweiterung eine Änderung an einer Position durchführen.
Aber: eine Spalte mit Datentyp Date hat keinen Zeitanteil. Dafür gäbe es datetime2 und andere. Die Frage macht irgendwie keinen Sinn, oder was gnau hast Du da vor Dir?Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform MCSE Data Platform
MCSM Charter Member, MCITP Charter Member etc.
www.SarpedonQualityLab.com (Founder) -
Danke für die Antwort.
Mein Problem ist wie folgt. Ich habe mehrere Einträge (Zeilen), die ein Datumsfeld beinhalten.
Der Inhalt vom Datumsfeld sieht wie folgt aus: "2018-02-16 00:00:00.000"
Jetzt möchte das Datumsfeld so ändern, dass das Datum unverändert bleibt und nur die Uhrzeit geändert wird, nämlich so: "2018-02-16 23:58:00.000"
Ist das überhaupt möglich?
Gruesse, NUNUI
-
Für alle die vielleicht das gleiche Problem haben, habe folgende Lösung im Netz gefunden:
UPDATE MyTable SET <mein_Feld> = DATEADD(HOUR, 23,DATEADD(MINUTE, 58, CAST(FLOOR(CAST(<mein_Feld> AS FLOAT)) AS DATETIME))) where <meine_Bedingung>
Gruesse, NUNUI
- Als Antwort markiert Nunui Dienstag, 29. Mai 2018 00:33
-
Aha, dann war es also doch kein "Date" vom Datentyp, sondern datetime oder datetime2.
Und bei der Frage ging es eher um einen Weg, wie man auf Basis der bestehenden Zeit Zeit dazuaddiert.
Ansonsten kann man ja einfach schreiben "Set Spalte = 'AlterDatumsanteil Zeitanteil"
Der Datenbankdesigner wird an dieser Stelle aufmerken, und feststellen, dass, wenn diese Operation typisch bzw häufiger auftritt, man doch besser generell Datum und Zeit in verschiedenen Spalten getrennt speichern sollte. Normalisierung ist auch heute in Zeiten von BigData noch kein Schimpfwort :). Dafür gibt es seit langem nun date und auch time als Datentypen, die für sich auch wunderbar effizient sind
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform MCSE Data Platform
MCSM Charter Member, MCITP Charter Member etc.
www.SarpedonQualityLab.com (Founder) -
"wenn diese Operation typisch bzw häufiger auftritt, man doch besser generell Datum und Zeit in verschiedenen Spalten getrennt speichern sollte"
Das kann ich so nicht pauschal bestätigen, da es genug Anwendungsbereiche gibt, in denen SQL dann nicht mehr sinnvoll anzuwenden ist.
Man denke nur an Min/Max-Funktionen. Ein Max(DateTime) ist nicht dasselbe wie ein Max(Date), Max(Time).
Abfragen und Joins für between Zeitraum sind dann unmöglich ohne die Felder wieder zusammen zu führen, was dann einen Tablescan verursacht.Leider findet man dies dann häufiger in den Datenbanken (z.T. historisch bedingt, als es DateTime noch nicht gab) und wundert sich dann über Abfragezeiten und komplexe Konstrukte.
Für die Lösung oben geht auch folgendes:
cast(cast(MyDateTime as date) as datetime) + cast('12:23:49' as datetime)
Der Inner-Cast schneidet die Uhrzeit ab, der Outer-Cast hängt die Zeit 00:00:00 dran.
Ansonsten sollte man Informationen immer so speichern, wie sie im Zusammenhang stehen.
Der 2. Ausdruck erzeugt ein Datetime ohne Datum.
- Bearbeitet Der Suchende Dienstag, 29. Mai 2018 07:59
- Als Antwort markiert Nunui Dienstag, 29. Mai 2018 17:11
-
...Man denke nur an Min/Max-Funktionen. Ein Max(DateTime) ist nicht dasselbe wie ein Max(Date), Max(Time).
Abfragen und Joins für between Zeitraum sind dann unmöglich ohne die Felder wieder zusammen zu führen, was dann einen Tablescan verursacht.
...
Keine Sorge, eine AND-Verknüpfung führt noch lange nicht zu Scans. Man hat im Gegenteil kleinere Indexe.
Und das performt dann richtig gut, selbst bei Terabytes an Daten, wo ich das so implementiere. Notfalls kann man mal mit computed Columns arbeiten, aber ich erinner mich nicht, dass wir das dort expliziet benötigt hatten.
Und bei solchen Datenmengen ist ein bisschen Mehr an Code ein gern gezahlter Preis für gewonnene Performance.
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform MCSE Data Platform
MCSM Charter Member, MCITP Charter Member etc.
www.SarpedonQualityLab.com (Founder) -
Eine Abfrage
where Datum between datum1 and Datum2 and Zeit between Zeit1 and Zeit2
liefert ein anderes Ergebnis als
where Datum + Zeit between DateTime1 and DateTime2
weil die Zeitabfrage ja nicht an das Datum gebunden ist. Somit wäre sinnvoller Weise ein berechnetes Feld mit einem Index darüber wieder von Vorteil.
Da ich persönlich aber Vereinfachungen liebe, verwende ich dann doch besser ein DateTime-Feld.- Bearbeitet Der Suchende Mittwoch, 30. Mai 2018 08:02