shenron76 Posté 21 Juillet 2006 Partager Posté 21 Juillet 2006 Bonjour, Je me pose une question concernant l'utilisation des tables dans une bdd. Voici un exemple: J'ai un site sur lequel il faut s'inscrire pour continuer la visite. L'inscription comprend pseudo, mdp, age, ville, tel. Je vais donc créer une table "membres" avec les champs pseudo, mdp, age, ville, tel. Maintenant, je souhaite enregistré les timestamp des connexion et déconnexion de mes membres.... Voilà ma question: Est il préférable de créer une seconde table nommée "connexions_deconnexions" avec les champs pseudo, timestamp_connexion, timestamp_deconnexion OU alors de rajouter ces champs dans la table "membres" ??? En résumé, est-il plus judicieux de regrouper tout dans une même table, quitte à avoir une table comprenant 30 champs différents OU alors faut il mieux faire plusieurs petites tables d'une dizaines de champs maxi ?? Y a t il un nombre de champs maximum à ne pas dépasser dans une table afin de ne pas saturer le traitement des données ou autre ??? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeromnimo Posté 21 Juillet 2006 Partager Posté 21 Juillet 2006 La question que tu soulève fait forcement débat dès que l'on conçoit une base de données ;-) Il faut savoir que les jointures sont assez longues (comparées à un SELECT normal), donc par exemple dans ton cas, il vaut mieux créer une deuxième table dans laquelle tu recopie la clef primaire du membre (plus eventuellement d'autres infos comme le pseudo par exemple) qui te permet d'avoir un "qui est en ligne" en n'interrogeant qu'une table (rapide, ce qui est bien si tu veux qu'il soit affiché sur cahque page par exemple) Apres, grace à la clef primaire, rien ne t'emepche de faire une jointure si tu as besoin de plus d'infos sur une page spécifique (admin, details des users connectés..etc) Lien vers le commentaire Partager sur d’autres sites More sharing options...
shenron76 Posté 21 Juillet 2006 Auteur Partager Posté 21 Juillet 2006 Quelle est justement la définition de la "clé primaire" d'une table ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeromnimo Posté 21 Juillet 2006 Partager Posté 21 Juillet 2006 Une clef primaire est un champ unique pour chaque enregistrement, qui te permet d'identifier de maniere sure et unique un enregistrement de ta table (par ex le numero d'inscription, incrementé à chaque nouvel inscrit) Lien vers le commentaire Partager sur d’autres sites More sharing options...
shenron76 Posté 21 Juillet 2006 Auteur Partager Posté 21 Juillet 2006 Ok merci il faut donc la définir à chaque création de table pour plus de sécurité ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
adn Posté 21 Juillet 2006 Partager Posté 21 Juillet 2006 A priori oui, même si au départ cela ne semble pas nécessaire, après ne serait-ce que pour faire un DELETE d'une ligne en particulier, çà peut servir Lien vers le commentaire Partager sur d’autres sites More sharing options...
shenron76 Posté 21 Juillet 2006 Auteur Partager Posté 21 Juillet 2006 Justement, est il possible de faire un DELETE sur plusieurs tables en même temps concernant une meme entré (un même membre par exemple) ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Spidetra Posté 21 Juillet 2006 Partager Posté 21 Juillet 2006 (modifié) La réponse est relativement simple : - dans un premier temps tu essaye de normaliser au maximum ta base - les dénormalisation éventuelles n'arrivent qu'à la fin, si tu as des pb de performances. Il te faut une table des cnx/dcnx. J'irai même plus loin, ville n'est pas un attribut de la table membre. Il te faut une clé étrangère IDVille qui référence une table des villes. Ne pas oublier que les SGBD sont R : Relationnel ! Ne pas hésiter à faire des jointures entres les tables. Modifié 21 Juillet 2006 par Spidetra Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 21 Juillet 2006 Partager Posté 21 Juillet 2006 La question que tu soulève fait forcement débat dès que l'on conçoit une base de données ;-) Je ne trouve pas qu'au niveau de la conception cela fasse vraiment débat ... Il ne faut pas avoir peur de créer des tables si celles-ci sont justifiés. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 (modifié) La réponse est relativement simple :- dans un premier temps tu essaye de normaliser au maximum ta base - les dénormalisation éventuelles n'arrivent qu'à la fin, si tu as des pb de performances. Ah bon? et comme ça c'est le merdier pour modifier tout ce qui concerne cette modification, un peu partout dans le code, Les dénormalisations se décident au début aussi, et non à la fin (de la programmation). En toute logique une fois le MCD établi, on peut facilement imaginer combien de jointures certaines requêtes demanderaient, et avec un peu d'expérience, se dire qu'a partir d'un certains nombre de jointures et en fonction du nombre d'enregistrements prévus dans chaque table, si cela fera ramer ou non le serveur. Quand tu as une requête SQL sur 5 ou 6 tables, Exemple de tables liées susceptibles d'être appelées parallèlement avec des jointures : "personne" "metier" "rue" "ville" "pays" "code_postal" Cela fait 6 tables. Un peu beaucoup... surtout si il y a des milliers de rues, des milliers de personnes etc... Ce genre de prévisions, on peut facilement les faire au début (en phase d'analyse) et donc à ce moment là décider de dénormaliser un peu. Par exemple pays ville cp et rue dans la même table (c'est ce qui se fait couramment). Cela fera des répétitions certe, mais il faut voir aussi si la séparation est vitale dans le projet en question. Tout ça se pense au début et non à la fin de la programmation... sinon c'est sujet à de multiples bugs imprévus, qui auraient pu être évités + perte de temps..... et donc d'argent! Zodd Modifié 1 Août 2006 par Zodd Lien vers le commentaire Partager sur d’autres sites More sharing options...
Portekoi Posté 1 Août 2006 Partager Posté 1 Août 2006 Par exemple pays ville cp et rue dans la même table (c'est ce qui se fait couramment). Cela fera des répétitions certe, mais il faut voir aussi si la séparation est vitale dans le projet en question. Whooww.... J'imagine la table avec toutes les rues de paris et le code postal répété des milliers de fois inutilement.... Je n'ai encore jamais vue une telle proposition (et pourtant, j'en ai vue des bdd) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 (modifié) Whooww.... J'imagine la table avec toutes les rues de paris et le code postal répété des milliers de fois inutilement.... Je n'ai encore jamais vue une telle proposition (et pourtant, j'en ai vue des bdd) Encore une fois, j'ai bien précisé "Si ce n'est pas vital". A partir du moment où c'est le membre qui entre son adresse, quel importance que la rue va se répéter 3 ou 4 fois? A moins que ton site c'est mappy.com, ou que tu comptes faire des statistiques par rue, ou quelques chose du genre, je n'en vois pas l'intérêt. Economiser de la place? Si tu as 10000 membres, tu vas gagner quoi? 50Ko? même pas? A l'heure des DD de 200Go je pense qu'on optera pour la performance plutôt que l'espace disque utilisé. Sur ce forum par exemple, la ville est un champ libre. Et pourtant Invision board c'est pas un forum de merde je crois. Zodd Modifié 1 Août 2006 par Zodd Lien vers le commentaire Partager sur d’autres sites More sharing options...
Portekoi Posté 1 Août 2006 Partager Posté 1 Août 2006 Bonjour, Je ne vois pas le rapport avec Invision sur le fait d'avoir un schéma de BDD cohérent. Si on suis ton idée, autant tout enregistrer dans une table et le jour ou il faudra ajouter une seconde adresse pour X ou Y raison, ton schéma ne sera pas évolutif. 50 Ko sur 10 000 Membres? Franchement, je pense plus que ca et quand on vois les hébergeurs proposés 100 Mo pour une BDD, c'est quand même pas énorme si le forum marche bien donc autant gagné de la place autant que possible. Portekoi Lien vers le commentaire Partager sur d’autres sites More sharing options...
Spidetra Posté 1 Août 2006 Partager Posté 1 Août 2006 Ah bon? et comme ça c'est le merdier pour modifier tout ce qui concerne cette modification, un peu partout dans le code, Les dénormalisations se décident au début aussi, et non à la fin (de la programmation).En toute logique une fois le MCD établi, on peut facilement imaginer combien de jointures certaines requêtes demanderaient, et avec un peu d'expérience, se dire qu'a partir d'un certains nombre de jointures et en fonction du nombre d'enregistrements prévus dans chaque table, si cela fera ramer ou non le serveur. Quand tu as une requête SQL sur 5 ou 6 tables, Exemple de tables liées susceptibles d'être appelées parallèlement avec des jointures : "personne" "metier" "rue" "ville" "pays" "code_postal" Si tu as une telle table ta base de donnée a été mal conçue. ( Cette table n'est pas normalisée ) Je suppose que tes champs métiers, etc... ne sont pas des clés étrangères mais des champs dénormalisées. Oui, la dénormalisation se fait, en derniers recours, si on a pas d'autres possibilités pour améliorer les performances. Mais bon, avant de dénormaliser, cela sous-entend que la base a été normalisée ( 1NF, 2NF, 3NF ). J'avoue ne jamais être aller au-delà Et ensuite tout dépend quel est ton processus de développement logiciel. Si tu as un bon gros vieux processus en V, effectivement tu vas t'arracher les cheveux chaque fois qu'il faudrat toucher à la structure de la DB. c'est comme ça que je suis devenu chauve Si tu as un processus de développement incrémental et itératif ( RUP, XP ), tu ne dois pas avoir peur de casser plusieurs fois to DB. Encore uns fois, j'ai rarement eu besoin de faire appel à la dénormalisation pour améliorer les performances d'une DB. Cela doit rester ponctuel et exceptionnel. La dernière fois c'était lié à une problématique très particulière ( Ajax ), et j'ai du passer par des opérateurs sur les bits. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 (modifié) Si tu as une telle table ta base de donnée a été mal conçue. ( Cette table n'est pas normalisée ) Ce que je listais ce sont des exemples de tables liées justement pour illustrer un exemple de cas dans lequel on va dénormaliser certaines données. Modifié 1 Août 2006 par Zodd Lien vers le commentaire Partager sur d’autres sites More sharing options...
Spidetra Posté 1 Août 2006 Partager Posté 1 Août 2006 Ce genre de prévisions, on peut facilement les faire au début (en phase d'analyse) et donc à ce moment là décider de dénormaliser un peu. Sil doit y avoir une dénormalisation, c'est au concepteur, et certainement pas à l'analyste, de faire ces choix. On pas la même conception de la production logicielle. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 Bonjour, Je ne vois pas le rapport avec Invision sur le fait d'avoir un schéma de BDD cohérent. Si on suis ton idée, autant tout enregistrer dans une table et le jour ou il faudra ajouter une seconde adresse pour X ou Y raison, ton schéma ne sera pas évolutif. 50 Ko sur 10 000 Membres? Franchement, je pense plus que ca et quand on vois les hébergeurs proposés 100 Mo pour une BDD, c'est quand même pas énorme si le forum marche bien donc autant gagné de la place autant que possible. Portekoi Le rapport est qu'ils aurait pu faire une table "Localités" histoire d'économiser de la place, et de normaliser au max mais il ne l'ont pas fait car dans notre cas ce n'est pas vital à la gestion des données. Donne moi le nom de ton hébergeur que je n'y aille pas. Il y a plein d'hébergeur en mutu pour lesquels tu as du 500Mo pour une bouchée de pains... et puis même 50Ko sur 100 mo y a de la marge. Et rare sont les membres habitant la même rue, donc même si ta DB est 100% normalisée, peut de chance de gagner plus de quelques milliers d'octets.... et encore... à moins que la france entière s'y est inscrite. Lorsque j'ai présenté mon travail de fin, d'étude, j'avais tout normalisé. clients, fournisseurs adresses, (se rapportant a client ou fournisseur) rues, villes pays (se rapportant a adresse). La première remarque d'un des membre du juri est le pourquoi la séparation en plusieurs tables (rue ville pays etc..). Ma réponse : pour normaliser au max Sa réponse : Ca risque de poser des prob de performances si il ya beaucoup de client/ adresses etc... Et il avait raison. Ma requête prenait plus d'une seconde. avec peut d'enregistrements.... Zodd Sil doit y avoir une dénormalisation, c'est au concepteur, et certainement pas à l'analyste, de faire ces choix.On pas la même conception de la production logicielle. L'analyste peut aussi faire preuve de bon sens, en général l'analyse connais le but final d'un projet, et donc peut sur base de ca décider de normaliser ou dénorméliser certaines choses. En effet nous n'avons pas la même conception. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Spidetra Posté 1 Août 2006 Partager Posté 1 Août 2006 Lorsque j'ai présenté mon travail de fin, d'étude, j'avais tout normalisé.clients, fournisseurs adresses, (se rapportant a client ou fournisseur) rues, villes pays (se rapportant a adresse). La première remarque d'un des membre du juri est le pourquoi la séparation en plusieurs tables (rue ville pays etc..). Ma réponse : pour normaliser au max Les membres de ton jury avaient raison. Normaliser, cela ne veut pas dire éclater en plein de petites tables. Une adresse c'est une entité autonome. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 (modifié) Les membres de ton jury avaient raison. Normaliser, cela ne veut pas dire éclater en plein de petites tables.Une adresse c'est une entité autonome. Pourtant si on met cp et ville et pays dans la même table --> redondance de données possible, me trompe-je ? Modifié 1 Août 2006 par Zodd Lien vers le commentaire Partager sur d’autres sites More sharing options...
Portekoi Posté 1 Août 2006 Partager Posté 1 Août 2006 Exactement mais pour ce qui est de la ville, la normalisé me semble juste. Peu de chance d'avoir la même rue mais beaucoup de chance d'avoir la même ville. Et pour ce qui est de ta requête prenant une seconde, les index sont très très important (je ne t'apprends rien) et l'un de mes sites ayant 15 000 membres, les requêtes ne prennent même pas 0,1 secondes... Et pour ce qui est de mon hébergeur, c'est 1and1 et j'en suis très content. Pourtant si on met cp et ville dans la même table --> redondance de données possible, me trompe-je ? Oui tu te trompes puisque le couple cp + ville est unique... C'est dans la table membre ou une table de croisement qu'il y aura une fausse redondance de l'id cp + ville. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 j'avais édité mon reply cp + ville + pays Lien vers le commentaire Partager sur d’autres sites More sharing options...
Spidetra Posté 1 Août 2006 Partager Posté 1 Août 2006 L'analyste peut aussi faire preuve de bon sens, en général l'analyse connais le but final d'un projet, et donc peut sur base de ca décider de normaliser ou dénorméliser certaines choses. En effet nous n'avons pas la même conception. Analyse et Conception sont deux phases différentes d'un processus. Un des rôle de l'analyste est de modéliser le modèle métier du client. Ce modèle doit s'abstraire le plus possible des contraintes logicielles et matérielles. Il doit aussi décrire les exigences non fonctionnelles. Le rôle du concepteur, en se basant sur le travail de l'analyste, est, au contraire, de coller aux contraintes logicielles et matérielles qu'on lui impose. Il va rajouter des couches techniques, appliquer ici ou là un pattern GRASP pour se simplifier la vie, casser une association faîtes par l'analyste ( sans pour autant modifier les cardinalités ), rajoutre des façades, etc., etc... Et de temps en temps la frontière entre Analyse et Conception est très, très légère.... surtout si l'Analyste et le Concepteur est une seule personne Finalement nos deux points de vues ne sont pas aussi éloignés que ça l'unde l'autre. Je suis même sûr qu'on arriverait à travailler ensemble, avec de grosses enguelades de temps en temps Lien vers le commentaire Partager sur d’autres sites More sharing options...
Zodd Posté 1 Août 2006 Partager Posté 1 Août 2006 (modifié) Finalement nos deux points de vues ne sont pas aussi éloignés que ça l'unde l'autre. Je suis même sûr qu'on arriverait à travailler ensemble, avec de grosses enguelades de temps en temps Hihi sans doute... moi de mon coté j'essaie de m'appliquer dans mon travail et parfois même de trop. Mon point de vue est peut-être faussé pour la raison que tu cites, je suis l'analyste et le concepteur dans ma boite. Donc je dénormalise directement car je connais à l'avance les contraintes matérielles. Et puis a force de créer des bases de données qui se ressembles souvent sur certains points (l'exemple clients/rue/ville/pays reviens souvent), on commence à agir par réflexe. Zodd Modifié 1 Août 2006 par Zodd Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant