Bonjour à tous !

J'ai une simple petite question, MySQL est il sensible à la casse ?

Par exemple, dans ma BDD vaut il mieux un champ dateCreation ou date_creation ?
Simple question d'uniformité, pas envie d'avoir des problèmes par la suite

Merci d'avance

Bonne journée

C'est comme tu veux!

Mais respecte la casse dans tes requêtes en tout point.

SELECT * FROM MaTable WHERE Champ = 12

SELeCT * FROM MaTable WHERE Champ = 12

sont deux plans d'exécution distincts et donc deux résultats différents et deux mises en cache différentes

http://www.fanaticalsolutions.com/2009 [...] ution-basics/

"Before even parsing a query, MySQL checks for it in the query cache, if the cache is enabled. This operation is a case sensitive hash lookup. If the query differs from a similar query in the cache by even a single byte, it won’t match, and the query processing will go to the next stage."

Une grande différences souvent oubliée avec de lourdes conséquences.

Merci beaucoup pour ta réponse

... Je pense me tourner vers des nom de champ sans majuscule...

Quels caractères puis je utiliser dans un nom de champ ? Je ne parviens pas à trouver dans la doc :/

On peut utiliser '_' je pense non ?
Sais tu où je peux trouver une liste exhaustive ?

Encore merci

Citation : netdoor.fr

sont deux plans d'exécution distincts et donc deux résultats différents et deux mises en cache différentes

Deux requêtes identiques ayant une casse différentes auront chacune une entrée dans le "query cache". Certes.
Mais elles auront le même plan d'exécution.
Et je ne voit pas pourquoi elle donneraient des résultats différents.

Après, quelle place prendrait ces 3 requêtes dans le "query cache":
SeLeCt col FrOm taBle;
SElect COL from TAblE;
select coL froM tablE;
comparé à l'unique:
SELECT COL FROM TABLE;
Je ne serait pas le mesurer. Et est-ce que cela a un impact sur les perfs ? encore moins.

Citation

Quels caractères puis je utiliser dans un nom de champ ? Je ne parviens pas à trouver dans la doc :/

On peut utiliser '_' je pense non ?
Sais tu où je peux trouver une liste exhaustive ?

http://sqlpro.developpez.com/cours/standards/#L3
Ce n'est pas à suivre à la lettre, ça te donnes une idée.

@cintre sournois

ah excuse moi, quand je parle de résultat, je parle d'occurrence de résultat...

"A" résultat 1
"A" résultat 2

deux occurrences, une même valeur...

Apparemment MySQL ne cache pas ses plans d'exécutions (ou pas encore!? ou dans une prochaine version?! bref)...mais Oracle et SQL Server le font, et il s'agit de plans compilés.

Dans leurs cas la perte de performance est encore plus importante:

la "référence interne du SGBDR" du plan d'exécution ne sera donc pas la même, même si le plan d'exécution est identique en tout point pour la logique. Disons que l'"identifiant" du plan ne sera pas le même...

Ainsi, au lieu de réutiliser un plan d'exécution déjà établi, le SGRBDR va compiler un nouveau plan...qui sera en fait le même. Mais le SGBDR ne le sait pas et ne veux pas le savoir car tenir compte de la casse au niveau d'un algo de recherche en cache de plan c'est perdre un trop grand gain...

Le SGBDR va donc perdre en performance...sur plusieurs points:
1) le query optimizer va devoir compiler un plan (ce qu'il n'aurait pas eu à faire si la casse avait été la même), donc il perd du temps plutôt que d'extraire du cache de plan un plan déjà tout fait.
2) comme la référence du plan n'est pas la même, la valeur n'est pas en cache, et donc...le SGBDR répondra moins rapidement.
3) si on va plus loin, le cache contiendra plusieurs résultats (occurrences identiques!) de requête de logique identique, pour rien...et le cache va évincer (algo LRU) des résultats peut-être, eux, utiles...(principe du cache)

bref

Tout SGBDR garde en mémoire les plans d'exécutions des requêtes. MySQL en a forcément un.

Un SGBDR travail uniquement en RAM, et est sensé être "up" H24, jamais éteint/redémarré.
Dans un monde parfait (pour les bases tenant en RAM), pour toutes requêtes, quelque soit le casse, l'explain plan a déjà était calculé, il n'est pas calculé a chaque fois.

Pour tout ce qui est performance, je ne sait pas comment ça fonctionne physiquement, je ne pourrais rien dire là dessus. Mais c'est on ne peut plus vague et imprécis de dire en gros "si on ne respecte pas toujours la même casse on est moins performant".

Citation : Cintre Sournois

Tout SGBDR garde en mémoire les plans d'exécutions des requêtes. MySQL en a forcément un.

On dirait que non en 5.1, étonnant!
<lien url="http://bugs.mysql.com/bug.php?id=42808"></lien>

Mais s'ils l'ont pas déjà ajouté, ils vont finir par y venir forcément...

Citation : Cintre Sournois

Un SGBDR travail uniquement en RAM, et est sensé être "up" H24, jamais éteint/redémarré.
Dans un monde parfait (pour les bases tenant en RAM), pour toutes requêtes, quelque soit le casse, l'explain plan a déjà était calculé, il n'est pas calculé a chaque fois.

Oui il est calculé la première fois et ensuite il est en cache de plan d'exécution et le SGBDR sait que pour telle requête, c'est ce plan qu'il faudrait utiliser, en effet...

Citation : Cintre Sournois

Mais c'est on ne peut plus vague et imprécis de dire en gros "si on ne respecte pas toujours la même casse on est moins performant".

Il me semblait l'avoir vu dans les "Best practices"...

Je ne connais pas non plus, réellement, le gain en performance d'une telle convention...

En tout cas ca aide et ca coute rien de mettre les mots réservés du language sql en MAJUSCULE !