faut-il liée ou importée une table ?

[lolothom]

j'aimerai votre avis , j'ai trouvé un peu partout sur le net

en faveur table importée

plus rapide pour l'ajout et la mise à jour
ajout de clés primaires possibles
intégrité référentielle possible

votre expérience ?

[Jack78960]

Bonsoir,

Réponse de normand ==> çà dépend

Les performances d'une table attachée n'est pas très différente de la même table dans la base.

Lorque que l'on veut développer une petite application, il semble plus sage comme les premières versions D'access de mettre tous les tables dans une base et tous les autres objets dans une base principale avec des attachements sur les tables:

• cela permet de compresser plus facillement la base des tables ==> le code assurant le compresse n'est pas dans la bases à compresser
  |*]la compresion d'une base ne contenant que des données est plus efficace que s'il y a d'autres objets (au mois jusqu'en Office 2000)
• l'attachement permet dans des cas extrêmes de dépasser la limite des Deux Giga Octets; on arrive en mettant deux très grosses tables chacune dans une base à faire une requête dans la base principale et à obtenir une réponse même avec deux tables qui indéxée approchent les deux GigaOctets (expérience personnel).

Par contre, utiliser l'attachement complique fortement l'installation ou le déplacement de son développement. En effet on ne corrige pas un attachement; on le supprime puis ont recrée un lien vers le nouveau fichier base de données.

Dans la plus part des cas , il est souhaitable d'avoir tous ces objet Access dans la même base ==> On fait tout de même des archivages très réguliers afin d'éviter les risques des cassures bases maintenant peu nombreuses mais toujours problématique.

[loufab]

Bonjour,
Quelques corrections :

Envoyé par Jack78960

Les performances d'une table attachée n'est pas très différente de la même table dans la base.

En local oui ! En réseau ce n'est pas du tout la même chose.

[*]cela permet de compresser plus facillement la base des tables ==> le code assurant le compresse n'est pas dans la bases à compresser

Il existe les options de la ligne de commande et le plannificateur de tache pour ça. Bien plus pratique !

Par contre, utiliser l'attachement complique fortement l'installation ou le déplacement de son développement. En effet on ne corrige pas un attachement; on le supprime puis ont recrée un lien vers le nouveau fichier base de données.

On peut modifier un attachement sans être obligé de le supprimer.

Exemple :

Code :

1
2
3
4
 
Set tdfCurrent = dbLoc.TableDefs(strTblName)
 tdfCurrent .Connect = ";DATABASE=" & strDataMdb
 tdfCurrent .RefreshLink

Dans la plus part des cas , il est souhaitable d'avoir tous ces objet Access dans la même base ==> On fait tout de même des archivages très réguliers afin d'éviter les risques des cassures bases maintenant peu nombreuses mais toujours problématique.

La corruptions des bases provient la plupart du temps d'un problème de réseau (perte de trame, coupure réseau), de problème matériel (drivers ou matériels -notamment Disque dur) ayant un disfonctionnement, ou encore avec des systèmes et office n'étant pas upgradé - les Services Releases corriges des problèmes autant les appliquer.


L'attachement a des avantages :
celles données pas Jack sur le contournement de la limite des 2go;
Utilisation plus sécurisé,
Partage plus performant,

L'inconvénient :
En monoutilisateur et sur des gros volumes une baisse de perfo (négligeable souvent imperceptible)
surtout l'absence d'héritage des Relations (donc refaire les relations dans la frontale.

Cordialement,