+ Répondre à la discussion
Affichage des résultats 1 à 19 sur 19
  1. #1
    Invité régulier
    Inscrit en
    juin 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 30
    Points : 9
    Points
    9

    Par défaut Gestion Abonnement - deux tables ou une ?

    Bonjour,

    J'ai une table membre et je souhaite qu'un membre puisse s'abonner à un ou plusieurs autres membres afin d'être au courant lorsque un d'eux poste un statut.

    Comme Twitter en gros.

    J’hésite entre deux possibilités.

    1 table membre avec un champ "abonnement"



    Dans le champ abonnement je mets tous les id_user des membres dont je suis abonné en les séparants par une virgule. Et je traite l'information avec un explode en php.

    Deuxième possibilité :

    Je fais une deuxième table avec une clé étrangère id_user, et je rajoute l'id du membre suivi.



    Exemple :
    A veut s'abonner à B et C
    C veut s'abonner à A
    B à C

    id_user...|..id_du_membre_suivi
    A...........|..B
    A...........|..C
    C...........|..A
    B...........|..C

    Si on a beaucoup de membre on risque d'avoir beaucoup de lignes...

    Quelle solution est la plus optimisée ?
    Je ne sais pas trop comment modéliser cette situation avec un MCD.
    Je dois faire une association réflective ?

    Merci de m'aider

    Bonne soirée

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    5 718
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 5 718
    Points : 14 814
    Points
    14 814

    Par défaut

    C'est sans conteste la seconde solution qui est la seule bonne.
    L'autre ne devrait même pas être évoquée
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  3. #3
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 117
    Points : 5 157
    Points
    5 157

    Par défaut

    je degagerai la colonne id_abonnement ceci dit.
    Elle ne sert à rien dans ce cas précis.

  4. #4
    Invité régulier
    Inscrit en
    juin 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 30
    Points : 9
    Points
    9

    Par défaut

    Merci al1 et punkoff pour vos réponses.

    Si j'enlève la colonne id_abonnement je mets quoi en clé primaire ? Sachant que je ne peux pas utiliser id_du_membre_suivi ou id_du_membre_abonné.

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 504
    Points
    30 504

    Par défaut

    Citation Envoyé par punkoff Voir le message
    je degagerai la colonne id_abonnement ceci dit.
    Elle ne sert à rien dans ce cas précis.
    Pas si évident (dépend de l'indexation de la PK, par exemple CLUSTERED sous MS SQL Server=... Mais il est certain que dans ce cas, une clef alternative doit impérativement être rajouté sur le couple de clef étrangères.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  6. #6
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 988
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 988
    Points : 3 093
    Points
    3 093

    Par défaut

    Bonjour SQLPro, en quoi est-ce gênant que la clé primaire soit clustered ?

    En effet, lorsque je vais lire les abonnés de l'utilisateur lambda, ça me semble pas plus mal qu'ils soient tous regroupés ensemble sur le disque non ?

    Bon, après en effet, si 10000 personnes décident de s'abonner d'un coup à mon utilisateur 20, SQL Server va devoir bouger toutes les données de la table, ce qui peut être préjudiciable... Mais comparé au gain lors de toutes les autres requêtes, n'est-ce pas un risque à prendre ?

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 504
    Points
    30 504

    Par défaut

    Non seulement le problème que vous évoquez, mais une clef clustered sert de repère de ligne à tous les autres index ce qui fait que plus elle est grosse plus les index secondaires grossissent...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 008
    Points : 25 263
    Points
    25 263

    Par défaut

    Revenons à la modélisation...

    Règle de gestion :
    Un membre peut s'abonner à plusieurs membres et un membre peut être dans les abonnements de plusieurs membres.

    MCD :
    membre -0,n----abonner
    |------------0,n---------|

    Tables :
    membre (mbr_id...)
    abonnement (abn_id_titulaire, abn_id_membre_cible)

    Même avec 100 000 membres qui ont en moyenne 10 abonnements, soit plus d'un million de lignes dans la table associative, en utilisant une clé de type entier auto-incrémenté pour mbr_id, et donc des entiers dans les clés étrangères, même le mauvais MySQL donnera la liste des membres auxquels un membre est abonné en une fraction de seconde.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Invité régulier
    Inscrit en
    juin 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 30
    Points : 9
    Points
    9

    Par défaut

    J'utilise Mysql.
    Du coup pas de clé primaire sur la table abonnement ?

    On m'a toujours dit qu'une table devait impérativement avoir une clé primaire afin d'éviter les doublons... :'|

  10. #10
    Modérateur

    Homme Profil pro
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 6 914
    Points : 14 393
    Points
    14 393

    Par défaut

    Si bien sûr, vous avez du lire un peu vite.

    Soit vous implémentez une colonne id_abonnement, qui sera votre clef primaire.
    Soit vous ne l'implémentez pas et vous déclarez votre couple (id_membre_abonné, id_membre_suivi) comme clef primaire.

  11. #11
    Invité régulier
    Inscrit en
    juin 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 30
    Points : 9
    Points
    9

    Par défaut

    D'accord! Merci à tous pour vos réponses.

    Juste une dernière question par rapport à ma table membre. C'est plus optimisé si je rajoute une table pour le sexe des membres ou je laisse comme tel ?


    Tables:
    membre (mbr_id...)
    genre(id_genre, homme, femme)

  12. #12
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 988
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 988
    Points : 3 093
    Points
    3 093

    Par défaut

    Ta table "genre" à 3 colonnes ???

    id_genre, lib_genre

    C'est mieux non ?

    Evite le type "bit" pour le sexe. Sans parler du mauvais jeu de mot, le problème de bit, c'est que c'est vrai/faux/null
    Un jour tu pourrais avoir besoin de rajouter un autre sexe, ce qui t'obligeras à casser toutes tes tables. Un tinyint sur 8 bits est donc tout à fait correct, d'autant que niveau représentation mémoire/traitements, ce sera plus rapide qu'un bit !

  13. #13
    Invité régulier
    Inscrit en
    juin 2009
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 30
    Points : 9
    Points
    9

    Par défaut

    StringBuilder pour récupérer le genre d'une personne je serai obligé de faire une jointure avec cette méthode. Le traitement sera plus long du coup ou ça ne change rien ?

  14. #14
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 988
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 988
    Points : 3 093
    Points
    3 093

    Par défaut

    Ca ne changera pour ainsi dire rien.
    La table "genre" sera minuscule, et sans mouvement. Elle sera donc continuellement en mémoire.

    Aussi, au lieu de faire une requête à chaque fois pour retrouver le sexe d'une personne, tu utiliseras une jointure, ce qui est beaucoup plus performant.

  15. #15
    Membre Expert

    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 226
    Points : 2 272
    Points
    2 272

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Non seulement le problème que vous évoquez, mais une clef clustered sert de repère de ligne à tous les autres index ce qui fait que plus elle est grosse plus les index secondaires grossissent...

    A +
    Dans SQL Server certes, mais pas dans la majorité des autres SGBD (et en tout cas sûrement pas dans DB2 for z/OS) où c'est une référence interne qui est stocké dans les index secondaires ...

  16. #16
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 504
    Points
    30 504

    Par défaut

    Aujourd’hui"hui la plupart des SGBDR permettent de créer des index CLUSTERED. Dernier en date PostGreSQL.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  17. #17
    Membre émérite Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 965
    Points
    965

    Par défaut

    Intéressant, je ne l'ai pas vu. Sous quelle version et sous quelle syntaxe? On aura les index only scan dans la 9.2 (mais ça reste primitif) et l'opération cluster qui ne fait que trier la table sans lier à un index.

  18. #18
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 504
    Points
    30 504

    Par défaut

    Pour PG, tout dépend du FILL FACTOR que vous allez mettre et de la fréquence a laquelle vous allez défragmenter ou reconstruire les index.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  19. #19
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 883
    Points : 13 975
    Points
    13 975

    Par défaut

    Bonsoir,


    Citation Envoyé par SQLpro Voir le message
    Aujourd’hui"hui la plupart des SGBDR permettent de créer des index CLUSTERED. Dernier en date PostGreSQL.
    C’était en quelle année ?


    Citation Envoyé par SQLpro Voir le message
    une clef clustered sert de repère de ligne à tous les autres index ce qui fait que plus elle est grosse plus les index secondaires grossissent...
    Le concept d’index cluster et la technique de « clusterisation » méritent d’être explicités, car les SGBD divergent à ce sujet. Par exemple, le problème que vous évoquez n’existe pas avec DB2, puisque dans son cas les index adressent tous directement les tables. Voir à ce propos les approches SQL Server et DB2 (lequel, pour mémoire, a permis la clusterisation dès le début, disons 1984).

    Parfois les divergences sont bigrement sensibles, et on risque de tomber carrément dans le quiproquo. Extrait du document Présentation du système d’information ORACLE et introduction à SQL, par ORACLE France SA, décembre 1986, page 65 :

    « Une autre technique pour l’amélioration des performances est la "clusterisation" (regroupement). En créant un "Cluster", vous demandez à ORACLE de juxtaposer physiquement ensemble des lignes en provenance de différentes tables. Cette technique accélère ainsi les requêtes de jointure car les lignes que vous êtes amené à rapprocher par l’opération de jointure sont déjà physiquement regroupées et stockées de manière consécutive dans une même page du disque. »

    Autrement dit, le cluster (commande CREATE CLUSTER) sert ici à implanter les jointures en dur. J’avoue qu’à l’époque cela m’avait laissé, disons, septique et dubitatif, quand j’ai comparé avec DB2. Pendant ce temps là, des collègues qui utilisaient SQL/DS (frère aîné de DB2, né en 1981) pleuraient à chaude larmes car ils ne bénéficiaient pas des index cluster de son petit frère...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •