MsACCES - Possibilités, avenir ?
Bonjour à tous,
Salut {F1},
J'aimerais bien aller sur votre île (de France) !
Sachez que j'admire sans retenue la brillante synthèse que représente votre article publié le 15/10/2004. :ccool:
Coïncidence : La case à cocher pour sélection individuelle d'enregistrements sans point commun est la toute première fonctionnalité personnalisée que j'ai ajoutée, moi aussi, lorsque j'ai abordé le travail avec des formulaires dans MsACCESS !
Quant à votre dernier post, je m'empresse de le recopier dans ma collection d'arguments en sa faveur.
Cela fait toujours du bien d'avoir sous la main de quoi rabattre le caquet de ceux qui critiquent sans fondement.
Je n'y trouve pas de contradiction d'idées avec les miennes bien que j'aie utilisé le mot "béquille" qui n'était pas approprié.
(Cela dit, ôtez sa béquille à quelqu'un qui en a besoin : Il y a de fortes chances pour qu'il se retrouve par terre !)
Votre conception d'une architecture "composite" (ERP/MsACCESS) dès le départ me semble être une idée remarquable. :ccool:
Elle éviterait bien des errements, dus à la difficulté que représente pour les informaticiens de cerner correctement un besoin vu de l'extérieur.
Malgré toutes les méthodes d'analyse existantes, il leur faudrait ajouter à leurs compétences une vue "métier" que seuls les gens du milieu peuvent avoir, et qui leur permettrait de distinguer clairement le spécifique du "standard".
De leur côté, les gens du métier ne voient pas les choses d'un point de vue exploitable pour un informaticien.
D'où l'intérêt pour l'entreprise d'avoir recours à un informaticien attitré, voire de l'embaucher.
Vaste sujet !
Pour en revenir à la question posée au départ dans ce débat, elle me semble être un faux problème (ou plutôt un problème mal posé).
En revanche les réponses ainsi que le contenu de votre article ont l'immense mérite de recadrer une quantité impressionnante d'idées reçues et de notions de base (de données) mal assimilées !
Quant au possibilités offertes par MsACCES dans le prototypage, y compris celui de produits destinés à une architecture client/serveur, elles sont, comme vous l'avez si bien montré, quasi illimitées.
Mais il existe un prérequis à cela, qui est de connaître son outil sur le bout des doigts, comme un compositeur connaît son instrument, et de travailler dans les règles de l'art (en queue de pie au clavier).
L'élaboration de maquettes fonctionnelles, même sur une quantité relativement faible de données, fait immédiatement ressortir un défaut de structure.
Ces maquettes permettent de tester le comportement des éléments critiques, voire de les mettre en évidence s'ils n'avaient pas été considérés comme tels.
Ce serait trop bête de s'en priver !
A plus forte raison losqu'on sait qu'un client ou une entité cliente n'a pas nécessairement la clairvoyance requise pour préciser l'évolution d'un besoin : Savoir anticiper est précisément ce qu'on attend de l'analyste/informaticien.
À cet égard, MsACCES s'avère être aussi un outil de spécification au moyen d'un modèle éprouvé.
J'ai connu ce cas, toujours dans le spatial, pour un logiciel de gestion "qualité bord" :
Après quelques années de fonctionnement sous MsACCESS, la transposition vers un grand système, pour raisons de montée en charge, s'est effectuée en un temps record !
Économie, sécurité de retrouver un découpage pertinent de l'information, une structure fiable et des fonctionnalités bien rodées, que souhaiter de mieux ?
:twisted: Attention, vous risquez de lever un (gros) lièvre avec votre remarque à propos de MsEXCEL !
Très performant dans son domaine, on a souvent le tort de le "préférer" à MsACCESS pour "développer des bases de données" !!! (sic).
Peu d'usagers font la différence entre une gestion matricielle (cellules) et la gestion d'enregistrements (lignes) du moteur Jet.
Pourtant tout est là !
Il y aurait amplement matière à un autre débat !
Cordialement.
CRUSOE13
UNE QUETION QUE JE ME POSE
Bonjour !
J'ai réaliser des bases de données qui gére des entreprises la partie commerciale, les commandes la facturation, le stock, la caisse, le planning, les ordres de fabrication, les tarif fourisseurs etc.
Je ne comprend pas coment vous avez des bases de données dépassant 100 Mo puisque l'enssemble de mes base de donées remplie par les clients depuis plus de 10 ans ne dépasse pas 45 Mo, je ne parle que des données et je ne parle pas des tarif fournisseurs qui peuvent atteindre prés de 100 Mo chacune ni des fichiers WOrd, excel et autre qui peuvent atteindre 100 Go.
Pour moi un fichier prend trés peu de place dans la base de données puisque j'utilise son emplacement comme donnée.
Pour moi les tarifs fournisseurs sont des tables attachées chacune dans une base de données
Alors pour moi, ça me parait inconcevable même en ayant plusieurs centaine de mille de client avec 1000 octets par client ça fait 100Mo en effet, mais ce n'est pas la majorité des cas de base de données il me semble qu'Oracle serait plus adapé comme base de donnée, mais avant d'investir dans Oracle j'étudirais bien la question. Je n'investirerai pas sur MySQL pour de type d'application qu'il m'obligerait à programmer toutes les contraintes référentiel du type effacement en cascade ou suppresion non autorisée si des enregistrements connexe existe etc. Ou alors j'investirai dans SQL server.
Merci encore une fois de m'avoir lu
Client/serveur et Fichier
Bonjour à tous,
Je vous fais part de mes investigations dans le domaine ACCESS pour ou contre
L'aspect CLient/Serveur est un bon argument contre ACCESS, car ACCESS n'est pas Client/serveur, que veut dire Client/serveur ? Et bien ça veut dire qu'en mode client/serveur, votre base est sur le serveur et vous en tant que client allez interroger la base (1 requête), la requête va s'executer sur le serveur et à la fin va répondre (1 réponse).
Ce qui limite pas mal le flux de données sur le réseau. Alors que dans une base de type fichier comme ACCESS ou DBASE ou PARADOX ou FOXPRO ou MySQL, c'est le client qui va exécuter la requête, c'est à dire que le client va lire l'essemble des données nessecaire pour écécuter la requete puis en donner la réponse et cette réponse ne sera peut-être qu'un enregistrement et il aura fallut lire 100 ou 1000 ou 1 Million d'enregistrements.
En plus de ca ACCESS n'accepte pas d'étre transactionnelle, dans le sens client serveur, et ne dispose pas de Triggers ce qui fait qu'ACCESS est limitée en nombres d'utilisateurs et nessecite une rapidité en réseau importante.
Mais néanmoins, c'est un logiciel exellent pour un petit nombre d'utilisateur, ce qui ne veut pas dire pour pour une application simple, car mais même pour de trés grooses applications ACCESS peut faire l'affaire à condition d'étre peu nombreux à l'utiliser( au maximum 10 personnes)
au dela de 10 personnes, je vous conseille d'utiliser soit Oracle soit SQL serveur ou Sybase ou encore DB2.
:idea: si votre base est sur intenet alors là vous avez tout gagnez en ce qui concerne le trafic sur le réseau, puisque l'HTML est client serveur, mais coté dévellopement , il faudra tout refaire dans un autre langage comme ASP par exemple associé à du VBScript ou à du JavaScript.
Je vous remercie de votre attention
Access n'égalle pas performance
D'après moi, je ne sais pas si ca a été dit je n'avais pas 10 heures a passés sur ce sujet lol ma pause n'est que de 15 min alors je m'excuse si jamais je répète.
Access = SIMPLICITÉ
Access est très utile pour les newbie de l'informatique qui veule se créer une petite base de donnée rapidement et simplement. Dès que l'on parle de base de donnée importante (tant au niveau de l'importance des données que du nombre d'enregistrement) on doit voir autre chose.
Lorsqu'on est programmeur ou qu'on a une grande notion de programmation on ne choisit pas Access par choix (Moi jlai fais par obligation dans mon stage)(L'informatique est TRES mal géré ici hehe)