SQL Abfrage - Bestimmter Zeitraum und eine weitere Bedingung

toxic189

Lieutenant
Registriert
Jan. 2012
Beiträge
773
Hallo Freunde,

Ich habe eine frage, gleich vorweg ich arbeite noch mit stinknormalen MySQL Abfragen (Ich weis bescheid bezüglich SQL Injection das es dafür PDO und der gleichen gibt).
Mein Problem ist, folgendes, und zwar möchte ich das er mir die Datensätze anzeigt, die 2 Bedingungen erfüllt.


Die erste: Wenn in einem Feld "nein" steht.
oder sollte ein ja drin stehen.....
Die zweite: Das Datum nicht älter als 10 Tage ab heute ist.

Sollte die Bedingungen der Datensätze nicht erfüllt sein, soll er mir die nicht anzeigen.


Ich habe es auch schon zum laufen gebracht, aber nachdem ich ein paar Änderungen am Datum gemacht habe (Konvertierung beim abspeichern in die DB etc) funktioniert diese nicht mehr.



Mein Code: konv.php


PHP:
<?php
// Datum ins englische konvertieren (für Datenbank):
function konv_date2($datum)
{
    $jahr = substr($datum,6,4);
    $mon  = substr($datum,3,2);
    $tag  = substr($datum,0,2);
    $datneu = $jahr.'-'.$mon.'-'.$tag;
return $datneu;
}
?>



Mein Code: abfrage SQL

PHP:
// SQL-Kommando: Ändern von Einträgen
	include("konv.php");
    $sql="UPDATE auftrag SET f1='$_POST[f1]', f2='$_POST[f2]', f3='$_POST[f3]',f4='$_POST[f4]',
          f5='$_POST[f5]', f6='$_POST[f6]', f7='$_POST[f7]', f8='$_POST[f8]',
          f9='$_POST[f9]', f10='$_POST[f10]', f11='$_POST[f11]', f12='$_POST[f12]', f13='$_POST[f13]',
		  f13='".mysql_real_escape_string(konv_date2($_POST['f13']))."',
		  f14='".mysql_real_escape_string(konv_date2($_POST['f14']))."',
		  f15='$_POST[f15]', 
		  f16='".mysql_real_escape_string(konv_date2($_POST['f16']))."'
                    WHERE f1=$_POST[f1]";
					
					
    // SQL-Kommando ausführen
    mysql_query($sql) or exit("Fehler im SQL-Kommando: $sql");
}

// Tabelle erneut darstellen
// SQL-Anfrage: Ergebnis ist eine vorhandene Tabelle
$sql="SELECT
		f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11,f12,
		date_format(f13, '%d.%m.%Y') as	f13, 
		date_format(f14, '%d.%m.%Y') as	f14,
		f15,
		date_format(f16, '%d.%m.%Y') as	f16
		FROM auftrag WHERE f15 = 'nein' OR TO_DAYS(f14)+1 > TO_DAYS(NOW())";



Ich hoffe es ist verständlich was ich fragen möchte, und bedanke mich schon im vorraus für eure Hilfe :)

MFG
Dome ;)
 
sieht alles viel zu kompliziert aus. das geht doch mit datediff(dd, datum, getdate()) < 10 ganz einfach.
 
Formatier alle Zeiten als Unix Timestamp, das macht die Arbeit damit viel einfacher, weils dann einfach nur (recht große) Integer sind. Probleme kriegst du damit erst in ~20 Jahren. Kombinieren kann man das wunderbar mit den PHP-Befehlen strtotime() und mktime()
 
Danke, aber verstehe das nicht ganz mit dem datediff habe mir dies angeschaut aber habe das Prinzip dahinter nicht ganz verstanden.



@Daaron ok, in wie weit muss ich dann dafür mein Code umschreiben?
Ich bin da einfach nocht nicht ganz drin in dem Thema und so wie ich im web lese, gibt es ja ständig probleme mit Zeiten/Datums angaben.


Daher meine frage, was ich am besten tun kann (am besten immer mit einem kleinen beispiel damit ich dies besser verstehe, damit mein Wunsch Funktion funktioniert ?! :D
 
Jop, viel zu kompliziert...
Code:
DATE_SUB(NOW(), INTERVAL 10 DAYS)
erfüllt seinen Zweck wunderbar. http://dev.mysql.com/doc/refman/5.1/de/date-and-time-functions.html Punkt DATE_ADD, DATE_SUB etc.

@ Daaron: Timestamps würde ich umgehen, wo es nur möglich ist. Intervalle u.ä. sind damit viel zu viel Gefrickel und einfach mal zwei Tage aufschlagen ist da auch nicht, außer du nutzt ne Kombination aus date und mktime und mit 86.400 Sekunden zu rechnen ist auch suboptimal. Einfache BETWEENS sind damit auch nur schwerlich möglich, zudem die ganzen Date-Funktionen nicht möglich sind, außer man verwendet dann FROM_UNIXTIME().
 
@Yuuri habe das nun bei mir wie folgt eingebaut, habe mir deinen Link durchgelesn und scheint mir die bessere Lösung zu sein, doch tun möchte er dies trotzdem nicht kann mir wer da weiterhelfen? :)

FROM auftrag WHERE f15 = 'nein' OR DATE_SUB(NOW(),INTERVAL 30 DAY)";
 
Du brauchst auch noch einen Vergleichsoperanden. DATE_SUB() errechnet dir ja nur das Datum minus Offset, du musst dies ja auch noch mit der entsprechenden Datumsspalte vergleichen.
 
Yuuri, es gibt was besseres als mktime, es gibt strtotime. strtotime("+2 days")... lesbarer gehts nicht. Der Vorteil an Unix Timestamps ist, dass du sie überall auswerten kannst. Du bist nicht an irgend welche Formate gebunden und auch Zeitzonen entfallen. Eine Timestamp ist immer Zulu.

Wenn du rein auf der Datenbank operierst sind die SQL Date-Formate besser, aber wann tut man das schon? Ist doch immer irgend eine Scripting-Engine dahinter, die den Mist aufschlüsseln kann.
 
Daaron schrieb:
Yuuri, es gibt was besseres als mktime, es gibt strtotime. strtotime("+2 days")... lesbarer gehts nicht.
Code:
<?php

$a = new DateTime();

var_dump( $a );

$a->add( new DateInterval( 'P2D' ) );

var_dump( $a );

$a->setTimezone( new DateTimeZone( 'Europe/Moscow' ) );

var_dump( $a );
Code:
object(DateTime)[1]
  public 'date' => string '2014-07-23 11:48:38' (length=19)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/Berlin' (length=13)

object(DateTime)[1]
  public 'date' => string '2014-07-25 11:48:38' (length=19)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/Berlin' (length=13)

object(DateTime)[1]
  public 'date' => string '2014-07-25 13:48:38' (length=19)
  public 'timezone_type' => int 3
  public 'timezone' => string 'Europe/Moscow' (length=13)
Warum mit plain ints rumärgern, wenn es doch dafür bereits ne wunderschöne Abstraktion gibt? Falls einem das Handling nicht gefällt, kann man immer noch die Klasse erben und neu modellieren.
Daaron schrieb:
Der Vorteil an Unix Timestamps ist, dass du sie überall auswerten kannst.
Auch bei Systemen mit 16 Bit ints? ;) Ich weiß aber nicht, wie das bei ganz alten Systemen aussieht, mit welcher Art oder welchem Typ diese Daten darstellen bzw. intern arbeiten.
Daaron schrieb:
Du bist nicht an irgend welche Formate gebunden und auch Zeitzonen entfallen. Eine Timestamp ist immer Zulu.
Warum selbst um Zeitzonen kümmern, wenn es etwas gibt, was sich darum kümmert?
Daaron schrieb:
Wenn du rein auf der Datenbank operierst sind die SQL Date-Formate besser, aber wann tut man das schon? Ist doch immer irgend eine Scripting-Engine dahinter, die den Mist aufschlüsseln kann.
Sollte man imho tunlichst immer machen. Nicht umsonst hat jede Sprache/Framework immer irgendwo ne DateTime-Klasse, die dir dort alles fern hält und auch Zeitzonen u.ä. mit einbezieht. Zusätzlich gibts hier keine Beschränkung von 32 Bit ints. In PHP mag das vielleicht so erstmal nicht das Problem sein, denkt man aber daran, dass heute noch Win 3.1 Maschinen laufen, sehe ich sehr schwarz für die Zukunft. Deshalb gleich auf die DateTime-Klassen schwenken, dann hat man definitiv keine Probleme.
 
Vielen dank leute, habe meine wunschfunktion hinbekommen :))

Danke an euch :)


LG
Dome ;)
 
Zurück
Oben