Bonjour!
 
Je travaille depuis 3 mois sur un projet qui avait été commencé par une autre personne auparavant (un gros logiciel en C++), et je me penche maintenant sur la partie "base de données". La personne avant moi avait mis en place une architecture assez étrange à mes yeux, j'ai déjà mis en place un sous programme pour la remplir à l'aide des ODBC, mais je suis pris d'un doute...
 
Voilà l'architecture de la base:

 
Donc en gros chaque entrée dans une table a un numéro d'index, et la table "entrees" les regroupe. Les infos à stocker concernent des clients, avec plusieurs contrats portant sur plusieurs rues contenant plusieurs mâts, avec informations générales et mécaniques pour chacun de ceux-ci.
 
Mes problèmes sont les suivants:
- déjà je trouve ce genre de relations peu claires, par rapport à une architecture du style "table clients" -- "table contrats" -- "table rues" -- "table mâts" à laquelle je suis plus habitué.
- pour le moment, quand on ajoute des entrées leur index est incrémenté par rapport à l'index le plus élevé déjà existant dans la base, donc je risque d'avoir un problème à long terme, non? (exemple: j'ai les index 1 à 100 utilisés, je supprime les entrées d'index 10 à 20, puis je rentre des nouvelles données, leur index sera 101, 102, ... alors que ceux de 10 à 20 sont de nouveai libres!) Donc après plusieurs mois d'utilisation je risque d'atteindre la valeur maximale autorisée par la base SQL pour les index, et tout sera bloqué! Pour éviter ça, je vais devoir récupérer tous les index libres, ce qui va encore rajouter des calculs...
 
Donc voilà, est-ce vraiment mieux d'utiliser ce genre d'architecture? J'ai l'impression que ça ne fait qu'alourdir les choses, mais je me trompe peut être...

En gros : J'ai rien compris à tes tables, donc d'un point de vue "analytique", je ne peux pas te dire si c'est correct, bien que ça me paraîsse étrange.
 
Par contre, d'un point de vue purement logique, il y a deux énormes incohérences...
 
=> NUM_ENTREE est la clé primaire de TOUTES les tables. A ce moment, cela veut dire qu'une seule table "maxi-poubelle" peut stocker l'intégralité des informations, ce dont je doute.
 
=> Chaque "sous-clé" des autres tables sont présentes à la fois dans les tables "mères" et la table "entrée". Logiquement, num_entree n'a donc sa place que dans la table entrée, puisque cette dernière est déjà liée aux tables autour.
 
D'un point de vue purement analytique, t'as pas très bien détaillé, donc il est possible que je me trompe...
 
Généralement, on a :
 
Table CLIENT
Clé : NUMCLI
 
Table ADRESSE (rue)
Clé : NUMCLI / NUMADR (double clé - tu peux aussi ajouter "TYPADR" pour différencier adresses de livraison, communication et facturation)
FK : NUMCLI
 
Table PRODUIT
Clé : CODPRO
 
Table COMMANDE / CONTRAT
Clé : NUMCDE (tu peux aussi faire intervenir NUMCLI dans la clé, ainsi qu'un éventuel TYPCDE si tu gère des commandes/contrats/devis)
FK : NUMCLI / NUMADR (tu peux avoir plusieurs fois ce champ si tu gère plusieurs types d'adresses)
 
Table LIGNECDE
Clé : NUMCDE / NUMPOS (numéro de la ligne dans la commande)
FK : CODPRO
 
Pour ce qui est de la clé autoincrément, aucun souci à avoir. Voici par exemple les limitations de SQL Server, la plupart des autres SGBD ont des limitations similaires à ce niveau :
 

 
Donc, déjà avec un simple type integer t'as de quoi faire... Si t'as peur, t'as toujours bigint, et si vraiment t'es assez parano pour penser que dans 10 000 ans on viendra déterrer ton corps pour te faire corriger un bug, tu peux toujours utiliser un number, il monte jusqu'à 17 bytes (136 bits). Après quelques calculs, si tu tente de référencer chaque atome de l'univers dans la base, t'auras encore de la place pour descendre au niveau des protons
 
Je pense que ton disque aura fumé d'ici là

j'ai jeté un bref coup d'oeil, je vois déjà des défauts.
notamment les champs remarques de la table igco. Si l'on a plus ou moins que 3 remarques, on est embêttés.
idem pour les surfaces/dimaètres/hauteurs qui devraient faire l'oeuvre d'une ou plusieurs tables séparées.
 
en résumé je pense qu'il a voulu économiser les tables

Ok, merci beaucoup, vos avis me confortent dans mes opinions...
 
urd-sama -> Pour les remarques, pas de problèmes, tous les champs proviennent d'un logiciel dans lequel il n'y a de possibilité que pour 3 remarques, idem pour les autres données. mais tu as raison, il a dû vouloir économiser les tables (à la base il comptait faire ça sous Access, c'est plus limité point de vue nombre de champs, non?)...
 
Arjuna -> Désolé, j'ai très mal expliqué les choses, mais je crois que tu les as quand même pas mal comprises!   Comme tu le dis, vu la façon dont sont faites les tables, on pourrait passer par une seule grosse table dont chaque ligne comporterait toutes les infos pour un mât (client, contrat, rue, nom, infos techniques...), donc il y a un max d'infos répétées et ça ne me plait pas... Je suis tout à fait d'accord avec l'architecture générale que tu donnes, c'est ce genre là que j'ai vu en cours, donc je pense que je vais tout refaire sous cette forme. (merci pour l'info sur les INT au passage!   )

"plus limité" je sais pas
je connais pas les spec précises de access, mais normalement il ne devrait pas y avoir de problèmes majeur

Les seuls problèmes d'acces (les principaux) sont :
- Lenteur : Access est lent, c'est pas fait pour faire des grosses bases.
- Taille : Access n'est pas fait pour stocker des millions de lignes. Passé un certain nombre de lignes par table, ou Mo, Microsoft ne garantis même pas la cohérence des résultats.
- Mono-utilisateur : Même si avec les dernières versions ça s'est amélioré, une base Access est faite pour être distribuée localement avec un programme, et ne supporte pas des accès multiples (il supporte, mais ça a tendance à planter à tout bout de champs à cause de son système de lock qui n'est pas performant du tout)
 
Sinon, niveau complexité de la base de données elle-même, Access couvre l'intégralité de la norme SQL-92 (on peut même faire des pseudo-triggers via bidouille), et est donc moins limité que MySQL 3