IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQL Procédural MySQL Discussion :

Structure de base de données


Sujet :

SQL Procédural MySQL

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 30
    Par défaut Structure de base de données
    Bonjour,

    Je souhaiterais modèliser une base de données de produits. Le problème est que ces produits peuvent avoir des caracteristiques et critères de recherche très différents.

    Ex :
    • Carte graphiques avec filtre de recherche sur la marque, la mémoire, le bus graphique, chipset graphique, etc...
    • Processeur avec champs marque, fréquence, socket, etc...
    • Carte mère avec champs marque, socket, chipset, bus graphique, etc..
    La solution qui me parait la plus adaptée est la modélisation par héritage :

    Code : 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
     
    t_produit
    prd_id (pk)
    prd_marque
    prd_prix
     
    ----------
     
    t_carte_graph
    prd_id
    prd_mem
    prd_bus
    prd_chipset
     
    t_cpu
    prd_id
    prd_freq
    prd_socket
     
    etc...
    • Pensez-vous que c'est la seule solution à adopter ???
    • En terme de souplesse, y a t-il mieux ???
    • Pouvez-vous me proposer d'autres modèles ??? (autre que la modèlisation par méta-données, quelle galère !!! )
    Merci d'avance

    Cordialement,

    Philippe

  2. #2
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Par défaut
    Bonsoir Philippe,

    Citation Envoyé par hphil
    La solution qui me parait la plus adaptée est la modélisation par héritage
    Ca me semble aussi la solution la mieux adaptée.

    Ca te permet également de représenter de manière très fine les données propres à chaque composant et de faire des traitements intéressants comme la liste des matériels compatibles.

    Exemple: Une carte mère est caractérisée (entre autres) par:
    - le type et le nombre de socket pour le processeur
    - le type et le nombre de ports (PCI-Express, AGP, PCI...)
    - ...

    Un processeur est caractérisé par:
    - le type de socket
    - la fréquence
    - ...

    Une carte graphique est caractérisée par:
    - le type de port
    - ...


    Avec:
    • des tables "composants" comme: t_carte_mere, t_carte_graph, t_cpu
    • des tables "caractéristiques" comme: t_socket, t_port
    • des tables traduisant les relations comme "cette carte-mère possède 2 ports PCI-Express"
    on peut en fonction du processeur choir la carte mère, puis la carte graphique, etc.



    La limitation d'un tel système, ce sont les solutions "hybrides" faisant intervenir de l'héritage multiple, par exemple les barebones qui regroupent à la fois la carte mère, le boitier et le ventirad.

    Un autre cas assez pénible, ce sont les cartes mère multi-processeurs, par exemple.


    Citation Envoyé par hphil
    • Pensez-vous que c'est la seule solution à adopter ???
    • En terme de souplesse, y a t-il mieux ???
    La seule, non. La meilleure, certainement.

    C'est déjà très très souple: ça te permet de définir précisément les caractéristique de chaque composant, et surtout les contraintes entre composants (sockets entre processeurs et CM, etc.)
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 30
    Par défaut
    Bonjour,

    Merci Caboche de m'avoir répondu.

    Citation Envoyé par pcaboche
    La seule, non. La meilleure, certainement.
    La modélisation par héritage me semble aussi la plus adaptée ! Elle offre pas mal de perspective en terme d'évolutivité (dommage que MySQL ne gère pas ça en natif, alors que PostgreSQL... )

    Par curiosité et pour ma culture personnelle, ya t-il une autre solution tout aussi pertinente que l'héritage pour modéliser une telle structure, commune quand même à beaucoup de site de ecom (LDLC, TopAchat, Pixmania, et j'en passe...) ?

    ----------

    Cordialement,

    Philippe

  4. #4
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Par défaut
    Citation Envoyé par hphil
    Par curiosité et pour ma culture personnelle, ya t-il une autre solution tout aussi pertinente que l'héritage pour modéliser une telle structure, commune quand même à beaucoup de site de ecom (LDLC, TopAchat, Pixmania, et j'en passe...) ?
    T'as qu'à leur demander... (mais ça métonnerait beaucoup qu'ils te répondent: "Bonjour, comme vous m'avez l'air bien sympatique, voici la structure de notre base de données en ligne, faites-en ce que vous voulez. Enjoy !")

    Plus sérieusement, je ne pense pas qu'il y ait d'autre solution (je veux dire "d'autre solution viable". Sinon il y a toutjours la solution avec les méta-données mais bon... tu vois ce que je veux dire !)
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 30
    Par défaut
    Merci d'avoir pris le temps de me répondre. Cela m'a permis d'effacer certaines zones d'ombres et de doutes

    Je clos le sujet...

    @plus

    ----------

    Bien cordialement,

    Philippe

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Structure de base de données pour un questionnaire
    Par maminirina dans le forum MySQL
    Réponses: 1
    Dernier message: 24/10/2008, 09h09
  2. Structure de base de donnée (optimisation?)
    Par juJuv51 dans le forum SQL Procédural
    Réponses: 5
    Dernier message: 23/02/2007, 21h05
  3. Réponses: 8
    Dernier message: 05/12/2005, 12h52
  4. Réponses: 4
    Dernier message: 17/02/2004, 08h36
  5. structure des bases de données Palm
    Par nomdutilisateur dans le forum Bases de données
    Réponses: 2
    Dernier message: 17/01/2004, 17h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo