Jump to content

Présentation Michel et son projet


mayk901
 Share

Recommended Posts

Bonjour,

Pas vraiment novice avec FileMaker, ni vraiment novice en développement (web en particulier avec php et mysql), je viens solliciter votre aide pour un nouveau projet.
Je découvre la version 19 et j'aurai besoin d'en savoir plus sur le dimensionnement et l'approche qu'il vous plaira de me conseiller.

Il s'agit d'un projet de type ERP avec les particularités suivantes:
- ± 100 clients
- ± 500 factures/an et autant de commandes
- ± 1000 lignes de factures/an
- une centaine de clients
- ± 100 fournisseurs et ± 100 factures/an
Il y aurait 2-3 intervenants réguliers sur l'ERP pour l'encodage des commandes et plusieurs postes de validation (check box: c'est fait) dans le processus de fabrication.

Un premier développement a déjà eu lieu pour valider certains processus et vérifier si FileMaker pouvait répondre à l'ensemble de la demande.
A ce stade FileMaker semble pouvoir répondre à toutes les demandes.
Maintenant, ce qui coince c'est de choisir de gérer toutes les tables dans un même fichier ou plutôt une table par fichier.
Nous arrivons à mesurer certains avantages/inconvénients de l'un ou l'autre choix mais c'est quand même une inconnue du point de vue des indexations, d'un seul fichier qui serait endommagé, etc.

Et c'est là (sans se limiter) que nous espérons recevoir quelques précieux conseils de membres avisés😋.

Michel

Link to comment
Share on other sites

Bonjour,

il y a une heure, mayk901 a dit :

si FileMaker pouvait répondre à l'ensemble de la demande.

Surement ;)

 

il y a une heure, mayk901 a dit :

toutes les tables dans un même fichier ou plutôt une table par fichier.

Depuis plusieurs versions, on utilise plus ( moin )les fichiers séparer.

FM enregistre à tout moment (validation) Même, simplement, en sortent d'une rubrique, cela enregistre ce qui a été introduit.  CAD que le fichier est toujours à jour...

Le risque de perte dans ces conditions est presque nul.

Link to comment
Share on other sites

Bonjour Michel,

Je vais suivre ce sujet de près, je suis curieux de connaitre les réponses des experts FM sur ce sujet qui m'intéresse beaucoup !

il y a 41 minutes, mayk901 a dit :

Il y aurait 2-3 intervenants réguliers sur l'ERP pour l'encodage des commandes et plusieurs postes de validation

Il s'agit donc d'autres personnes qui vont, avec toi, travailler sur la(les) base(s) FileMaker si j'ai bien compris ?

Pour la question de gérer toutes les tables dans un même fichier ou plutôt une table par fichier, j'ai personnellement tendance à faire un compromis entre les deux :

• Mettre toutes ses tables dans un seul et même fichier à plusieurs désavantages :

  • On perd en clarté et en maintenabilité, à moins d'être ultra-précautionneux et organisé. Au fur et à mesure que le projet évolue, il est probable que le graphe des liens se transforme en plat de spaghetti, que nos tables contiennent 1500 rubriques, que l'espace de travail des scripts contienne plein de dossiers, dans des dossiers, dans des dossiers...
  • C'est difficile (impossible) de travailler à plusieurs sur la base de données d'un fichier unique. Il faudra attendre que l'autre administrateur ait terminé ses changements avant de pouvoir y accéder...

• Faire une table par fichier ne rend pas le tout plus maintenable à mon avis, et je pense même qu'on y perd en performances (propos à valider) car il va falloir inclure autant de sources de données que de tables...

Par contre, le compromis entre maintenabilité et performance, à mon avis, c'est de créer un fichier par module. Un exemple sera plus clair : J'ai une application de gestion toute simple (clients, factures, devis, etc.). J'ai besoin d'une nouvelle fonctionnalité de gestion de stocks et d'inventaire, mais c'est un peu lourd à intégrer. Je créé alors un nouveau fichier GestionStocks, dans lequel j'aurais tout ce qui est en rapport avec ma gestion des stocks (les tables, les scripts, les modèles...)

Si mon application de gestion à besoin d'accéder à des données de l'app GestionStocks, je n'ai qu'à l'intégrer dans les sources de données externes (fichier > gérer > sources de données externes) et j'y aurais accès hyper facilement (on peut créer des occurrences de ses tables dans le graphe, et donc ensuite utiliser les données dans les scripts, calculs...). L'inverse est identique.

De plus, si on est plusieurs à bosser sur l'application, je peux tout à fait bosser sur la base de donnée d'un fichier et un collègue sur la base d'un autre fichier. Ce n'est pas parfait, mais ça limite déjà l'inconvénient, je trouve.

Et enfin, on y gagne beaucoup en maintenabilité, puisque tout ce qui concerne mes stocks se trouve dans mon app GestionStocks. Disons que les choses se rangent naturellement et c'est plus simple :)

Si le travail en équipe est un critère important de ton projet, j'avais posé la question sur le dév FM en équipe il y a un an, et Fabrice m'avait donné quelques précieuses infos. Dommage, ce sujet n'est pas allé plus loin, j'avais encore plein de questions ^^

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...