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 ???

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)

Quelle est justement la définition de la "clé primaire" d'une table ?

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)

Ok merci il faut donc la définir à chaque création de table pour plus de sécurité ?

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

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) ?

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.

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.

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

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

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

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.

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.

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.

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




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.

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 ?

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.



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.

j'avais édité mon reply cp + ville + pays

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

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