Soutenez-nous
Publicité
+ 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 : 8
    Points
    8

    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 Alain
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    5 483
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain
    Âge : 53
    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 483
    Points : 13 699
    Points
    13 699

    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
    2 865
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 2 865
    Points : 4 649
    Points
    4 649

    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 : 8
    Points
    8

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 069
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

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

    Informations forums :
    Inscription : mai 2002
    Messages : 13 069
    Points : 29 234
    Points
    29 234

    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
    Membre Expert
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 573
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : février 2010
    Messages : 1 573
    Points : 2 403
    Points
    2 403

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 069
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

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

    Informations forums :
    Inscription : mai 2002
    Messages : 13 069
    Points : 29 234
    Points
    29 234

    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 Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 713
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 50
    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 : 13 713
    Points : 25 575
    Points
    25 575

    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 : 8
    Points
    8

    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 Fabien
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 740
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien
    Âge : 36
    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 740
    Points : 14 917
    Points
    14 917

    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 : 8
    Points
    8

    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
    Membre Expert
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 573
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : février 2010
    Messages : 1 573
    Points : 2 403
    Points
    2 403

    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 : 8
    Points
    8

    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
    Membre Expert
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 573
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : février 2010
    Messages : 1 573
    Points : 2 403
    Points
    2 403

    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 François Durand
    Spécialiste Delivery Mainframe IBM
    Inscrit en
    octobre 2005
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Spécialiste Delivery Mainframe IBM
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 198
    Points : 2 151
    Points
    2 151

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 069
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

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

    Informations forums :
    Inscription : mai 2002
    Messages : 13 069
    Points : 29 234
    Points
    29 234

    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
    809
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 809
    Points : 853
    Points
    853

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 069
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

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

    Informations forums :
    Inscription : mai 2002
    Messages : 13 069
    Points : 29 234
    Points
    29 234

    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 François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 405
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 405
    Points : 11 882
    Points
    11 882

    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
  •