Zend FR

Bonjour,

-> Insensible à la casse lors de la connexion
Tu peux faire des requêtes "case insensitive" avec les 2 bases.

-> Utilisation UTF-8 et acceptation de tous les caractères. Donc peut-être différences de casses entre langages, logiciels, etc
Tu auras ça sans problème avec les 2 bases

-> "15 000" personnes connectés simultanément
Ca me paraît considérable, mais bon, il y a des gros sites avec ces 2 bases. Il te faudra par contre de solides compétences en tuning de base de données. Mais le problème sera le même pour les 2 bases.

-> Vaut-il mieux mettre en minuscule avec un filtre le nom d'utilisateur lors de l'inscription ET de la connexion ?
Comme tu veux, mais ça peut être géré par la base. Dans la norme SQL si je ne m'abuse, un where est de base case insensitive.

En gros pour moi les différences sont les suivantes :

Mysql :
- communauté plus grosse, beaucoup d'infos sur Internet
- un problème de gouvernance depuis le rachat de Sun par Oracle et le fork MariaDB
- des fonctionnements un peu bizarres quand on met des contraintes d'intégrités, ou qu'on utilise des procédures stockées

Postgresql :
- Plus complet et efficaces avec les fonctions étendues (contraintes d'intégrités, triggers, procédures stockées
- plus de fonctions pour construire des requêtes complexes
- communauté plus petite
- base globalement plus complexe à administrer

Je dirais que pour ton besoin elles sont équivalentes.

A+, Philippe

Concernant le where ... il est bien case sensitive. L'interclassement ne joue pas seulement sur les ORDER BY mais aussi sur cela, apparemment.

SELECT * FROM "Professeurs" WHERE username = lower('eSSai') me retourne bien la ligne avec username essai
SELECT * FROM "Professeurs" WHERE username = 'eSSai' ne me retourne rien

En y réfléchissant, il peut être intéressant que l'utilisateur retrouve son identifiant comme il l'a laissé. Donc s'il enregistre SuperMan, il peut être intéressant qu'il retrouve en se connectant "Bonjour, SuperMan", et non en minuscule. Ceci réduit le problème à zéro concernant le nom d'utilisateur, mais reste globalement une question.

Par expérience (le peu), je fais des trim() avant enregistrement. Mais je fais des htmlentities() après lecture. Il ne me viendrait plus à l'esprit de le faire avant, et je sais pourquoi. Tout comme l'absence de trim() qui viendrait influencer les validateurs qui refuseraient ce qui est acceptable, et polluerait la base de données d'espace inutile.

Concernant ce problème, ou même le cas similaire de savoir si un nom de famille doit être mis en majuscule avant insertion ou avant affichage, est assez similaire. Il est vrai qu'il dépend d'une logique, qui est : et si demain, je ne veux plus afficher les noms de famille en majuscule mais avec une lettre sur deux. Cela est donc non plus similaire mais identique à htmlentities.

Cependant, vos expériences me seraient extrêmement enrichissant, je pédale des fois des heures avant de trouver une réponse, et souvent une réponse plus palliative que vraiment absolue.

Le LIKE chez moi est case sensitive. Pour l'authentification, je ne vois pas le problème si on supprime les "%" et les "_" avant. Mais, si demain ils sortent un nouveau joker (ou si je ne les connais pas tous), ça sera tant pis