Datum A größer als Datum B

[Alex_winf01]

Hallo liebe Forengemeinde,

wie kann ich über SQL abfragen, ob Datum A größer ist wie Datum B? Die Datenbankstruktur habe ich vom Vorgänger übernommen und sowohl Datum A als auch Datum B sind in der DB als Strings hinterlegt (JA ich weiss, dass man das nicht machen soll). Bin auch schon dabei, dass zu ändern.:upps

[flashpixx]

Bei Strings machst Du eine lexikographische Analyse. Rechne die String entsprechend in Unixzeit ? Wikipedia um und dann kannst Du sie vergleichen. Da Du das DBMS nicht nennst, solltest Du eben selbst nachschauen, wie Du mit entsprechenden Stringfunktionen aus den Stringdaten einen numerischen Wert machst.

Ich empfehle dringend die Datenbank zu überarbeiten

[martin88]

Ich kann mich der Meinung von flashpixx nur anschließen. Wahrscheinlich musst du ja noch öfter mit/an der Datenbank arbeiten. Da lohnt sich die Mühe auf jeden Fall, die Werte umzuwandeln. Das ist zwar auch Arbeit, aber danach hast du es deutlich leichter.

[raiserle]

In welchem Format (STRING) liegen sie denn vor?

Bevor du die DB umbaust - erst *DENKEN* dann *HANDELN*! Es kann - wenn du einfach mal so drauf lost gehst, an anderen Stellen zu Problemen kommen.

Man könnte auch schnell mal ne Prozedur schreiben - und seine Berechnungen darüber machen lassen. Klar, die *Feine* ist es nicht, aber bevor dir der Code an anderen Stellen um die Ohren fliegt. Q'nD muss ja nicht immer schlecht sein!!

vG

[flashpixx]

Man könnte auch schnell mal ne Prozedur schreiben - und seine Berechnungen darüber machen lassen.

Problematisch werden solche Dinge aber, wenn z.B. Grouping, Having oder auch Between verwendet werden muss, weil ich für jede Row der Tabelle die Berechnung durchführen muss und Stringverarbeitung ist "teuer".

Außerdem führen solche Klimmzüge immer dazu, dass man Fehler, die vorhanden sind, nicht behebt, sondern den "einfach und schnellen" Weg wählt, d.h. Dokumtationsanpassung muss hier ebenfalls erfolgen.

Die Lösung, auch wenn sie mit Arbeit verbunden ist, ist das Redesign der entsprechenden Tabellen und dann ggf. die Anpassung des Frontends, wobei das kein großes Problem darstellt, sofern hier korrekt z.B. mit Prepare-Statements gearbeitet wurde.

[raiserle]

Außerdem führen solche Klimmzüge immer dazu, dass man Fehler, die vorhanden sind, nicht behebt, sondern den "einfach und schnellen" Weg.....

Sagt ja auch keiner etwas dagegen! Man sollte sich eben nur im Vorfeld überlegen, wenn man jetzt an der einen Stelle anfängt - dass es irgendwo anders auch zu Problemen kommen kann.

Im übrigen ist schon abzuwägen, wenn man nur kleine Anpassungen, Erweiterungen machen soll - ob es Wert ist, den kopletten Code samt DB zu bugfixen .

Wenn eine Aufgabe klar definiert ist - kann man auf die Mängel hinweisen - eine Lösung vorschlagen! Aber auf keinen Fall selber anfangen irgendwas zu verbessern!

[flashpixx]

Full Ack.

Im übrigen ist schon abzuwägen, wenn man nur kleine Anpassungen, Erweiterungen machen soll - ob es Wert ist, den kopletten Code samt DB zu bugfixen .

Ich denke ich würde hier eine Übergangslösung bauen, d.h. Stringverarbeitung implementieren und aktuell für die Problemstellung verwenden. Langfristig wäre dann die DB aber zu fixen und die Front- und Backends anzupassen.