Comment bien configurer sa base des données ?
Fermé
razily
Messages postés
250
Date d'inscription
lundi 9 mars 2009
Statut
Membre
Dernière intervention
4 décembre 2013
-
16 févr. 2012 à 19:52
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 - 25 févr. 2012 à 12:29
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 - 25 févr. 2012 à 12:29
A voir également:
- Comment bien configurer sa base des données ?
- Configurer chromecast - Guide
- Vérifier que le serveur freebox est bien connecté à internet - Forum Freebox
- Germain veut gérer les activités de son association avec une base de données. il a commencé à créer des tables dans un fichier, mais il n’est pas sûr du résultat. le fichier à télécharger contient uniquement le schéma de cette base de données. en l’état actuel, que peut-on en déduire ? - Forum Outlook
- Excel reporter des données sur une autre feuille avec conditions - Forum Excel
- Formules excel de base - Guide
1 réponse
Bonsoir,
En principe, pour éviter la redondance des informations, la séparation en plusieurs tables est recommandée :
- une table pour les couleurs, une pour les marques...
- peut être même, pointures, avec une identification relative
Toutefois, ça dépend quand même fortement de ta future utilisation, tu dois te poser quelques questions :
- Est ce que quelqu'un va devoir maintenir ce travail après toi?
- Quelle taille va faire la base de données au final?
- Est ce que tu vas accéder aux mêmes informations tout le temps : inner join fréquent -> complexification des requêtes -> ce qui n'est pas optimisé...
Il faut faire la part des choses entre l'optimisation des requêtes et la redondance...
En principe, pour éviter la redondance des informations, la séparation en plusieurs tables est recommandée :
- une table pour les couleurs, une pour les marques...
- peut être même, pointures, avec une identification relative
Toutefois, ça dépend quand même fortement de ta future utilisation, tu dois te poser quelques questions :
- Est ce que quelqu'un va devoir maintenir ce travail après toi?
- Quelle taille va faire la base de données au final?
- Est ce que tu vas accéder aux mêmes informations tout le temps : inner join fréquent -> complexification des requêtes -> ce qui n'est pas optimisé...
Il faut faire la part des choses entre l'optimisation des requêtes et la redondance...
16 févr. 2012 à 22:49
17 févr. 2012 à 08:28
Après c'est à toi de déterminer si c'est grave... ou pas?
Est ce que cette application est susceptible d'évoluer? Est ce que tu as un "client" à satisfaire, qui te demande cette application, susceptible de vouloir des changements sur cahier des charges? Ce sont des questions qui peuvent t'aider pour déterminer quelle solution tu dois adopter.
17 févr. 2012 à 08:58
et l'afficher comme il faut !!
17 févr. 2012 à 09:10
Un dernier point, admettons que régulièrement, tu fais une requête du type :
"WHERE couleur = 'Blue' (pour par exemple, afficher la liste de tes produits d'une certaine couleur. )
Si tu es sur une seule table, il me semble qu'il va parcourir toutes les lignes de ta table pour retrouver tous les produits bleus.
Si tu sais que cet appel est fréquent, tu as meilleur temps de le séparer dans une autre table en terme de performance. Ca vaut pour toutes les requêtes en "where" que tu feras.
17 févr. 2012 à 09:29