Discussion :

[makimax]

Bonjour,
je souhaite faire un CRUD pour une pseudo gestion électronique documentaire.
Je souhaite ajouter des lignes correspondant à des documents, préciser leur type, par exemple NOTICE, SCHEMA, PLAN, PROGRAMME et que le système me nomme le document lors de son import selon une régle que je souhaite être préfixe + incrément.

Exemples
1 : document NOTICE (donc de doctype_id 1) donc son nom sera NO000001
2 : document PLAN (donc de doctype_id 3) donc son nom sera PL000001
3 : document NOTICE (donc de doctype_id 1) donc son nom sera NO000002
4 : document SCHEMA (donc de doctype_id 2) donc son nom sera SC000001
5 : document NOTICE (donc de doctype_id 1) donc son nom sera NO000003

Dois je faire une table "doctypes" et une table "documents" avec tous les documents et donc pour le nom je devrais trouver le dernier nom d'un document du même type puis le découper et incrémenter ensuite afin de bien avoir le numéro suivant.
ou dois-je faire une table par type, donc une table notice, une autre schema, etc. Dans cette solution c'est plus clair et plus simple pour le nom qui est finalement en lien avec l'id.

A savoir que je souhaite afficher un tableau de l'ensemble des documents avec des filtre et liens vers les fichiers. Dans le cas de tables par type, il faudra des requêtes imbriquées et même revoir la requête lors de l'ajout d'un nouveau type à l'avenir, ce qui n'est pas le cas avec une table unique.

Avez vous des conseils s'il vous plaît. Je n'ai pas d'expérience, juste quelques notions.
Merci de votre aide.

[escartefigue]

Bonjour,

Le nombre et la structure des tables dépend de leur contenu.
Si plusieurs types de documents partagent les mêmes attributs, alors ils peuvent être hébergés dans une même structure, si au contraire des documents ont des attributs spécifiques, alors une structure propre est requise.
On peut éventuellement utiliser l'héritage pour mutualiser ce qui est commun à plusieurs types.

Ensuite, l'identifiant de chaque document ne doit surtout pas être affublé de contraintes liées à son contenu, un identifiant doit être dénué de sens pour en garantir la stabilité.
Donc, utilisez des chronos techniques tels que ceux attribués par le SGBD (auto_increment dans le cas de MySQL), ils seront stables et bien plus performants que des identifiants alphanumériques.
Il sera très facile de concaténer une constante "NO", "PL", "SC" ou autre à un chrono lors de la restitution si besoin

[makimax]

Bonjour,
... un identifiant doit être dénué de sens pour en garantir la stabilité.
Donc, utilisez des chronos techniques tels que ceux attribués par le SGBD (auto_increment dans le cas de MySQL), ils seront stables et bien plus performants que des identifiants alphanumériques.
Il sera très facile de concaténer une constante "NO", "PL", "SC" ou autre à un chrono lors de la restitution si besoin

Vous voulez dire que les documents devraient avoir leur noms gérés dans le PHP à la récupération de l'ID ou d'un autre paramètre auto incremental par exemple.

mais dans cet exemple initial si j'utilise l'ID en identifiant que je concatène avec l'abbrégé du type de en préfixe, cela fait des 'trous' dans l'incrémentation des documents par type. Pas forcément gênant mais j'aimerait bien ne pas en avoir car en allant dans le répertoire où il seront stockés, on visualise rapidement l'absence d'un fichier.

doc_id (A.I)	doc_doctype_id	mise en forme après restitution
1	1	NO000001
2	3	PL000002
3	1	NO000003
4	2	SC000004
5	1	NO000005

Ou alors il faut incrémenter un identifiant autre que l'ID après avoir analysé son type :

doc_id (A.I)	doc_doctype_id	doc_identifiant	mise en forme après restitution
1	1	1	NO000001
2	3	1	PL000001
3	1	2	NO000002
4	2	1	SC000001
5	1	3	NO000003

Je sais bien que l'idéal serait même de ne pas avoir de préfixe, utiliser par exemple simplement l'ID ou un aléatoire, ou une base temps.

[Artemus24]

Salut à tous.

@ Makimax : il faut toujours aller au plus simple et ne pas chercher à résoudre un problème qui n'est que fonctionnelle par un aspect technique qui va vous compliquer l'existence, surtout en terme de performance. L'identifiant de vos documents doit être une colonne numérique de type incrément. Et surtout pas d'identifiants alphanumériques !!!

Les trous n'ont aucune importance dans la gestion de vos identifiants.

Pas forcément gênant mais j'aimerais bien ne pas en avoir car en allant dans le répertoire où il seront stockés, on visualise rapidement l'absence d'un fichier.

Ce que vous dites n'est pas possible car l'affectation de l'identifiant numérique va se faire lors de la création de votre document dans la base de données. A moins que délibérément vos documents peuvent être détruits. Le mieux est de protéger vos documents en les mettant dans un répertoire qui n'est qu'accessible uniquement en lecture. Dans le cas contraire, vous risquez de vous retrouver avec des identifiants qui pointent sur des documents inexistants.

Je sais bien que l'idéal serait même de ne pas avoir de préfixe, utiliser par exemple simplement l'ID ou un aléatoire, ou une base temps.

Pourquoi ne pas procéder ainsi ?

On peut éventuellement utiliser l'héritage pour mutualiser ce qui est commun à plusieurs types.

C'est une bonne idée et ainsi il aura un identifiant de type auto incrémenté par type de document.

Coté PHP, il suffit de convertir votre préfixe afin de trouver la table correspondant au document et d'accéder uniquement avec l'incrément. Cette solution est acceptable à la condition de ne pas avoir trop de type de documents différents (<10).

@+

[escartefigue]

Si l'on veut absolument avoir des numéros contigus, sans trou de numérotation (comme c'est le cas pour les factures), alors il faut utiliser un chrono distinct de celui attribué par le SGBD.
En effet, les identifiants attribués par le SGBD peuvent sauter certaines valeurs dans certains cas (incrément > 1, arrêt relance d'un serveur, ligne non commitée...)
On aura donc d'une part un identifiant technique, unique et PK, mais présentant des "trous" potentiel et d'autre part un chrono fonctionnel.

Pour ce chrono fonctionnel, il faut utiliser une table contenant la dernière valeur utilisée et qu'on incrémentera à chaque utilisation commitée

Exemple de solution possible :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
create table YD_TYPE_DOC
      (  YD_ident    integer      auto_increment  primary key
       , YD_code     char(4)      not null        unique
       , YD_libelle  varchar(50)  not null
      )
;
insert into YD_TYPE_DOC (YD_code, YD_libelle)
values ('NOTC', 'Notice')
     , ('PLAN', 'Plan')
     , ('SCHM', 'Schéma')
;    
create table TC_TABL_CHRONO
      (  TC_table    char(20)     not null
       , TC_colonne  char(20)     not null
       , TC_chrono   integer      not null
       , primary key (TC_table, TC_colonne)
      )
;
insert into TC_TABL_CHRONO(TC_table, TC_colonne, TC_chrono)
values ('DO_DOCUMENT', 'DO_numero', 0)
;
create table DO_DOCUMENT
      (  DO_ident    integer      auto_increment  primary key
       , DO_numero   integer      not null        unique
       , DO_titre    varchar(50)  not null 
       , DO_date     date         not null
       , YD_ident    integer      not null
       , constraint DOFK01 
         foreign key(YD_ident)
         references YD_TYPE_DOC(YD_ident)
         on delete restrict on update cascade
      )
;
update TC_TABL_CHRONO
set TC_chrono = TC_chrono + 1
where TC_table   = 'DO_DOCUMENT'
  and TC_colonne = 'DO_numero'
;
-- insertion d'un document de type "notice" dans la table des documents
insert into DO_DOCUMENT (DO_numero, DO_titre, DO_date, YD_ident)
values (  (select max(TC_chrono)
          from TC_TABL_CHRONO
          where TC_table   = 'DO_DOCUMENT'
            and TC_colonne = 'DO_numero')
        , 'mon document'
        , current_date()
        , (select YD_ident
           from YD_TYPE_DOC
           where YD_code = 'NOTC')
       )
;  
commit
;
update TC_TABL_CHRONO
set TC_chrono = TC_chrono + 1
where TC_table   = 'DO_DOCUMENT'
  and TC_colonne = 'DO_numero'
;
-- insertion d'un document de type "plan" dans la table des documents
insert into DO_DOCUMENT (DO_numero, DO_titre, DO_date, YD_ident)
values (  (select max(TC_chrono)
          from TC_TABL_CHRONO
          where TC_table   = 'DO_DOCUMENT'
            and TC_colonne = 'DO_numero')
        , 'mon plan'
        , current_date()
        , (select YD_ident
           from YD_TYPE_DOC
           where YD_code = 'PLAN')
       )
;  
commit
;
select * from DO_DOCUMENT
;

Résultat :




DB fiddle ICI


Le point important est de bien "commiter" l'insertion dans la table des documents et la mise à jour de la table des chronos dans la même transaction.
Pour la table des chronos, on adoptera un verrouillage de niveau ligne, ainsi, si d'autres tables ont un chrono à gérer dans la table des chronos, les différentes transactions ne se gêneront pas
Si l'on veut un chrono unique par type de document, alors il suffit d'ajouter le type de document dans la PK de la table chrono

[SQLpro]

Le problème du chrono fonctionnel c'est que le numéro attribués ne sont pas stable.... par exemple si l'on a ajouter un document qui après quelques jours s'avère faux, on le supprimera et donc les documents créées après devront être renumérotés... Mais si madame Michu a obtenu ce document entre temps, elle va se référer à l'ancien numéro... Et le merdier est indémerdable !

A +

[escartefigue]

Dans ce cas d'espèces, il faut faire comme pour les factures : s'interdire la suppression de tout numéro, on joue sur une colonne statut qui prend une valeur signifiant "annulé" ou "invalidé" accompagné d'un horodatage ce qui permet de répondre à Mme Michu que ce numéro n'est plus valide depuis le ...

[Artemus24]

@ SQLPRO : je ne vois pas pourquoi il faudrait renuméroté les identifiants.
On peut ne pas supprimer les identifiants qui ne servent plus mais juste indiquer leur indisponibilité comme le suggère Escartefigue.

Ce n'est pas une bonne pratique de venir boucher les trous. Dans le domaine bancaire, un compte qui est clôturé l'est définitivement.
Si le même client demande le même type de compte, il aura un nouveau compte, avec un nouveau numéro d'identifiant.
En procédant ainsi, cela crée moins de problème.

@ tous : Je ne comprends pas trop la volonté de Makimax d'utiliser un identifiant composé d'un préfixe déterminant le type de document et d'un incrément.
A la limite, mettre tous les documents du même type dans une même table. D'où l'héritage.
Et demander sous PHP, quel est le type de documents afin de déterminer la table où est stocké ce dit document.
Les trous sont un faux problème qui n'a pas lieu d'être.

Et au lieu de mettre des incréments, pourquoi ne pas utiliser un horodatage composé de la date et de l'heure ?

[makimax]

Merci à vous pour vos réponses, je ne comprends pas tout car cela n'est pas mon domaine, je cherche à faire une maquette avec le peu de compétences que 'j'ai.
@Artemus24 : Clairement oui ce serait plus simple d'avoir un horodatage ou aléatoire mais unique. Si je cherche une solution à préfixe+numéro c'est parce qu'aujourd'hui notre ERP est ainsi (Devis DVxxxxxx, Ordre d'achat OAxxxxxx, Commande client CCxxxxxx, Ordre de fabrication OFxxxxxx, ...

Je sort du cadre "developpement" en expliquant le pourquoi :
De mon côté je réalise des schémas de principe, des plans via CAO 2D/3D, des notices utilisateur ou notice interne d'assemblage, des programmes d'automates ou écran tactiles et aujourd'hui tout ces documents sont créer manuellement, nommer sans vrai règle, et stocker dans le répertoire de leur projet respectif, ceci par l'explorateur Windows sur le serveur. Actuellement je met le code projet en préfixe car il m'est interdit d'avoir 2 fois le même nom de fichier (à bannir en CAO) Par exemple PRJ123-PL00001.pdf

Mon idée est de toujours continuer à garder les sources ainsi, dans le répertoire projet, mais avec une règle de nommage définie par ce module (celle qui fait débat ici du coup ^^). Le formulaire me proposerait d'uploader le fichier neutre du même nom (donc en pdf ou zip) et le transfert dans un répertoire du serveur accessible en terme de droits pour mes collègues. Ainsi ce répertoire ne changeant pas de nom ou d'emplacement contrairement à mes répertoires projets où sont les sources, peu de risque de perdre le lien.
Mes collègues pourraient donc utiliser cette maquette avec la datatable que je ferai en php (ou essaierai en tout cas) et des outils de recherches pour trouver leur document par une recherche de nom, type, article associé, mot clé, ... et je pourrait aussi gérer les révisions.
Je n'ai jamais pratiqué de Gestion Electronique Documentaire GED mais j'imagine que c'est ca en mieux. L'outil idéal pour mon cas est un PDM / PLM mais malheureusement ce n'est pas d'actualité et un budget colossal à 5 chiffres :-(

Une règle de type PL000001, SC000956, NO000546 permet juste d'être plus parlant lorsqu'on est dans le répertoire projet comme aujourd'hui par explorer, sans l'outil de recherche, sans base de données. Il faut s'imaginer que cette maquette n'aura peut-être aucun succès et je ne veut pas me retrouver avec des fichiers qui ont un nom "aléatoire unique" mais oui, je suis d'accord qu'avec un outil de GED c'est mieux. Je suis preneur de tout conseil, c'est toujours constructif.

[Artemus24]

Le gros de ton problème est de passer, on va dire du nom fonctionnel de tes documents au stockage technique dans la base de données.
L'idée est d'utiliser deux méthodes de classifications qui n'ont aucune relation entre elles.
La première méthode est celle que tu utilises pour numéroter tes documents et de les ranger dans les bons répertoires.
La deuxième méthode est celle connue des utilisateurs.
Et bien sûr, c'est la base de données qui va faire le lien entre les deux méthodes.
Du coup, plus aucune contrainte.

Par exemple PRJ123-PL00001.pdf

Je suppose que "PRJ" est un code d'identification du projet.
Et "123", son identifiant, voire son numéro de version.
De même "PL" est le type de document.
Et "0001" le numéro du classement du document que tu utilises dans ton logiciel ERP.

En gros, il te faut quatre tables.

a) Table des projets.
--> Un identifiant de type numérique incrémenté qui sera unique dans la table "projet".
--> Une colonne "libellé" contenant tes codes du genre "PRJ" ou autre chose.
Ainsi tu peux modifier ce libellé sans revoir de font en comble la numérotation de tes projets dans la base de données.
Si "PRJ" devient "DEV", tu modifies juste le libellé, mais l'identifiant reste le même.

b) une table des versions.
La clef primaire sera composée d'un incrément unique.
Dans ta table des versions, tu auras :
--> Une clef étrangère qui va pointer sur la table des projets.
--> Le numéro fonctionnel utilisé pour désigner la version de ton projet.
Même remarque, si tu changes ce numéro, cela n'a aucun impacte sur la clef primaire de la table et donc de l'identifiant utilisée dans la base de données.

c) une table des préfixes.
La clef primaire sera composée d'un incrément unique.
Dans ta table, tu auras :
--> une colonne "libellé" ou tu renseignes le préfixe que tu utilises.
Même remarque, si tu changes le libellé du préfixe, cela n'a aucun impacte dans ta base de données.

d) une table des documents.
La clef primaire sera composée d'un identifiant unique de type incrément.
Dans ta table, tu rajoutes :
--> l'identifiant désignant la ligne de la table version que tu utilises.
--> l'identifiant du préfixe désignant la ligne de la table des préfixes.
--> une colonne numérique où tu pourras mettre le même identifiant (ton "00001") qui va désigner le numéro de ton document.
D'autres colonnes comme :
--> le nom du répertoire où se trouve rangé tes documents,
--> le nom réel de ton document dans le répertoire,
--> la date de dernière modification du document,
--> la date de création du document,
--> ...

Si ton utilisateur demande à lire le document "PRJ123-PL00001", il devra accéder à quatre tables afin de connaitre son emplacement et son nom définitif.
--> table "projet" pour "prj".
--> table "version" pout "123".
--> table "préfixe" pour "PL".
--> table "document" pour "00001".

L'idée que je suggère est de ne pas avoir de lien entre l'usage fonctionnel de tes documments et donc le nom réel du document enregistré dans le répertoire, et la façon de le classifier dans ta base de données

Ainsi tu pourras classifier tes documents en les mettant dans des répertoires différents, adpoté un nom contenant un horodatage, et de faire le lien en utilisant "projet", "version", "préfixe" et "numérotation" pour le retrouver.

Si maintenant, un même document appartient à plusieurs projets, il te fait :

d) table des documents.
Dans ta table, tu supprimes :
--> l'identifiant désignant la ligne de la table version que tu utilises.

e) tu crées une table association qui aura deux colonnes :
--> l'identifiant de la table version.
--> l'identifiant de la table document.

Tout ça pour dire que le script PHP fera la conversion des identifiants fonctionnels que tu utilises en faisant une recherche dans la base de données.
Et cette même base de données va te fournir le nom vrai nom du document et son emplacement.
Ton script va faire la relation entre l'homme (fonctionnel) et la machine (l'aspect technique), dont l'utilisateur n'a pas besoin de connaitre.
Voici pour les explications.

@+

[makimax]

Merci Artemus pour cette explication. Je comprends totalement. La recherche des 4 champs PRJ123-PL00001 serait donc en arrière plan 1 1 1 1 par exemple en base de données, cela permet de pouvoir revenir en arrière sur certain noms. Mais dans cet exemple, le nom final que tu mets au fichier lors de l'import est bien la concatenation donc PRJ123-PL00001.pdf et il peut y avoir des "trous" dans les clés peu importe dans ce cas.

PRJ123 c'est actuellement le code projet entier. J'ai en effet le problème de finalement utiliser un plan d'un projet pour un autre. C'est pourquoi je ne souhaite plus inclure le code projet dans le prefixe. Il devrait y avoir un bac à plan, un bac à notice, un bac à ... et finalement sont utilisés ou non par des projets, j'ai même des plans purement interne qui ne sont utilisé par aucun projet.

Ton idée de table association, je comprends, cela permet d'avoir plus d'une utilisations pour un même document mais dans la logique de nommage du fichier cela ne fonctionne pas, j'ai bien un seul et unique fichier.
PRJ123-PL00001 sera aussi trouvable en PRJ456-PL00001 mais le fichier aura été créé sous PRJ123-PL00001.pdf

Déjà si je retire PRJ et code projet, je n'ai plus qu'une ou deux tables
a) une table type de documents
La clef primaire sera composée d'un incrément unique "typdoc_prefix_id"
--> D'une colonne typdoc_prefix pour le PL, NO, SC ou autre (donc changeable à tout moment)
--> D'une colonne typdoc_descrption Pour plus d'explication sur ce type

b) une table des documents.
La clef primaire sera composée d'un identifiant unique de type incrément "doc_id"
--> l'identifiant du préfixe désignant la ligne de la table des types de documents.
--> une colonne numérique où tu pourras mettre le même identifiant (ton "00001") qui va désigner le numéro de ton document.
D'autres colonnes comme :
--> le nom du répertoire où se trouve rangé tes documents,
--> le nom réel de ton document dans le répertoire,
--> la date de dernière modification du document,
--> la date de création du document,


Pour pour ce "00001", comment faire pour ne pas avoir à le saisir ? si le document est un PLAN, je songe rechercher le dernier numéro affecté pour un type PL et lui fait +1 avant de faire un insert. Si jamais on est deux à le faire en même temps, il y a un risque. Sauf si je le met en UNIQUE ?

[Artemus24]

Peu import le nom de tes fichiers (ou documents), ceux-ci vont être rangés dans des répertoires.
La façon de ranger les fichiers dans les répertoires, ainsi que le nom ne doivent pas être connu des utilisateurs.
Ceci est ta nomenclature que tu dois mettre en place afin de t'y retrouver.
Voire les contraintes que tu as avec tes logiciels.

L'utilisateur a une autre nomenclature qui ne reprend pas celle que tu utilises.

Admettons que l'utilisateur se connecte par un compte qui lui est propre : "user456.
Ce compte est associé à un plan, et il accède à un domaine de ce plan.
Ces caractéristiques, peuvent être renseignées dans la table des utilisateurs.

Quand ce même utilisateur demande à accéder à la documentation, tu connais déjà le plan, ainsi que le domaine.
Tu peux lui fournir une liste de documents qu'il est autorisé à consulter.
Cette liste de documents ne sera pas la même pour un autre utilisateur qui lui-même sera dans un autre plan, ou encore dans le même plan mais d'un autre domaine.
La liste que tu vas fournir est un libellé désignant le document mais en aucune façon le nom du fichier qu'il n'est pas censé connaitre.

Tu devras mettre en correspondance à partie de la base de données les deux nomenclatures :
--> plan utilisateur <--> projet
--> domaine utilisateur <--> version + préfixe
--> référence du document <--> incrément

Avant de commencer à créer la base de données, il faut réfléchir à cet aspect nomenclature que tu dois mettre en place.
Je pense que tu as compris l'idée où les table vont te permettre de faire la relation entre les deux nomenclatures utilisées.

PRJ123-PL00001 sera aussi trouvable en PRJ456-PL00001 mais le fichier aura été créé sous PRJ123-PL00001.pdf

L'utilisateur n'a pas besoin de connaitre le nom des documents.
Dupliquer le même document sera nécessairement une source d'erreur en cas de maintenance.
Ce que tu mets à la disposition de l'utilisateur, c'est le contenu du document, en lecture seul je suppose.
Si tu dois fournir un pdf, il suffit de lui donner une copie de ce même document.
La table association répond bien au fait qu'un même document est présent dans plusieurs projets.

Pour pour ce "00001", comment faire pour ne pas avoir à le saisir ?

Au lieu de faire une saisie, propose une liste de documents que l'utilisateur a le droit de cliquer dessus pour les consulter.

C'est une recherche par multicritères, où tu peux introduire plusieurs façons d'accéder aux documents.
Par exemple, la date de création du document, son auteur, par projet, ...

@+

[escartefigue]

Bonjour

Pour pour ce "00001", comment faire pour ne pas avoir à le saisir ? si le document est un PLAN, je songe rechercher le dernier numéro affecté pour un type PL et lui fait +1 avant de faire un insert. Si jamais on est deux à le faire en même temps, il y a un risque. Sauf si je le met en UNIQUE ?

J'ai expliqué comment répondre à ce besoin dans ma réponse n°5 du 7 février : la colonne DO_numéro contient justement ce compteur unique et calculé automatiquement.
Pour ce qui concerne les accès concurrents, cette réponse explique également comment procéder.
Y a plus qu'à !

[makimax]

Lorsque je passe des commandes de pièces à fabriquer en usinage ou en découpe laser sur plan, je met des articles A000001 et A000002 par exemple sur ma commande C000456 . Y figure pour chaque article commandé une colonne avec chaque référence de plan nécessaire à leur fabrication. Le plan de fabrication peut très bien être le même pour les deux pièces. Cette référence est indiquée dans le contenu du document (cartouche de plan).
Lorsque quelqu'un à le plan en papier, c'est bien cette référence qui est la clé pour le retrouver informatiquement pour lui. Donc il cherche un fichier se nommant ainsi.
Le SGBD me donne un numéro, je nomme mon fichier source Autocad ou Solidworks ainsi, ce qui met à jour le champs référence dans le contenu du document, et génère son export en PDF ou DXF ou autre du même nom.
Cela peut être quelconque comme avec une règle de préfixe mais le nom de fichier doit bien être identique à l'information de référence de document indiquée dans le contenu. C'est comme lorsque l'on met un pied de page avec nom de fichier dans un document texte.

[escartefigue]

Bonjour,

Et du coup quelle est la question ?

[makimax]

Il n'y en a pas, vous m'avez apporté les réponses à ma question.
Merci à vous pour vos conseils !