par
caroube » 09 mai 2008, 18:34
Caroube => quand je disais sensible à la casse j'entendais qu'il ne comprendrait pas que "Magasin" et "magasin" sont une seule et même table (à moins que la dernière version de SQL le prenne en charge, ça je ne peux pas le dire je n'y suis pas encore passée).
Je confirme : on ne peut pas dire que SQL est sensible à la casse ou pas.
Si tu prends des bases de données telle que Oracle, MySQL, SQLite, Access, SQLAnywhere, ... tu peux écrire "Magasin" ou "magasin". Par contre, les produits "Microsoft SQL Server" ou "Sybase SQL Server" sont sensibles à la casse (du moins dans le paramétrage par défaut).
Et je vais le dire une dernière fois avant de laisser tomber. Qu'est-ce que ça te dit si tu mets
"num_magasin" au lieu de
"num-magasin" dans ta requête ? Parce que là, on tourne en rond autour d'une erreur de frappe !!!
Dans ce cas je vous conseille d'utiliser l'écriture plus spécifique de SQL qui consiste à encadrer le nom des champs avec des ` (touches Alt Gr + 7).
Au risque de passer pour un emm..., je dis non, ce n'est pas une bonne idée. Cette apostrophe ` est un pis-aller dans les cas où l'on est obligé d'avoir des noms de champs qui comportent des espaces, des accents, des mots réservés, ...
1) On est quasiment jamais obligé.
2) Ce n'est pas une syntaxe SQL standard. De nombreuses bases de données ne supportent pas ce caractère.
3) Dans ce cas, le champ dans la base s'appelle num_magasin et pas num-magasin !
Concernant le fait que num_magasin soit un champs ambigu, ici il n'y a pas d'ambiguité, c'est bien une valeur commune à deux tables, d'où la possibilité d'un NATURAL JOIN.
je ne parle pas du natural join (syntaxe haïssable à mon avis), mais de l'ambiguité de ce qu'il y a entre le select et le from. Si vous avez deux tables avec un même nom de champ, vous ne pouvez pas faire la requête sans préfixer (imaginez que les identifiants de Produit et de magasin s'appellent id)
[quote="animithra"]Caroube => quand je disais sensible à la casse j'entendais qu'il ne comprendrait pas que "Magasin" et "magasin" sont une seule et même table (à moins que la dernière version de SQL le prenne en charge, ça je ne peux pas le dire je n'y suis pas encore passée).[/quote]
Je confirme : on ne peut pas dire que SQL est sensible à la casse ou pas.
Si tu prends des bases de données telle que Oracle, MySQL, SQLite, Access, SQLAnywhere, ... tu peux écrire "Magasin" ou "magasin". Par contre, les produits "Microsoft SQL Server" ou "Sybase SQL Server" sont sensibles à la casse (du moins dans le paramétrage par défaut).
Et je vais le dire une dernière fois avant de laisser tomber. Qu'est-ce que ça te dit si tu mets [color=red]"num_magasin"[/color] au lieu de [color=red]"num-magasin"[/color] dans ta requête ? Parce que là, on tourne en rond autour d'une erreur de frappe !!!
[quote="animithra"]Dans ce cas je vous conseille d'utiliser l'écriture plus spécifique de SQL qui consiste à encadrer le nom des champs avec des ` (touches Alt Gr + 7). [/quote]
Au risque de passer pour un emm..., je dis non, ce n'est pas une bonne idée. Cette apostrophe ` est un pis-aller dans les cas où l'on est obligé d'avoir des noms de champs qui comportent des espaces, des accents, des mots réservés, ...
1) On est quasiment jamais obligé.
2) Ce n'est pas une syntaxe SQL standard. De nombreuses bases de données ne supportent pas ce caractère.
3) Dans ce cas, le champ dans la base s'appelle num_magasin et pas num-magasin !
[quote="animithra"]Concernant le fait que num_magasin soit un champs ambigu, ici il n'y a pas d'ambiguité, c'est bien une valeur commune à deux tables, d'où la possibilité d'un NATURAL JOIN.[/quote]
je ne parle pas du natural join (syntaxe haïssable à mon avis), mais de l'ambiguité de ce qu'il y a entre le select et le from. Si vous avez deux tables avec un même nom de champ, vous ne pouvez pas faire la requête sans préfixer (imaginez que les identifiants de Produit et de magasin s'appellent id)