Validité...

Bonsoir,

Je suis façe a un petit problème au niveau d'une insertion de date et de validation dans une base de donnée...


Mon but est de créer une annonce par l'utilisateur et d'inserer la date afin de donner a l'annonce une validité de 4 semaine...

Après quoi le membre peu soit, prolonger son annonce soit elle se supprime automatiquement...

J'éspère que j'ai réussi a être claire, et que vous auriez des idées pour moi.

Merci, bonne soirée

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 ! :)

Sur ce ! Bonne nuit ! :)

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).

salut

mysql prevoit des fonctions de gestion des dates sur des champs date et timestamp... alors pourquoi prendre un int ?

/**
* @author coucou747 <coucou747@hotmail.com>
* @see irc://cominweb.uni-irc.net/#programmation
*/

@coucou747 : Parce que j'ai toujours galéré autrement :p (et surtout car j'ai jamais du approfondir la chose :p)

Sinon est-ce que c'est supporté par toutes les bdd's ?
Genre la requete de Malalam est-elle ANSI ou juste spécialement faite pour MySQL ?

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.

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 ?

(Au passage, une requete Limit ne fait pas mieux puisque une "LIMIT 2.500.000, 20" ira trier les 2.500.020 premieres lignes !)
(source, Nexen.net : http://www.nexen.net/actualites/tutorial/17953-pourquoi_la_pagination_coute_autant_de_performances.php)

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.

"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 :))

(:

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.   

Vive malam :p