Reprise du message précédent :
Quelqu'un pourrait m'expliquer pourquoi MyWTFSql est sensible à la casse dans les noms de tables et de colonnes?

pourquoi pas

Parce-que c'est crétin?

c'est pas a moi qu'il faut le dire, je pense la même chose
Mais il y a un tas de monde qui doit penser que c'est bien vu la tétrachiée de langages de prog et de FS qui sont case sensitive

Ca évite des manipulations de chaînes lol.
 
Bon après je dis pas que c'est pas négligeable Mais à la base un language/FS est forcément case-sensitive, jusqu'à ce qu'on décide qu'il ne l'est pas, pas l'inverse, c'est sûrement pour ça que beaucoup le restent.

euh wut?

c'est peut-être pas le comportement par défaut, mais en oracle si tu crées ta table "CoMmEcA" ben y faudra l'appeler pareil dans ton select, et c'est la ou si tu n'as pas d'autocomplétion tu pleures et tu chies sur le gars qui a double quoté ses créations de table.
et c'est pareil pour tous les objets je pense, je me rappelle d'un index ou j'ai abandonné le drop au bout d'un jour, étant a court d'idée de comment l'orthographier.

Non, ce n'est pas le comportement par défaut.

Sous Win32 ça ne l'est pas. Vu que les tables ont chacun leurs fichiers ayant le nom de la table, la sensibilité à la casse dépend du FS en-dessous

Oui mais vu qu'il pose la question, son MySQL doit pas être sous Windows

Pour ça qu'il fallait lire la deuxième phrase de mon post qui en donne la raison

 
c'est bien ce que je dis, WTF?

Ch'ais pas, par ex if(name == "Fiou" ) ça me semble plus naturel que if(strlwr(name) == strlwr("Fiou" )), non ?

RAB de la tambouille interne du sgbd.

On s'en fout de la tambouille interne au C, on parle de SQL et SQL dit: "case insensitive".

A la base je faisais une remarque d'ordre général suite au post de mareek. Mais pas très intéressante donc passons

J'ose espérer que les gens qui développent des langages de prog et des FS sont un peu plus clairvoyants que les gerbeurs de code de mysql et décident de ce genre de choses dès la rédaction des spécifications.

MySQL

Underscore pour les noms de tables et de colonnes. Le camel c'est affreux dans une requête SQL.
 
Je commencerai par pendre le mec qui a créé les tables.

Je fais pareil

Chaque chose en son temps... Pendons d'abord le mec qui a créé le SQL, le reste viendra tout seul.

FTFY

 
 
bof, c'est une question d'habitude...je trouve ça très lisible, mais j'y suis habitué...

Question :
 
J'ai une appli qui permet de gérer des menus, par exemple :
 
(Menu Type Classe)
-Menu Vegetarien Somalien
-Menu Vegetarien Français
-Menu Vegetarien Allemand
 
 
En fonction du "type" de menu, on a un certain nombre d'ingrédients qui selectionnables, et chaque ingrédient aura en plus un supplément a payer en fonction de la "classe" du menu.
Chaque menu est décliné en 3 classes
 
Dans cet exemple j'ai un menu vegetarien donc je ne verrais pas les viandes.
Je paierais les carottes en dés :
2.40€ avec le Menu Somalien
2.00€ avec le Menu Français
1.80€ avec le Menu Allemand
 
Le problème que j'ai c'est : Comment gérer les prix en base pour un ingrédient? Si demande on ajoute une nouvelle classe de menu ( Menu X Américain ), comment je fais?
Parce que, je peux utiliser plusieurs colonnes prix, mais c'est pas future-proof du tout...
 
Vous feriez comment?

Je mettrais un champ "supplément" dans la table de liaison entre tes menus et leurs ingrédients autorisés.
 
Genre

pareil que la del rouge, si le prix d'un ingrédient est fonction du menu dans lequel il apparait, alors le prix est à stocker dans la table liant l'ingrédient et le menu.

Haaan, je réfléchissais à tout ça dans le mauvais sens. Merci les mecs

Un petit MCD et c'était réglé

Si dans une table j'ai 30000 records dont 29000 ont la même valeur dans la colonne "foo", mais cette valeur est un gros binaire de merde, comment je peux lister mes 29000 ids sans avoir à faire un "where foo=grosbinairedemerde"?

un truc de ce genre?

SELECT id FROM TABLE
WHERE (binaire, 29000) =
(SELECT binaire, count(*)
FROM TABLE
GROUP BY binaire
HAVING count(*)  = 29000)

SELECT id FROM TABLE
WHERE (binaire, 29000) =
(SELECT binaire, count(*)
FROM TABLE
GROUP BY binaire
HAVING count(*)  = 29000)

thanks

Ta gueule toi, retournes à ton Merise

en même tant à partir du moment où t'as un SGBDR en couche de donnée, avec quoi tu veux la faire ta modélisation . autant Merise suxx à mort, autant la partie donnée est plutot bien foutue...

Non mais
 
Bien sûr que j'ai schématisé mes données, ce que je disais plus haut que j'ai reçu un élément en plus ( j'aide le client à faire son cahier des charges ) donc ma logique était pas adaptée.

Question de base mais en rapport avec le sondage :
 
Si on a besoin de tous les champs, y-a-til une différence en perf entre faire un:
SELECT *
SELECT tous,les,champs
 
Merci

Oui, le SELECT * est très très lent. Le SELECT tous_les_champs doit toujours être préféré
(en gros, lors d'un SELECT *, le SGBD passe en revue toute la table pour connaitre ses colonnes avant de les retourner, alors qu'il les connait déjà dans le cas d'un SELECT tous_les_champs, d'ou gain de temps)

C'est bien ce que je pensais intuitivement mais je me disais aussi que peutêtre ça avait été "corrigé" par une pirouette quelconque  
 
Merci pour la confirmation

oui enfin très très lent...c'est pas non plus ce qui va être limitant pour la plupart des applications, hein.

Tu peux chiffrer la différence entre un "select *" et un "select tous, les, champs" dans le cas général ou donner des exemples concrets ? "très lent" et "gain de temps" c'est un peu vague quand même.

on peut éventuellement y voir aussi l'intéret que si la base change, en nommant les champs tu dois pouvoir péter une erreur plus rapidement...

Je ne suis pas partisant du select * mais connaissant harko, les gains en perfs qu'il indique peuvent tout à fait être du style 3 cycle CPU à gauche, 8 à droite et basta. Je me méfie un peu de l'animal