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 +