codefalse
Messages postés1123Date d'inscriptionmardi 8 janvier 2002StatutModérateurDernière intervention21 avril 20091 8 janv. 2008 à 00:02
Perso, pour éviter les problemes de date engendrés par MySQL et consor, je met un type int dans ma colonne date, et je lui envoie un timestamp unix (date depuis le 1er janvier 1970 en seconde).
Les fonctions natives en php pour convertir un timestamp en jour/mois/année heure:minute:secondes sont super simples d'usage, et pour savoir si la date est dépassé de 4 semaines, tu n'a qu'a faire un date_dans_bdd < (time () + (60*60*24*7*4)) si oui alors ta news est dépassée ! :)
Je sais pas ce que diront les autres de ma méthode, mais j'en avais discuté avec Neige il me semble, et il pensais à peu pres pareil ! :)
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 8 janv. 2008 à 00:22
Hello,
ma foi, je sais que beaucoup le font, mais je ne vois guère l'intérêt perso. Je ne vois pas ce que vous reprochez aux types DATE des bdd.
Si tu fous un champ date, puis que dans ta requête tu fais un
...blabla...WHERE CURDATE() > DATE_ADD(date_validite_news, INTERVAL 4 WEEKS)
ça marche sans doute aussi bien (pas testé là hien, à vérifier pour la syntaxe).
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 8 janv. 2008 à 09:55
Pas tout a fait. En même temps, aucune BDD actuelle n'étendent pas du tout le standard ANSI SQL92.
DATE_ADD n'existe pas, chaque BDD a ses spécificités là-dessus. Et que je sache, sur mysql, le standard ne fonctionne pas (je crois que ce serait "champ_date + INTERVAL 4 WEEKS" ou un truc dans le genre).
CURDATE() est aussi une spécificité mysql, mais ça reste un alias du standard CURRENT_DATE() qui fonctionne aussi sur mysql.
codefalse
Messages postés1123Date d'inscriptionmardi 8 janvier 2002StatutModérateurDernière intervention21 avril 20091 8 janv. 2008 à 10:06
Ca devient paradoxal quand on tente de faire un systeme qui permet l'utilisation de différents serveurs sgbd, et que chaques serveurs implémentes leur méthode de requetes.. Au final je vois trois possibilités
_ modifier les requêtes en fonction du type de sgbd (foireux !)
_ faire des requetes génériques (mais pauvre en possibilité !)
_ Approfondir les classes, en implémentant des méthodes select, upadte, delete, where, limit, etc ... lourd et pas forcément flexible (si le type veut faire des jointures de jointures de jointures avec des conditions poussées (comme Coucou747 aime les faires ;)), ca risque d'être vite impossible/lacata)
Par ailleurs, ca me fait penser à un truc Malalam. Dans ta classe d'abstraction Sgbd, tu propose une solution éventuelle mais à mon sens pas performante (j'aimerai ton avis sur la chose :)) quand à l'usage de Limit. Toi, tu le gère directement en Php. L'avantage, il est clair, c'est que les Sgbd qui n'implémentent pas la requete Limit, tu pourra quand meme les gerer et ca je ne peux pas le contredire. Mais le gros probleme c'est que ta méthode, pour une bdd qui possède 3.000.000 d'entrée par exemple, va récuperer ses 3.000.000 pour en afficher 10 ?, 20 ? Ca fait chère la requete nan ?
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 8 janv. 2008 à 10:38
Faudrait savoir, lol, tu me parles de SQL ANSI et de système multi sgbdr, et ensuite tu critiques ma solution pour faire de la limitation de jeu de requête qui ELLE, est compatible avec toutes les BDD au profit d'une clause propriétaire (LIMIT je présume), comme tu le dis d'ailleurs.
Ma solution est rapide, quoi que tu en penses. Je l'utilise en prod sur un gros système. Et la raison pour laquelle je n'opte pas pour LIMIT est justement la suivante : LIMIT est propriétaire. Implémenter une technique propriétaire dans une classe d'abstraction de DB est un non sens. Tu remarqueras que j'ai donné 2 extensions : mysql, et mssql...mssql ne connait pas LIMIT. Et n'a pas d'équivalent (il y a TOP, mais ce n'est pas un équivalent du tout...c'est une clause de mer**).
Voilà pourquoi j'ai utilisé les itérateurs :-)
Au passage, tu ne fais qu'une requête sur 3 000 000 d'entrées, tu ne vas pas récupérer les resultats...et la requête en elle-même est LOIN d'être ce qu'il y a de plus coûteux.
Quant au SQL ANSI parfait, je te mets au défi de me montrer un seul site que tu aurais monté qui respecte parfaitement cette norme et dont les requêtes sont compatibles avec toutes les BDD. Bon enfin sauf si ton site fait 1 select sur 1 table hein lol.
Faut rester réaliste : il essayer de se coller à la norme dans le but de...juste au cas où... un jour on doive basculer sur un autre serveur de DB. Mais ne faire QUE du SQL ANSI pose problème. Et ce ne sera généralement pas optimisé pour TON serveur DB actuel (les clauses propriétaires sont svt optimisées).
Moi j'opte pourtant pour la 3ème solution. Les requêtes doivent être bien placées dans ton code, facile à retrouver et à modifier. Ca facilite une migration, justement. Mais ça va avec la 1ère : tu es obligé de modifier tes requêtes, sur un gros système, quand tu changes de DB. Au moins un minimum. Enfin ça dépend du type de requêtes hein...mais globalement, tu auras 2-3 ajustements à faire, forcément. Donc, il faut que ces requêtes soient faciles à retrouver et qu'elles soient évidentes.
codefalse
Messages postés1123Date d'inscriptionmardi 8 janvier 2002StatutModérateurDernière intervention21 avril 20091 8 janv. 2008 à 10:43
"Faudrait savoir, lol, tu me parles de SQL ANSI et de système multi
sgbdr, et ensuite tu critiques ma solution pour faire de la limitation
de jeu de requête qui ELLE, est compatible avec toutes les BDD au
profit d'une clause propriétaire (LIMIT je présume), comme tu le dis
d'ailleurs."
> en fait j'ai dérivé (j'ai tenté un changement de sujet, mais apparement je l'ai raté :p)
C'est vrai que ta solution est compatible avec toutes les BDD je suis carément d'accord avec toi, mais je m'inquiétait de la lourdeur si tu prends de grosses quantitiées de données. Maintenant si tu dit que la requete en elle meme ne coute rien, que ce n'est que brasser les données qui coute chere, alors jte crois (et en plus vu que tu me le confirme avec l'usage que tu en fait, alors ca va !) :)
Note : Ce n'était pas une critique, mais une remarque (ou une critique au sens neutre (et non négatif !) du terme :))
xeroxiss
Messages postés85Date d'inscriptionsamedi 30 juillet 2005StatutMembreDernière intervention 7 mai 2009 8 janv. 2008 à 11:04
Re,
Heu...
Je suis un peu embêté de devoir "m'imposer" dans mon propre post lol
Non je rigole, vos messages sont bien intéressant et je suis désolé de faire irruption dans votre débat mais c'est que je suis vraiment débutant que je me suis permis de poster ici. Enfaite c'est avec ce genre de débat que je ne m'y suis pas retrouvé avec google ^^
Juste une petite question pour éclaircir mon espirt de boulet ^^
=> La requête a effectuer à l'insertion est donc :
INSERT INTO....VALUES ... WHERE CURDATE() > DATE_ADD(date_validite_news, INTERVAL 4 WEEKS)
// ici action après 4 semaine ?
Et ajouter un champ de types DATE dans la bdd ?
Voilà merci beaucoup les gens !
Moi j'utilise Mysql (Php my admin) Hébergement OVH.
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 8 janv. 2008 à 11:11
C'est UNE solution en tous cas, à tester comme je l'ai précisé hein :-)
@codefalse => rassure-toi, je n'ai rien pris mal hein :-) Mais attention, je n'ai pas dit que ce n'était pas coûteux : ça l'est, une requête sur une grosse table récupérant bcp de données. Et LIMIT sera plus optimisé. Mais ce qui est vraiment le plus coûteux, c'est ben et bien de "brasser" les données comme tu le dis, en effet.
codefalse
Messages postés1123Date d'inscriptionmardi 8 janvier 2002StatutModérateurDernière intervention21 avril 20091 8 janv. 2008 à 12:35
Tu veux stocker la date pour un visiteur quand il reviendra plus tard ?
Si oui deux possibilités : un bdd (ce que l'on parle depuis le début :)) ou les sessions (bon yen a d'autres mais bon c'est les recommandés)
Si tu veux récuperer la valeur dans $date, alors tu fait une requete sql avec un query tout bete.
xeroxiss
Messages postés85Date d'inscriptionsamedi 30 juillet 2005StatutMembreDernière intervention 7 mai 2009 8 janv. 2008 à 13:54
Enfaite,
Le but est qu'un utilisateur arrive sur une page nommée inscription.php3
Sur cette page hors mis le formulaire d'inscription l'utilisateur peut (doit) inserer une annonce.
Je fait donc mon INSERT INTO... VALUES... dans une table membres et un deuxieme INSERT INTO dans une table annonces. J'aimerai que inserer la date dans mon INSERT annonces avec la restriction de 4 semaine.
Après 4 semaines, un mail s'envoie (ca est ok pour le mail) en indiquant au membre qui peut soit prolongé sont annonce soit elle se supprime automatiquement. Si le membre ne répond pas au mail. L'annonce se supprime d'elle meme.
Donc je fait un petit résumé:
INSERT INTO membres (mesvaleurs récupérées de mon formulaire) VALUES ($variables attribuées);
INSERT INTO annonce(mesvaleurs récupérées de mon formulaire) VALUES ($variables attribuées) WHERE ...(voir malam) ;
Rajouter un champ de type DATE sous MYSQL dans la table annonce
Voilà...Maintenant c'est vrai que j'ai pas spécialement besoin de passé en variable... Mais au cas ou je voudrait m'en servir pour signaler au membre dans son espace : Votre annonce a été enregistrée "$dates"...
Je suis un peu perdu Entre l'insertion de la date et la gestion du prolongement...
xeroxiss
Messages postés85Date d'inscriptionsamedi 30 juillet 2005StatutMembreDernière intervention 7 mai 2009 8 janv. 2008 à 23:43
Voilà...
J'ai testé ...(j'était pas chez moi tout à l'heure) ...
Bon j'ai fait :
$sql = sprintf("INSERT INTO membres (id, val1, val2, val3, val4, date) VALUES ('$id', '$val1', '$val2', '$val3', '$val4', NOW())");
Voilà dans ma base de donnée MYSQL sous PHPmyAdmin j'ai créer un champ date avec comme valeur par défaut 0000-00-00 (Ai-je bien fait ?)
Maintenant comment puis-je faire pour Commencé le compteur des 4 semaines sur rien que la date...
Et surtout comment exécuter une action après 4semaines. Exemple envoyé un mail de rappel ou prolonger l'annonce.
Voila merci
Ps: Quand vous parler de taille de poid et d'espace de base de donnée... Est-ce un problème d'utiliser cette requête meme si la table contient 10 000 entrées par exemples ?