un été studieux m'a permis de plancher sur quelques sujets souvent
rencontrés dans les forums. C'est pourquoi je vous informe de la
parution de certains articles...
1) Les erreurs les plus fréquentes en SQL :
- Nommer les objets SQL : pas de blanc ni de caractères diacritique !
- "Champ" et "enregistrement" n'existent pas dans les bases de données
- NULL n'est pas une valeur... bien au contraire...
- CASE SENSITIVE : une fausse bonne idée
- Comment récupérer le dernier truc : tout simplement impossible
- Ajouter un objet à la ne position : absurde !
- Le format de la date... une bonne idée mal comprise
- les doublons : problématiques...
A lire donc, à l'URL : http://sqlpro.developpez.com/SQL_AZ_E.html
2) Données et normes
Savez vous que de nombreux organismes externe proposent des normes et
modèles de données qui vous simplifient la vie ? La normalisation permet
de gagner facilement de l'argent si elle est implantée lors de l'analyse
du projet. Exemples concrets et payants !
A lire donc, à l'URL : http://sqlpro.developpez.com/Normes/SQL_normes.html
3) dates... excétéra...
Quelques ajouts importants à la page web consacré aux problématiques de
calculs temporels :
Le traitement des dates partielles
le calcul des jours fériés mobiles
A lire donc à l'URL : http://sqlpro.developpez.com/Planning/SQL_PLN.html
4) des casses têtes SQL !
Quatre nouveaux casse tête voient le jour à la page :
http://sqlpro.developpez.com/SQL_AZ_P.html
- Ordonner et réordonner !
- Jointure hétérogène multiple
- Insertion conditionnelle
- Un arbre à deux niveaux
Ce qui fait 24 problèmes a vous torturer le citron !
*******
Bien entendu les critiques et suggestions sont les bienvenues !
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto:brouardf@club-internet.fr ******************
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD - SQLpro
bonjour,
Christophe Cuq a écrit:
Fred BROUARD - SQLpro writes:
A lire donc, à l'URL : http://sqlpro.developpez.com/Normes/SQL_normes.html
Dans lequel on trouve de belles bêtises sur les jeux de caractères.
Lesquelles ?
La norme ISO prévoit bien les ligatures ½ et ¼, il suffit d'utiliser iso-8859-15 qui est nettement plus adapté au français.
Cela est spécifié dans la ligne NOTA juste avant le tableau vert en 1.1. Peut être l'avez vous lu trop rapidement. C'est pourquoi j'ai jugé utile d'ajouter un paragraphe dans le tableau
En outre, il permet d'écrire le caractère ¤.
Et si l''on veut vraiment pouvoir coder plusieurs langues dans une même base, y compris à alphabet "particulier" (cyrillique, chinois...) il suffit d'utiliser utf-8 (iso-10646) et d'utiliser une police adaptée.
Moins souple car pas encore très utilisé au seins des SGBDR... A déconseiller notamment pour XML !
En tout cas merci !
A +
Bien entendu les critiques et suggestions sont les bienvenues !
Eh bien voilà pour un début.
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
bonjour,
Christophe Cuq a écrit:
Fred BROUARD - SQLpro <brouardf@club-internet.fr> writes:
A lire donc, à l'URL : http://sqlpro.developpez.com/Normes/SQL_normes.html
Dans lequel on trouve de belles bêtises sur les jeux de caractères.
Lesquelles ?
La norme ISO prévoit bien les ligatures ½ et ¼, il suffit d'utiliser
iso-8859-15 qui est nettement plus adapté au français.
Cela est spécifié dans la ligne NOTA juste avant le tableau vert en 1.1.
Peut être l'avez vous lu trop rapidement. C'est pourquoi j'ai jugé utile
d'ajouter un paragraphe dans le tableau
En outre, il permet d'écrire le caractère ¤.
Et si l''on veut vraiment pouvoir coder plusieurs langues dans une
même base, y compris à alphabet "particulier" (cyrillique,
chinois...) il suffit d'utiliser utf-8 (iso-10646) et d'utiliser une
police adaptée.
Moins souple car pas encore très utilisé au seins des SGBDR...
A déconseiller notamment pour XML !
En tout cas merci !
A +
Bien entendu les critiques et suggestions sont les bienvenues !
Eh bien voilà pour un début.
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto:brouardf@club-internet.fr ******************
A lire donc, à l'URL : http://sqlpro.developpez.com/Normes/SQL_normes.html
Dans lequel on trouve de belles bêtises sur les jeux de caractères.
Lesquelles ?
La norme ISO prévoit bien les ligatures ½ et ¼, il suffit d'utiliser iso-8859-15 qui est nettement plus adapté au français.
Cela est spécifié dans la ligne NOTA juste avant le tableau vert en 1.1. Peut être l'avez vous lu trop rapidement. C'est pourquoi j'ai jugé utile d'ajouter un paragraphe dans le tableau
En outre, il permet d'écrire le caractère ¤.
Et si l''on veut vraiment pouvoir coder plusieurs langues dans une même base, y compris à alphabet "particulier" (cyrillique, chinois...) il suffit d'utiliser utf-8 (iso-10646) et d'utiliser une police adaptée.
Moins souple car pas encore très utilisé au seins des SGBDR... A déconseiller notamment pour XML !
En tout cas merci !
A +
Bien entendu les critiques et suggestions sont les bienvenues !
Eh bien voilà pour un début.
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
Christophe Cuq
Fred BROUARD - SQLpro writes:
bonjour,
Bonsoir,
Cela est spécifié dans la ligne NOTA juste avant le tableau vert en 1.1. Peut être l'avez vous lu trop rapidement. C'est pourquoi j'ai jugé utile d'ajouter un paragraphe dans le tableau
Effectivement, elle était bien cachée (avant le tableau).
Tiens, en relaisant, j'ai trouvé une autre erreur :
,---- | En parcourant les codes ISO-8859, ne perdez pas votre temps a chercher | la ligature `oe' utilisee en francais: elle n'y est pas. `----
Ben si, *elle y est*, dans iso-8859-15 :)
même base, y compris à alphabet "particulier" (cyrillique, chinois...) il suffit d'utiliser utf-8 (iso-10646) et d'utiliser une police adaptée.
Moins souple car pas encore très utilisé au seins des SGBDR... A déconseiller notamment pour XML !
C'est bizarre, ça, parceque la référence XML prévoit *expressément* le support de utf-8 *et* 16 :
(http://www.w3.org/TR/REC-xml#NT-Char)
,----[ Extensible Markup Language (XML) 1.0 (Second Edition) | W3C Recommendation 6 October 2000 ] | 2.2 Characters | | [Definition: A parsed entity contains text, a sequence of characters, | which may represent markup or character data.] [Definition: A | character is an atomic unit of text as specified by ISO/IEC 10646 | [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are | tab, carriage return, line feed, and the legal characters of Unicode | and ISO/IEC 10646. The versions of these standards cited in A.1 | Normative References were current at the time this document was | prepared. New characters may be added to these standards by amendments | or new editions. Consequently, XML processors must accept any | character in the range specified for Char. The use of "compatibility | characters", as defined in section 6.8 of [Unicode] (see also D21 in | section 3.6 of [Unicode3]), is discouraged.] | | Character Range | [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate | blocks, FFFE, and FFFF. */ | | The mechanism for encoding character code points into bit patterns may | vary from entity to entity. All XML processors must accept the UTF-8 | and UTF-16 encodings of 10646; the mechanisms for signaling which of | the two is in use, or for bringing other encodings into play, are | discussed later, in 4.3.3 Character Encoding in Entities. `----
En tout cas merci !
Avec plaisir.
-- CHC
Fred BROUARD - SQLpro <brouardf@club-internet.fr> writes:
bonjour,
Bonsoir,
Cela est spécifié dans la ligne NOTA juste avant le tableau vert en
1.1. Peut être l'avez vous lu trop rapidement. C'est pourquoi j'ai
jugé utile d'ajouter un paragraphe dans le tableau
Effectivement, elle était bien cachée (avant le tableau).
Tiens, en relaisant, j'ai trouvé une autre erreur :
,----
| En parcourant les codes ISO-8859, ne perdez pas votre temps a chercher
| la ligature `oe' utilisee en francais: elle n'y est pas.
`----
Ben si, *elle y est*, dans iso-8859-15 :)
même base, y compris à alphabet "particulier" (cyrillique,
chinois...) il suffit d'utiliser utf-8 (iso-10646) et d'utiliser
une police adaptée.
Moins souple car pas encore très utilisé au seins des SGBDR...
A déconseiller notamment pour XML !
C'est bizarre, ça, parceque la référence XML prévoit *expressément* le
support de utf-8 *et* 16 :
(http://www.w3.org/TR/REC-xml#NT-Char)
,----[ Extensible Markup Language (XML) 1.0 (Second Edition)
| W3C Recommendation 6 October 2000 ]
| 2.2 Characters
|
| [Definition: A parsed entity contains text, a sequence of characters,
| which may represent markup or character data.] [Definition: A
| character is an atomic unit of text as specified by ISO/IEC 10646
| [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are
| tab, carriage return, line feed, and the legal characters of Unicode
| and ISO/IEC 10646. The versions of these standards cited in A.1
| Normative References were current at the time this document was
| prepared. New characters may be added to these standards by amendments
| or new editions. Consequently, XML processors must accept any
| character in the range specified for Char. The use of "compatibility
| characters", as defined in section 6.8 of [Unicode] (see also D21 in
| section 3.6 of [Unicode3]), is discouraged.]
|
| Character Range
| [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
| [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate
| blocks, FFFE, and FFFF. */
|
| The mechanism for encoding character code points into bit patterns may
| vary from entity to entity. All XML processors must accept the UTF-8
| and UTF-16 encodings of 10646; the mechanisms for signaling which of
| the two is in use, or for bringing other encodings into play, are
| discussed later, in 4.3.3 Character Encoding in Entities.
`----
Cela est spécifié dans la ligne NOTA juste avant le tableau vert en 1.1. Peut être l'avez vous lu trop rapidement. C'est pourquoi j'ai jugé utile d'ajouter un paragraphe dans le tableau
Effectivement, elle était bien cachée (avant le tableau).
Tiens, en relaisant, j'ai trouvé une autre erreur :
,---- | En parcourant les codes ISO-8859, ne perdez pas votre temps a chercher | la ligature `oe' utilisee en francais: elle n'y est pas. `----
Ben si, *elle y est*, dans iso-8859-15 :)
même base, y compris à alphabet "particulier" (cyrillique, chinois...) il suffit d'utiliser utf-8 (iso-10646) et d'utiliser une police adaptée.
Moins souple car pas encore très utilisé au seins des SGBDR... A déconseiller notamment pour XML !
C'est bizarre, ça, parceque la référence XML prévoit *expressément* le support de utf-8 *et* 16 :
(http://www.w3.org/TR/REC-xml#NT-Char)
,----[ Extensible Markup Language (XML) 1.0 (Second Edition) | W3C Recommendation 6 October 2000 ] | 2.2 Characters | | [Definition: A parsed entity contains text, a sequence of characters, | which may represent markup or character data.] [Definition: A | character is an atomic unit of text as specified by ISO/IEC 10646 | [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are | tab, carriage return, line feed, and the legal characters of Unicode | and ISO/IEC 10646. The versions of these standards cited in A.1 | Normative References were current at the time this document was | prepared. New characters may be added to these standards by amendments | or new editions. Consequently, XML processors must accept any | character in the range specified for Char. The use of "compatibility | characters", as defined in section 6.8 of [Unicode] (see also D21 in | section 3.6 of [Unicode3]), is discouraged.] | | Character Range | [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate | blocks, FFFE, and FFFF. */ | | The mechanism for encoding character code points into bit patterns may | vary from entity to entity. All XML processors must accept the UTF-8 | and UTF-16 encodings of 10646; the mechanisms for signaling which of | the two is in use, or for bringing other encodings into play, are | discussed later, in 4.3.3 Character Encoding in Entities. `----
