Discussion :

[Maxence HUBICHE]

Une petite vidéo pour vous présenter l'une des nouveautés propres à Access 2010
Les Champs Calculés

Qu'en pensez-vous ?
Sondage et avis à remplir SVP !

[Domi2]

Bonjour,

Tout d'abord, bravo pour la vidéo !

Encore une nouveauté qui va bien simplifier l'utilisation d'Access.

L'écriture d'expressions de champs calculés dans les requêtes n'est pas toujours simple...

Domi2

[Tofalu]

J'ai voté non transcendant mais ... pour l'instant. A cause de :

la taille du fichier qui augmente considérablement,
du peu de gain de performance,
de la dé-normalisation de la base,
de l'impossibilité de faire appel à des fonctions VBA ou des macros-data
de l'impossibilité de faire appel aux fonctions de domaine,


Par contre, ça a le mérite d'exister mais à mon avis, ça doit être peaufiner.


Mais si on pouvait avoir des infos sur le comment c'est gérer dans la base de données, ça serait cool. Je n'ai pas non plus tester si c'était compatible avec des tables liées (externes). Par exemple, pas mal de fonctionnalités d'Access 2007 ne sont pas disponible lorsque les tables sont liées (frontale/dorsale)

[Invité]

Salut

Je suis comme Tofalu, qui nous avait fait une petite démonstration sur l'augmentation de la taille de la base et les performances.

Même si cela est un plus, il faut l'utiliser à mon avis avec Parcimonie.

@ Maxence : Pour la vidéo

Philippe

[Maxence HUBICHE]

Moi, je trouve que c'est sympa
Dénormalisation... mouais...

Enfin, c'est quand même supporté depuis très longtemps par des petits SGDBR comme SQLServer ! Et cela depuis... très très très longtemps !
Question taille... faut voir ce qui prend plus de taille :
Une table + une requête (qui a tourné, bien sûr)
Une table AVEC champs calculés.


Par contre, je râle à mort que les fonctions de regroupement de domaine ne soient pas prises en charge, ni même le SQL. Impossible de faire une sous-requête pour ces calculs. Ou alors, j'ai pas trouvé le truc !

Enfin, je rappelle que faire des tests de perf sur des technical preview c'est un peu casse gueule : on en a fait l'expérience avec la version précédente.

[Invité]

Bonsoir à tous
J'ai voté pas transcendant.
Je raisonne très égoïstement mais l'absence de ces champs calculés ne me gêne pas vraiment. Je mets donc cela dans le rayon des gadgets, au moins dans un premier temps. Quand les réserves soulevées par Tofalu seront levées, je changerai surement d'avis.

Par contre la Vidéo de Maxence

[Dolphy35]

Salut,



J'ai également voté rien de transcendant, seulement par manque concret

a tester avec la version final si comme dis plus haut ceci est facilement accessible et que cela ne demande pas trop de ressource sur des grandes tables.

Dolphy

[Tofalu]

Enfin, je rappelle que faire des tests de perf sur des technical preview c'est un peu casse gueule : on en a fait l'expérience avec la version précédente.

Oui, c'est pour ça que j'ai dit pour l'instant.

Espérant d'un coté que la différence de taille soit dû aux infos de tests et que l'absence des fonctions de regroupement ou du sql n'est qu'un oubli.

Dénormaliser, oui, quand cela apporte un réel plus au niveau des traitements ce qui aurait été le cas bien évidemment si les fonctions D* avaient été supportées. Mais là, dans le cadre d'une opération sur la même ligne, je ne voit pas bien l'intéret de dénormaliser.

[mout1234]

Salut à tous,

Malgré la belle vidéo plutôt alléchante - merci Maxence - j'ai voté 'Rien de transcendant' vu les limites évoquées (pas de SQL ni de VB...) mais bon... cela peut servir à l'occasion ... Je pense que cela sera beaucoup plus apprécié par des utilisateurs moins expérimentés qui bricolent leurs petites applis

[Jean-Philippe André]

bonne nouvelle selon moi, ca évitera d'avoir à expliquer aux utilisateurs comment s'y prendre dans les formulaires

[LE VIEUX]

Bonsoir,
Comme j’ai voté, je pense que je dois m’expliquer.
J’ai voté bonne nouvelle car j’ai trouvé que c’était un plus et qu’il est parfois intéressant d’avoir un champ calculé dans une table et que cela évitera des contournements.
D’autre part rien je nous oblige à les utiliser.
Par contre je ne comprends pas le problème avec SQL et fonction VBA ?
Je pense que l’on aura toujours possibilité d’utiliser un champ lamda habituel et d’y mettre la requête ou la fonction que l’on veut. Est-ce que je me trompe, ou j’ai mal compris, excusez c’est probablement l’âge….

[argyronet]

Bonjour,

C'est la mention "Trop nul ! On n'a pas besoin de ça !" qui m'a dissuadé de cocher cette option... Un peu trop avérée par sa définition.
Il ne faut pas exagérer.
Déjà qu'Access offre moulte méthodes en ce qui concerne les possibilités applicables (notamment dans les requêtes avec les fameux Forms![]...), je trouve que là, ils ont un peu poussé.
Bien que ce soit intéressant pour l'utilisateur pseudo concepteur de BDD, il s'avère selon moi que, considérant par exemple qu'une trop grande partie de nos chers développeurs négligent le couple optimisation/performance, que ce cadeau empoisonné ne va pas aller en améliorant ce point faible...

Merci en tout cas pour cette jolie démo, cher Max.

Argy

[Maxence HUBICHE]

Par contre je ne comprends pas le problème avec SQL et fonction VBA ?

En fait, il ne s'agit pas de fonction VBA (bien que...) mais de fonction Dxxx ou, si tu préfères xxxDom (SomDom, MoyDom, MaxDom, ...)
Ces fonctions et le SQL permettraient de renvoyer des résultats correspondant à des cumuls issus d'autres tables.
La limite qu'on trouve actuellement, c'est qu'il est seulement possible de faire des calculs sur la ligne en cours, avec les champs de la table en cours.
Donc, c'est limité.
Mais d'un autre côté, si on examine l'aspect "optimisation", il est certain que faire des sous-requêtes imbriquées dans les lignes d'une table, ou des fonction Dxxx, cela ralentirait sérieusement le rendu des données. Je pense donc que c'est un compromis très intéressant pour permettre aux utilisateurs d'Access d'avoir, au sein même de la table, des calculs qu'ils referont tout le temps !
Au lieu de faire une requête spécifique pour avoir ces calculs, et de faire toujours référence à cette requête, ils appellent directement la table, et basta !
Je trouve donc que c'est une bonne idée, même si on préfèrerait certainement pouvoir faire nos délires dans tous les sens ! il faut être raisonnables et penser aussi en terme de coût processeur et mémoire, et donc en terme de performances.

[LE VIEUX]

Bonjour et merci Maxence pour ta réponse.
Bon en fait j’avais pas compris que c’était dans ces champs calculés que tu regrettais l’absence de recours aux fonctions de domaine voire VBA.
Et donc j’étais étonné car en voyant ta très sympa vidéo, j’avais remarqué que, heureusement, les champs existants étaient toujours là, et que rien n’empêchait d’avoir recours à ceux-ci comme on le fait actuellement. OK on peut regretter cette limite, mais cela peut évoluer, NON ?.
Depuis office 95, j’ai en fait toujours apprécié les évolutions, et au temps où je maitrisais moins que maintenant je trouvais au contraire qu’ils pouvaient en faire un peu plus (ex : l’enregistreur de macro comme dans excel), même si j’en ai plus besoin, pour les gens qui débutent c’est toujours intéressant. Quand aux ressources, il faut effectivement attendre d’une part, et d’autre part le matos évolue également.

[Frank]

Bonjour à tous,

j'ai voté "Bonne nouvelle", mais je me demandais pourquoi le test avait été fait sur Access 2007 ?
Ou alors j'ai loupé quelque chose ?

[Chtulus]

Salut,

Merci @Maxence déjà pour la vidéo, je trouve ce moyen très ludique

Ensuite j'ai voté "Rien de transcendant" pour la même raison que argy !

2 choses me viennent directement en tête :

1/ On perd le côté SQL

2/ La plus importante pour moi (Et je poserai même pas la question à SQlpro LoooL), on ne met pas de champs calculés dans une table.....

Les requêtes sont faites pour ça !

Je pense aussi que cela va donner la possibilité à des utilisateurs amateurs de nous pondrent des calculs immondes qui risquent uniquement d'engendrer plus de soucis...

==> Pour les tables liées, si on garde Access/Access mouai, mais dès qu'on change de serveur comme par exemple SQLServer/Access je vois pas l'intérêt....

Bon j'arrête de dire des âneries

[Tofalu]

Bonjour à tous,

j'ai voté "Bonne nouvelle", mais je me demandais pourquoi le test avait été fait sur Access 2007 ?
Ou alors j'ai loupé quelque chose ?

Salut Frank

Le format de la base est sûrement 2007 mais il s'agit bien d'Access 2010, cf l'icône du menu Fichier

[pierre.serant]

J'ai voté bonne nouvelle

La Grosse utilité des champs calculés c'est a mon avis de pourvoir crée des clés de contrôle automatique liées aux données et pas à un contrôle dans un formulaire (pas de risque d'avoir un quasi doublon).
Pour moi c'est donc un plus mais uniquement s'il est possible de définir des fonctions complexes de calculs type (phonétique).
ou par exemple pour épurer des numéros de téléphone (txt en nombre).
De plus ce qu'il manque c'est la possibilité de pouvoir faire simplement des calculs (type Excel : decale -1) par rapport à la ligne d'avant (ou la ligne d'après)
par exemple pour un encodage kilométrique ou de consommations).

Pierre

[marmulay]

tout d'abod je vous remercie sur cette video tellement inéressante
puis je suis nouveau dans ce club et aussi en informatique et je vient de commencer la programmation avec vb de quoi vous me conseiller???