Reprise du message précédent :
personnellement je trouve çà beaucoup plus simple à gérer ensuite .
Et je trouve çà moyen de faire appel à SQL pour transformer les dates, pour moi la couche métier ou les fonctions SQL n'ont pas à formater la date, mais seulement à la récupérer dans la BDD.

ouais enfin c'est un peu réducteur hein, sinon autant réduire le SQL à la simple instruction SELECT
moi personnellement, je fais le maximum en procédures stockées, et à la fin je renvoie un recordset avec juste les résultats qui m'intéressent, que je n'ai plus qu'à récupérer dans le code client. le gain en perfs est loin d'être négligeable, mais l'inconvénient est qu'un éventuel changement de SGBD ne sera pas une sinécure.

 
Faut juste pas avoir besoin de dates d'avant 1970, quoi.
 
 
 
La couche métier interroge le stockage physique de manière à récupérer le format qu'il comprend/attend, il n'y a rien d'anormal là-dedans.
D'ailleurs tu prends le problème à l'envers : tes préférences dans la couche applicative métier impactent tes choix coté base de données, ce qui n'a aucune raison d'être le cas. On modélise la base en fonction de ce qu'on veut y mettre, pas en fonction du langage avec lequel on va l'interroger.

(comme quoi c'est parfois en voulant trop bien faire qu'on fait les choses de travers...)

effectivement  

pour moi le format attendu c'est un entier content un timestamp. Imagine que l'utilisateur peut choisir le format d'affichage d'une date ou bien que le format change en fonction de la langue (dans le cas d'un site multilingue par exemple). Pour moi le formatage doit être fait après récupération de la date dans ce cas.

ouais voilà

on s'en fout, on a pas l'intention de changer

Tu es en train de nous décrire les problèmes qui peuvent arriver si on stocke les dates sous formes de chaines de caractère ors, même un langage aussi moisi que PHP a un type datetime qui permet de t'affranchir du formatage jusqu'au moment où tu voudras afficher cette date (et où tu pourras utiliser le format qui te sied)

Bien sûr le formatage ne se fait pas dans la couche métier!
Tu confonds la représentation interne du champs dans la couche métier de ton application et le format de stockage dans la base - qui n'ont aucune raison d'être les mêmes.

D'un autre coté s'il change de langage coté application ou s'il veut avoir en même temps une appli desktop et une appli web qui attaquent la même base de données il est largement gagnant...

 
Mes profs de PHP/SQL conseillait de faire le plu de traitement possible en SQL plutôt qu'en PHP, le gain de perf serait plus important.

premature optimisation.

Quand ils disaient ça  cétait pour que  tu ne récupères que les lignes qui t'intéressent plutot que de récupérer toute la table et de faire le filtrage en php par la suite. Je doute qu'ils te conseillait de faire du formatage de date en SQL

 
Et comment tu stockes les dates inférieure au 1970-01-01 ? Genre les dates de naissance

 
Non mais on parlait des traitements en général, pas que des SELECT monchamp.

Alors tes profs sont des crétins

Bah non, ça dépend des cas, si tu t'attends à des accès depuis nombre de programmes séparés/différents tu vas essayer de mettre un maximum de métier et de logique dans la DB afin de limiter les conneries que les softs s'y connectant peuvent faire, et de leur fournir une interface clairement domaine.

Quand t'es un développeur expérimenté et que tu fais, ça peut effectivementt être utile mais ce n'est pas le genre de chose qu'il faut ériger comme une règle pour des étudiants. S'ils suivent ces conseils au pied de la lettre ils vont faire des usines à gaz en sql alors que faire la même chose en PHP aurait été plus simple plus maintenable avec des perfs similaires

je sais mais pour moi l'intérêt c'était de stocker un simple entier que je pouvais manipuler comme je le souhaitais parce que PHP dispose de nombreuses fonctions permettant de traiter les timestamp

possible

çà ne risque pas d'être mon cas même si je ne dis pas le contraire

mouais enfin y'a des limites, pour tout ce qui est formatage pour moi c'est PHP. Et puis franchement çà m'étonnerait qu'on gagne beaucoup de perf de cette façon  .
 
Bon en tout cas je voyais pas vraiment les choses de cette façon, à l'avenir je changerais peut-être de méthode mais ma façon de faire me convient pour mon projet actuel et c'est trop tard pour changer

mes applis ne sont pas faites pour des vieux

PHP a aussi de nombreuses fonction permettant de traiter les datetime et si t'as vraiment besoins du timestamp, il existe cette fonction

Un exemple classique d'un "dev" php/mysql qui veut gagner des perfs de cette façon. Il va vouloir par exemple utiliser la fonction MD5 de mysql :

$query = "SELECT * FROM users WHERE login = '$login' AND password = MD5('$password')";

sauf que dans ce cas, il faudra également échapper $password alors que si $password est hashé par PHP avant, il est sûr.
Question perf c'est un traitement supplémentaire, question sécurité, le risque c'est d'oublier d'échapper. .

Salut tout le monde !  
 
J'essai d'utiliser un script d'envoi de mail avec piece jointe mais visiblement ca refuse de fonctionner
 
Source : http://www.phpscripts-fr.net/scrip [...] php?id=150  
 
Si on essais d'envoyer un mail il y'a une erreur qui s'affiche
Class Mail, method attach : file ../upload/<nom du fichier> can't be found
 
Auriez vous une idée? j'ai mis les paramètres du dossier en CHMOD755 pourtant
 
http://www.helices-evra.com/mail/form.html

, je prend note pour les prochaines fois.

Je donne des conseils en PHP  

Exemple très bien choisi ()...dans la vraie vie tu fais une requête préparée, et j'aurais aussi plutôt tendance à utiliser le md5 du SQL - dans le sens où c'est la représentation du mot de passe dans la base.

c'est hébergé sur oxito, j'ai testé chez 1and1 et ca marche pas non plus. Sur Amen pas d'erreur mais le mail recu est bizarre...
Bon je vais laisser tomber ce script je pense, y'a pas des services en ligne pour ce genre de truc? ou quelq'un a peut etre dans son sac un script qui fonctionne

çà ne change pas grand chose à ce que j'ai dit

ok  

 
Gueuler non, mais préférable n'est pas forcément le terme le plus adapté.

Bon j'ai fini par trouver quelquechose, mtnt j'aimerais l'intégrer a mon deisgn mais l'include me renvoi une erreur

 
Pourtant mon include est tout ce qu'il y'a de plus bete....  

et il y a quoi dans /mail ?

"mail" est bien un dossier à la racine de ton OS ? (au même titre que /etc, /var, /home)

Tu utilises un chemin absolu au lieu chemin relatif là à mon avis...

pourtant c'est bien ce que je voulais, le dossier a la racine bref....
je me suis debrouillé autrement, maintenant j'ai d'autres soucis. Des qu'on touche un truc ca se barre dans tout les sens... je reviendrai poster ici si mon probleme perdure et que je n'arrive a rien
Merci

/ dans ton cas est la racine de ton serveur, pas de ton site

je fonctionne comme çà (avec une classe user perso et entre autres les méthodes addUser, updateUser, deleteUser...)
 

en fait j'avais des soucis avec l'url rewriting, mais maintenant c'est réglé, mon seul probleme c'est que l'envoi de mail fonctionne mais aucun accent ne passe
par exemple "é àè" donne en reception de mail "éà  Ã¨"

Stun peu inutile de suffixer "User" à chaque méthode alors qu'on est déja dans la classe User non ?

Encode les mails en iso, l'utf-8 ne passe pas partout.

A moins qu'il y ai une combine