Discussion :

[Invité]

Bonjour

Je lis avec intérêt, et une phrase me choque :

j’écris tous les mots complets en français parfait, avec les accents. Si j’ai un doute, je fais appel au dictionnaire. L’intérêt, c’est que quand je veux retrouver le nom du champ, je n’ai pas à me souvenir de quelle manière j'ai bien pu l'écrire : je n'ai qu'à me rappeller de la manière
universelle de l’écrire ;

J'espère que tu n'écris pas le nom des champs de la même manière. Si tu ais obligé de migrer sur un autre type de base tu auras des soucis, car beaucoup ne prennent pas d'accents, et donc tout ton code sera à revoir.

Philippe

[jimbolion]

Philippe,

Je m'étais fait la même réflexion, n'ayant pas pour habitude d'utiliser les accents mais aucune contre-indication à l'usage des accents dans le nom des champs (du moins ce que j'ai pu rechercher sur le net).

Du fait, l'ébauche de Mumen permet au moins de se poser quelques bonnes questions.

Je participe également activement au chat, et je vais bien trouver réponse auprès des spécialistes.

JimBoLion

[Pierre Fauconnier]

Salut.

Intéressante discussion qui met DVP devant un problème souvent rencontré: les personnes qui posent des questions sur les forums lisent-elles nos ressources (faq, tutos, ...)?

Car la plupart des réponses s'y trouvent, sauf peut-être le principal, qui a trait à la conception de la base, à la structure des tables.

Donc, la question se pose à chaque tuto que l'on souhaite écrire: Que puis-je apporter de différent? Croire que l'on rédigera LE tuto qui répondra à toutes les questions des débutants est une chimère, à mon avis. La diversité des écrits sur le sujet en est la preuve. Néanmoins, un autre regard (pas LE regard, mais UN NOUVEAU regard) sur le sujet serait certainement pertinent.

Donc, rédiger un tuto, collaboratif ou personnel, sur ce sujet serait certainement une bonne chose. Il faudrait toutefois nuancer ou s'approprier formellement certaines lignes de conduite proposées dans le tutoriel pour que le lecteur n'y voit pas LA bonne méthode mais une méthode parmi d'autres:

• Noms de champs en français accentué, ce n'est pas le top question portabilité;
• Pas de clé primaire composite, pourquoi? Dans le cas où les clés externes peuvent composer des valeurs répétées, la clé primaire sur un champ s'impose bien évidemment, mais lorsque les clés externes doivent former une valeur unique, il me semble plus simple de créer une clé composite qu'un index composite unique, et si on préfère une clé primaire non composite, on devra quand même rechercher l'enregistrement sur base des clés externes.

Il faut aussi insister sur certains choix qui vont déterminer durablement la suite des opérations. A contrario de ce que pense Thierry, je pense aussi que la clé primaire, si non composite, doit être constituée d'un entier long auto-incrémenté. Pour les raisons que tu invoques, tout d'abord, et j'ai aussi été confronté à des changements de codification qui ont bien foutu la pagaille, et aussi parce qu'elles permettent de normaliser les liaisons clé primaire/clé étrangère. Plus besoin de se poser la question de la longueur d'une clé primaire avant de créer la clé étrangère. On sait que ce sont des entiers longs et on ne se casse pas la tête avec cela. Il est donc judicieux d'expliquer cela pour que chacun fasse son choix en connaissance de cause. Dire "il faut une clé primaire de tel type ou de tel autre" sans expliquer les avantages et inconvénients, ce n'est pas très didactique.

On en revient donc au début de ton propos, dans ton premier message: Tu veux faire simple, mais ne fais pas "trop simple". Sinon, ton écrit sera simplement un relevé de "tes" pratiques. On peut, et on doit, aborder Access de façon simple, mais pas de façon simpliste.

A ce stade, les éditeurs demandent en général une table des matières, un plan de rédaction. Pourrais-tu nous fournir cela? Car ce qui nous est donné est un peu mince pour se forger une opinion.

Dernière chose: Si le tuto a pour vocation d'être publié sur DVP, il ne faut pas trop se soucier de la mise en forme, mais bien structurer avec des titres, listes à puces ou autres... pour faciliter la mise au gabarit

[jimbolion]

A tous,

Donc et après discussion sur le Chat, les spécialistes en Base de Données déconseillent fortement l'utilisation des accents en argumentant la portabilité et la maintenance des systèmes.
Les traitements natifs s'opèrent sur l'ensemble des transactions en UTF-8 et simplifient les process liés à la génération de fichiers XML, HTML...
Je n'entrerai pas dans ce débat, arguant les compétences des spécialistes.

Une lecture intéressante résumant les quelques questions précédemment soulevées :

http://www.info-3000.com/access/cour...03/lecon03.php

Le sujet date un peu je le concède, mais la réflexion est toutefois assez fidèle à la façon que j'ai de normaliser mes entités. (Peut-être de la vielle école).

Il n'en reste pas moins acquis que la réflexion de chacun permet d'avancer sur le sujet, et que Mumen saura intégrer à son document les différentes remarques (vérifiées, amendées, validées) que nous lui soumettrons.

JimBoLion

[Pierre Fauconnier]

[...]Une lecture intéressante résumant les quelques questions précédemment soulevées :

http://www.info-3000.com/access/cour...03/lecon03.php

Le sujet date un peu je le concède, mais la réflexion est toutefois assez fidèle à la façon que j'ai de normaliser mes entités. (Peut-être de la vielle école).

Il n'en reste pas moins acquis que la réflexion de chacun permet d'avancer sur le sujet, et que Mumen saura intégrer à son document les différentes remarques (vérifiées, amendées, validées) que nous lui soumettrons.

JimBoLion

En ce qui concerne le tuto renseigné, il y a lieu de bien vérifier ce qui est écrit dedans, car au delà d'une normalisation qui est finalement très personnelle, il y a des imprécisions, voire des erreurs manifestes (taille des champs texte qui prennent de la place pour rien), et des exemples malheureux concernant justement la conception de la structure (cas des animaux, par exemple).

[jimbolion]

Pierre,

Ma réflexion supposée du moment portait plus sur les règles de nommage que sur le contenu.

Il va sans dire que l'analyse du contenu (typages, longueurs...) feront l'oeuvre d'une attention particulière.

Merci en tout cas de ton apport

JimBoLion

[mumen]

Bonjour à tous, et merci de vos retours

Belle moisson.

Je suis globalement en accord avec tous les points relevés, j'entrerai dans le détail ultérieurement. Il y a deux sujets qui font débat et qui me touchent. Comme c'est dimanche, j'en resterai à ça !

Ce tuto, s'adresse à une frange. Je suis explicite là-dessus. La clé primaire que je conseillerai sera la numéro auto, en laissant la porte ouverte et en justifiant ce choix (la relation, c'est assez compliqué comme ça, pour en rajouter, c'est d'ailleurs mon choix de développeur). D'un point de vue technique, Pierre à d'excellents arguments là-dessus.

[...]des changements de codification qui ont bien foutu la pagaille, et aussi parce qu'elles permettent de normaliser les liaisons clé primaire/clé étrangère. Plus besoin de se poser la question de la longueur d'une clé primaire avant de créer la clé étrangère. On sait que ce sont des entiers longs et on ne se casse pas la tête avec cela.

En résumé, à chacun son métier : l'analyste analyse, le programmeur programme. Moi, je suis programmeur et je respecte hautement le métier d'analyste. Mais ce n'est pas pour une élégance qui ne produit finalement qu'une incertaine optimisation matérielle que quelqu'un viendra me compliquer la vie. Je suis dans le concret, la belle abstraction a ses limites. La métaphore qui convient ici est champêtre : "à chacun son métier et les vaches seront bien gardées" ! Que le programmeur ait sa clé primaire normalisée, que l'analyste ait tous les index qu'il veut et les logiciels seront fiables et maintenables !

Pour le sujet qui nous intéresse, le tuto, je pense le débat inutile et même contre-productif aussi bien pour la rédaction que pour le lectorat.




Concernant les accents, je ne tombe pas du ciel, mais je me désole de cette limitation résiduelle, que je n'ai pas accepté de m'imposer en développement. Je considère ce problème comme un "détail" technique, parce que je sais faire du renommage global au sein de mes applications : j'ai fait l'outil, tout simplement. J'ai même déjà prévu de longue date de programmer le jour venu, des directives de renommage dans la définition de la structure pour la garantir sans répéter le travail au moment de l'application réelle de la série de renommages.

Dans les faits, je n'ai jamais migré une de mes applications Jet sur un moteur client/serveur. Il y a un saut quantique entre les deux et je connais ma place. On ne parle que de ce cas-là : la migration d'une application existante sur un autre moteur qui n'accepterait pas les accents. Enfin, il est évident que si, demain je commençais un développement de type maquette pour un moteur sans accents, ma structure sera faite sans accents. Donc pour moi, ce n'est pas un problème.

Concernant la cible des lecteurs du tuto, ils ne savent même pas qu'ils utilisent un moteur et que cela peut se choisir. Ils ne le sauront que le jour où leur développement sur un coin de table sera soumis à des tests de scalabilité... Ce qui est une probabilité totalement disproportionnée à l'objet du tuto.

Leur problème type concerne une structure à trois tables, pour cinq postes dans l'entreprise, c'est leur apprentissage. Je pense qu'il est utile de les inciter à correctement écrire leurs noms d'entités avec toute la richesse orthographique à leur disposition et qu'il serait plus que navrant de leur mettre en tête la régression qui imposerait de ne pas mettre d'accents dans leurs noms d'entités, simplement parce que, peut être, un jour, s'ils deviennent des pro, etc. C'est le débat de l'ancienne école avec ses champs sur huit caractères. En fait, je pense enlever cette référence à l'ancienne école de nommage du tuto parce qu'il a besoin d'aller à l'essentiel.

Selon moi, le seul point de discussion au sujet des accents, c'est de savoir s'il faut leur dire, ou non. Pour moi, c'est non.

Mais je ne vais pas l'intention de m'arc-bouter sur ce sujet. Si le consensus est de ne pas mettre d'accents, alors ok.


Pour contenter tout le monde et parce que c'est juste, je pense mettre en introduction un passage qui dirait : "Certains choix ont été faits pour vous qui ne seront pas argumentés ici, mais auxquels vous serez forcément confrontés si vous continuez à développer."

[Dolphy35]

Bonjour,

Je n'ai pas tout lu mais je constate que l'on parle beaucoup d'accent dans le code. Pour ma part quitte à faire des articles orientés débutant autant donner des bonnes règles et habitude dès le début. Une fois les choses ancrés, c'est compliqué de changer et surtout que cela amène des erreurs potentiels de code.
Pour moi la typographie est le plus importants dans la clarté du code que des commentaires qui , des fois, ne servent à rien.

Pour lancer un débutant dans la marre je pense que le tuto suivant est primordial http://argyronet.developpez.com/office/vba/convention/

@+

[mumen]

"Ils viennent avec des usines à gaz et ils sont bloqués." Je n'ai pas l'intention de leur faire un cours magistral, mais de les débloquer.


Je pense être en accord avec Pierre Fauconnier pour tout ce qu'il dit.

les personnes qui posent des questions sur les forums lisent-elles nos ressources (faq, tutos, ...)?

Malheureusement, question ultrapertinente. C'est un autre sujet sur lequel je dirai ma vision une autre fois.

Car la plupart des réponses s'y trouvent, sauf peut-être le principal, qui a trait à la conception de la base, à la structure des tables.

Cela confirme ce que je supposais. Mais qu'il soit clair que ce n'est pas mon ambition de combler cette lacune dans le cadre de ce cours. J'espère apporter UN NOUVEAU regard, avec MA méthode quand il faut bien faire un choix. Toujours expliquer ce choix fait partie du cours. Mon objectif est qu'ils comprennent chacun de ces choix, avec leur vocabulaire pauvre en technicité.

Noms de champs en français accentué, ce n'est pas le top question portabilité;

Il y a plus grave comme problème. Néanmoins, je le mentionnerai explicitement. Cela fait partie de MA méthode.

Clés primaires normalisées. Pas de clé primaire composite. Pas de clé primaire publique. MA méthode. Je dirai qu'autre chose existe, sans m'étendre. Je dois absolument être économe en notions.

On en revient donc au début de ton propos, dans ton premier message: Tu veux faire simple, mais ne fais pas "trop simple". Sinon, ton écrit sera simplement un relevé de "tes" pratiques. On peut, et on doit, aborder Access de façon simple, mais pas de façon simpliste.

Entièrement d'accord. J'appelle ça un exercice de style. Je ne suis pas certain d'y parvenir. Nous saurons si c'est réussi quand des utilisateurs type que je décris en introduction l'auront exprimé.

A ce stade, les éditeurs demandent en général une table des matières, un plan de rédaction. Pourrais-tu nous fournir cela? Car ce qui nous est donné est un peu mince pour se forger une opinion.

Là, j'ai besoin d'aide, je ne sais pas faire. Concernant le plan, ce que j'ai donné est plus de la moitié du produit fini, moins les réécritures, selon mes (pauvres) critères.

Dernière chose: Si le tuto a pour vocation d'être publié sur DVP, il ne faut pas trop se soucier de la mise en forme, mais bien structurer avec des titres, listes à puces ou autres... pour faciliter la mise au gabarit

On est d'accord. Je pense réaliser la gabarisation moi même sur le forum qui va bien. Cela fait partie du jeu.

[mumen]

Bonjour Dolphy

Pour lancer un débutant dans la marre je pense que le tuto suivant est primordial

Ce tuto est plutôt à relire pour moi, avant de rédiger mon cours.

Même si le lien est évident, dans ce cours je ne parle pas encore de VB. Si je réussis quelque chose de bien avec ce cours, j'aimerais bien leur expliquer, à ces mêmes débutants un peu plus affirmés, comment coder proprement en VB (nommer, indenter, blocs With, etc.). Il y a la même problématique de l'usine à gaz qui se reproduit à ce niveau.

Pour moi la typographie est le plus importants dans la clarté du code que des commentaires qui , des fois, ne servent à rien.

Nous sommes donc à la même école.


Mon "client" vient pour la première fois, il a un problème. Il doit découvrir tout d'un coup. Comment marche le site, comment parler aux gens, comment expliquer son problème, quel vocabulaire, etc.

Si on lui balance directement et avec laconisme des liens techniques rébarbatifs comme celui là, cela ne fait que grandir brutalement la montagne qu'il doit gravir, sans comprendre ou on l'emmène. Je montrerai volontiers ce type de lien à la fin du cours, en disant quelque chose comme "pour les courageux, etc." et non pas "Il faut que, etc.".

Je crois que toute la problématique de lisibilité des tutos vient de cet enchaînement doux qui n'est jamais réalisé. Comme si on passait brutalement de la plaine à l'Alpe.

[Pierre Fauconnier]

Dans ton pdf, tu dis ceci

Une entité, c’est un terme générique pour désigner aussi bien une table en général qu’un champ ou une
relation

Ce n'est pas exact. Un champ n'est pas une entité, et une relation non plus. L'entité, c'est ce qui est géré au sein de la table.

Ainsi, on parle de l'entité Contact, de l'entité Facture. Chaque entité sera définie par des données la concernant. Les données de l'entité Contact définiront complètement mais exclusivement cette entité.

Matérialisés dans un SGBD, ces notions prennent le nom de table (entité) et de champ (donnée). C'est d'ailleurs par abus de langage qu'Access parle de champs lors de la conception d'une table, car il s'agit en fait de colonnes.

Je pense que même animé de la volonté de faire simple, il faut au moins, même si tu ne veux pas utiliser le langage professionnel, ne pas utiliser une mauvaise terminologie, car les débutants qui te liront ne pourront faire la jonction entre tes propos et les autres lectures qu'ils aborderont, ici ou ailleurs.

Que dans Access, on parle de champ, soit. Mais une relation est une relation et ni le champ ni la relation ne sont des entités.

Comme je le disais plus haut: Faire simple, oui. Faire simpliste, non.

[Invité]

Je crois que toute la problématique de lisibilité des tutos vient de cet enchaînement doux qui n'est jamais réalisé. Comme si on passait brutalement de la plaine à l'Alpe.

Bonsoir
Je ne suis pas d'accord avec cela. Primo il existe déjà pas mal de tutos très accessibles et deuxio; moi qui suit toujours un débutant, je pense que la progression ne se fait pas de manière linéaire mais par palier. Et ces paliers bien souvent, sont à la fois une remise en cause de ce que l'on a fait et une marche supplémentaire à franchir sur un sujet précis .
Un débutant souvent va partir bille en tête et se servir de tous les assistants pour réaliser ce qui lui est demandé. Et bien souvent il va y arriver.. Certes par des chemins pas très catholiques et en contradiction avec les règles établies. Ce n'est pas grave si les tables sont mal nommées, s'il manque des relations, s'il y a de multiples requêtes etc...ça marche et il est tout fier. Bon nombre de ceux qui viennent sur le forum sont des occasionnels qui ne referont pratiquement jamais de base Access.

Après, s'il continue, il va découvrir l'existence des macros, et se faire les dents la dessus.
Après éventuellement il passera au Vba et puis après....
Mais les erreurs de nommage, de clés, de relations, de conception c'est quand il aura un gros problème, qu'il fera éventuellement l'effort de se remettre en cause. De toute façon, il le fera au fur et à mesure de ses besoins.
D'autre part, avec un minimum de recherche bien des points évoqués sont déjà abordés. On parle de conception de tables: que je sache, c'est quelque chose d'assez universel, alors rendez vous sur le forum des bases de données...
Le lien mentionné par Dolphy ne fait pas référence qu'à Vba, il parle également dans le chapitre 7 des conventions de nommage des champs.

Alors oui, il y a encore beaucoup de choses à expliquer, structurer, compléter et modifier. Mais pour être très franc, je n'aime pas cette façon de sous-entendre que tout ce qui existe est mal fait ou n'existe pas (faute de recherche). Des phrases de ce genre

Pour le sujet qui nous intéresse, le tuto, je pense le débat inutile et même contre-productif aussi bien pour la rédaction que pour le lectorat.

me laissent également perplexe.

Tout ceci pour dire que je suis tout à fait d'accord avec le fait de proposer un tutoriel, mais il faut qu'il soit en cohérence avec ce qui est fait et il ne faut pas considérer que seule "TA" méthode est la bonne.

Désolé d'être franc, j'espère sincèrement que tu feras un beau tuto...

[f-leb]

Bonsoir à tous,

Je fais tous mes dévs avec des numéroautos, uniquement des numéros auto. Ils feront leur premier dév avec des NuméroAuto.

ça me semble radical...

A moins que le schéma à 3 tables que tu proposes de faire ne comporte que des associations "un à plusieurs", il y a tout de même le cas de l'association "plusieurs à plusieurs" qui génère une table dont la clé primaire composite est constituée des clés des tables associées.
On ne va tout de même pas jeter aux orties la fameuse table associative (#idCommande, #idProduit, quantité).

On peut dans certaines occasions aller vers LigneCommande(idLigneCommande(numéro Auto), #idCommande, #idProduit, quantité) en rajoutant cet index supplémentaire idLigneCommande mais cela doit pouvoir se justifier, un index en plus ça à un coût.
Exemple de justification: si la ligne de commande peut faire l'objet de plusieurs livraisons: LigneCommande-1------*-Livraison (conceptuellement, on transforme l'association (Commander produit) en entité [LigneCommande]).

Sur le vocabulaire: définitions en usage dans l'univers des SGBDR et du SQL.
et on s’aperçoit que le terme "entité" est déjà employé dans le contexte de la modélisation conceptuelle (MCD, schéma "entité-association", etc.)

Concernant le vocabulaire Access un peu particulier par rapport aux standards des SGBD, je m'en étais sorti avec la pirouette suivante :

http://f-leb.developpez.com/tutoriel.../#noteBasPage3]
L'usage dans l'univers des SGBDR et le langage SQL va dans le sens de l'utilisation des termes Colonne et Ligne en remplacement de Champ et Enregistrement (« les champs sont à la campagne ou dans les formulaires » comme aime à le rappeler CinePhil). Les termes Ligne et Colonne sont d'ailleurs appropriés à la représentation tabulaire des tables en mode « feuille de données » mais Microsoft en a décidé autrement pour Access. En conséquence, nous continuerons d'utiliser Champ puis Enregistrement dans cet article, conformément aux usages dans l'univers Access.

[Jeannot45]

De nouveau dans les couloirs de DVP, je viens de lire rapidement le fil.
Je suis quand même assez surpris de voir que les tutos de Maxence Hubiche permettant de faire les premiers pas sous Access, ont été oubliés :

Access - Les Bases
Comprendre les jointures dans Access

[mumen]

Bonjour Jeannot

Bien vu. Je les avais déjà vu passer. Je vais les lire posément.

Au premier abord, il n'y a pas de contre-indication avec ce que je veux faire, mon désir n'étant pas d'être exhaustif, mais de dépanner des gens. C'est une approche différente et complémentaire.

Il est plus que probable que ces liens seront mis dans la conclusion. En fait je les attendais sans me l'exprimer, merci.

[alassanediakite]

Salut à vous.
Pour ce qui est des accents: j'explique aux débutants qu'il faut les éviter puis je donne la BD exemple Northwind de MICROSOFT pour nos tests; imaginez les yeux des ces débutants
Concernant "champ", "colonne", "ligne"... quelles étaient les expressions utilisées par nos prédécesseurs (qui ont vue les modèles hiérarchique, réseau, relationnel, objet)?
Ne me dite pas que colonne est un terme du modèle relationnel! Non il ne l'est pas! Le modèle relationnel utilise "domaine" ou "attribut".
Si "champ" est à la campagne, je peux aussi dire que "colonne" et "ligne" sont dans EXCEL!
Pour ce point, je pense qu'il faut juste dire aux débutants (pourquoi pas aux experts) que CE SONT DES SYNONYMES.
Pour revenir au sujet, sincèrement je pense qu'il faut juste enrichir le FAQ.
@+