Structurer sa base de données

Salut,

Il faut avant tout évaluer la probabilité de faire appel aux tables jointes. Si les données sont systématiquement lus, il faut rassembler dans la même tables.
Autre facteur, par exemple le code postal, sera t'il lu dans d'autre fonctions (ex. Fiche client) ? Si oui il faut l'externaliser dans une table indépendante avec villes, pays etc...).
Et enfin et non négligeable, en fonction de la base de données, la jointure peut être pénalisante en terme de performance. Y compris au sein des différentes version de windev et du nombre de jointures (dégradation si les clés ne sont pas bien choisies, anciennes version de WD non appropriées à parti de 3 jointures). Pour des BDD extérieures, penser aux procédures stockées.

Je pense qu'il faut pratiquer par des test aussi. Enfin, plein de choses à calculer.

 

salut

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

,
cela s'appelle de conception de modèle logique des données.
il y a pas mal de cours en format livres ou vidéo sur le sujet.
ou méthode merise.
il existe d'autres méthodes.
voici un exemple :

 

Bonjour,
J'ai eu ce problème en Mysql et je pense que c'est général pour les BDD. Quand le nombre d'enregistrements n'est pas important, les performances restent acceptables mais plus le nombre augmente plus le fichier de la table prend du volume.
En règle générale, il vaut mieux séparer les tables quand il y a possibilité de champs de liaison surtout quand les appels aux jointures sont occasionnels.
De plus on suppose que les champs nécessaires sont :
ID_Client (Entier Long 4), Nom (STR 30), Prénom (STR 30), Adresse (STR 255), Code Postal (STR 6), Commune (STR 30), Département (STR 30), Région (STR 30)
Vous allez avoir des enregistrements qui vont avoir des doublons (inutiles) en Code Postal, Commune, Département, Région et lorsque vous ferez des recherches sur le nom uniquement ils seront là pour ralentir l'opération. Alors qu'il suffit de balancer les champs Commune, Département, Région dans une autre table dont la clé unique est Code postal pour alléger le tout.

 

Bonjour,
En règle générale, on mets sur une autre table les informations qui peuvent être communes à beaucoup d'enregistrements dans la table dite principale.
Dans le cas que je t'ai présenté, je mettrais Commune, Département, Région dans la seconde table et je ne garderais que le Code postal qui me servira de référence pour la jointure.

 

Salut

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

En quelquesorte ta question nous ramene un peu dans les "normalisations". Dans ton example IL FAUT creer une table saparee surtout pour les addresses de livraison sinon cela fera beaucoup de redondance et vite ta base s'essouflera. J'ai eu un cas similar que voici.
Une compagnie de livraison doit distribuer les paquets a des clients de amazon a travers la cote east des etats unis. Les paquets sont recus de Amazon en fret et Scanee un a un toute la nuit avant de partir pour la livraison.
C'est en quelque sorte 10.000 petit paquets a faire distribuer par une cinquantaine de chauffeurs, utilisant les van de livraisons. Donc vu toutes les tables a creer et la zone a couvrir. le format d'adresse aux US c'est : Nr Batiment, Nom rue, City, State, Zip code.
Les infos receuillit a partir des paquets scannees sont: Bare code, Nom et prenom du client, Adrresse de Livraison complete, Phone number, etc...
Donc tu as une idee apres avoir scanne 10,000 paquets/jour le volume. Pour trouver une addresse apres une semaine de travail, le programme parcourira toute la base ce qui peut etre interminable.
Mais nous avons fait une table UNIQUEMENT d'addresse et un paquet scannee pointera sur une valeur au lieu de prendre toute l'address dans une seule table (gain en volume aussi). C'est vrai que cela fait de jointure, mais c'est tres tres souple.
Maintenant l'autre partie pour la performance dependra de la conception de la requete, le support et la capacite qu'offre la machine.
En resume je dirais plus c'est petit mieux c'est facile a gerer (par defaut performant)
Cheers.

 

Salut

Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

LST 105

Optimiser une analyse revient à réduire au minimum la taille des fichiers de données : plus un fichier de données est petit, plus il a de chances d'être chargé en intégralité en cache et donc être accessible rapidement.
Si un fichier de données peut être lu depuis la mémoire cache sans avoir à accéder au disque dur, c'est un gain de temps considérable.
Pour réduire la taille d'un fichier de données, une solution consiste à réduire la taille allouée à 1 enregistrement de ce fichier. Il est alors nécessaire d'analyser chaque rubrique pour déterminer si elle peut être réduite.