Discussion :

[Norin]

Bonjour, j'ai deux types d'informations très similaires (Exemple: Rencontre et Réunion).

Tous deux contiennent à peu près les mêmes informations outre que la Rencontre par exemple, contient un numéro de rencontre alors que la réunion contient un nom de rencontre (Ce serait l'unique différence entre les deux tables).

Serait-il mieux de créer deux tables distinctes? Soit une pour les rencontres et une pour les réunions ou devrais-je plutôt ajouter un champ "Type" et un autre "Nom" dans une même table qui aurait le rôle de contenir les deux types d'informations en même temps? (Si le type serait rencontre, le nom serait vide et si le type serait réunion, le numéro de rencontre serait vide)

Y aurait-il une quelconque différence de performance entre les deux options?

Merci d'avance

[AdD92]

Bonjour,
La réponse est dans la théorie des bases relationnelles (voir les tutoriels/docs sur ce site).
A priori, pour moi, la réponse est 2 tables car chaque table concerne un traitement particulier.
Si, dans un premier temps, une table comprenant le tout peut sembler plus simple (intellectuellement), à moyen terme, si ton application se développe, tu risque d'avoir des pb. de mises à jour, de relation 1 à 1 ou 1 à n ou n à 1.
Bonjour l'usine à gaz à ce moment-là.
Avec 2 tables, c'est clair.
Cordialement.

[Norin]

Merci, je ferai donc deux tables

[Heureux-oli]

Tous deux contiennent à peu près les mêmes informations outre que la Rencontre par exemple, contient un numéro de rencontre alors que la réunion contient un nom de rencontre (Ce serait l'unique différence entre les deux tables).

Unique différence, au niveau des champs ou des données.

Là les avis seront toujours partagés, si les tables sont identique au niveau des champs, je ne ferais qu'une seule table puisque les enregistrements ont différenciés par une champ rempli ou non.

Il faut aussi tenir compte de l'utilisation des données.

Est-ce qu'une réunion donne lieu à une rencontre ou vice versa ?

Combien d'enregistrments ?

Evolution future ?

Il y a plein de question aui peuvent faire pencher la alance d'un côté ou de l'autre.

[pellec]

Bonjour, il n'y a pas que deux possibilités. Il y en a une troisième : pas une, pas deux mais trois tables.
La première table serait celle qui engloberait les caractéristiques communes des réunions et rencontres. Elle pourrait s'appeller "contact".
Ensuite une deuxième table s'appelerai "rencontre" et aurait deux colonnes : l'une contenant la clé externe pointant vers des contacts, et l'autre qui serait la colonne le nom de la rencontre.
Et pareil pour la troisième table "réunion" qui contiendrait deux colonnes : la référence vers le contact, et la colonne "numéro de réunion".

Pour synthétiser voici les attributs de chaque table :
contact : (clé primaire) idContact, ...(tous les attributs communs aux réunions et rencontres)
rencontre : (clé externe vers idContact de la table Contact) idContact, nomRencontre
contact : (clé externe vers idContact de la table Contact) idContact, NumeroRéunion

Selon moi, cette méthode est la plus propre. Si un jour tu veux faire évoluer tes tables, c'est la méthode la plus flexible.

voir méthode MERISE de conception de base de données : http://cyril-gruau.developpez.com/um.../ConceptionBD/

En esperant t'avoir eclairci.

[AdD92]

Exact ! Je ne peux qu'approuver.
Mais cela passe par une modélisation par les données (méthode Merise) ou par les fonctions (méthode Axial).
Les 2 méthodes se rejoignent au final.
Question : Les informations communes de Contact et Rencontre se mettent-elles à jour au même moment et/ou concernent-elles indissociablement la même action ?
Si oui, 3 tables tables suffisent.
Si non, 4 tables : Contact, Rencontre, Relation Contact vers Rencontre et Relation Rencontre vers Contact. Les 2 dernières tables sont, finalement, des index.
Cordialement.

[motrin]

Je désapprouve totalement l'utilisation de 3 tables. Est-ce qu'une rencontre est une réunion? Quant à moi, il y a aucun lien. Quand nous normalisons une bd il ne faut pas essayer de trouver les champs semblables entre deux tables et les rassembler. Selon la loi de la normalisation de la bd, l'utilisation de deux tables distinctes est essentielles.

[pellec]

motrin, d'un côté je vois ce que tu veux dire. Bien sûr qu'une rencontre n'est pas une réunion. Et une réunion n'est pas une rencontre non plus.
Par contre, même si ce n'est pas exactement la même chose, ça peut être regroupé dans une entité plus globale. ex : "contact" comme je le disais plus haut. "contact" au sens : j'ai vu des personnes (soit dans le cadre d'une rencontre, soit dans le cadre d'une réunion).
Après, ce regroupement n'est légitime que si Norin (concepteur de la base) voit ces deux entités sous le même oeil, et désirera effectuer le même genre de requêtes sur ces deux entités.

Mais pour revenir aux regroupements, je ne suis pas d'accord avec ce que tu dis. Je pense qu'il ne faut pas faire des tables distinctes si deux entités ont des propriétés communes. Un exemple vaut mieux qu'un long discours :
Disons que j'ai une entité voiture et une entité moto. Pour chacune de ces deux entités, je veux la date de construction, la vitesse, la marque, etc.
Toi, tu penses qu'on devrait faire deux tables distinctes, point final ?
Eh bien moi je pense qu'il faudrait faire une table véhicule avec les caractèriques communes aux motos et aux voitures, puis deux autres tables : l'une pour les caractéristiques spécifiques aux motos et l'autre pour les voitures.

Mais je répète qu'il n'y a que le concepteur (qui sait de quoi il a besoin) qui peut décider de regrouper ou non ses réunions et ses rencontres.

Ce n'est que mon humble avis...

[motrin]

Mais pour revenir aux regroupements, je ne suis pas d'accord avec ce que tu dis. Je pense qu'il ne faut pas faire des tables distinctes si deux entités ont des propriétés communes. Un exemple vaut mieux qu'un long discours :
Disons que j'ai une entité voiture et une entité moto. Pour chacune de ces deux entités, je veux la date de construction, la vitesse, la marque, etc.

Je ne sais pas ce que tu fais dans la vie, mais je serais vraiment curieux de voir comment tu ferais la relation de la table commune aux tables voiture et moto de façon à ne pas mettre le bordel dans la base de données.

[random]

tous les assureurs mettent dans la même table les voitures et les motos
c'est aussi le cas des préfectures dans le fichier carte grise
tout dépend du niveau d'abstraction

[pellec]

merci random.
motrin, je pense que tu n'as jamais fait de programmation orienté objet (java, c++), je me trompe ?
Connais-tu la notion d'héritage ?

[SamLeChiseuji]

Bonjour à tous,

Juste une petite remarque :
La question est de savoir comment organiser les tables et les champs...
...non pas pour se rapprocher d'une quelconque normalisation...
... mais plutôt pour obtenir les meilleures performances...

... donc voilà...

[pellec]

Oui, j'admets que je me suis eloigné de la question de départ. Effectivement, il est possible qu'on perde en performance (au sens "temps mis pour effectuer des requêtes") si on répartit sur plusieurs tables (a voir selon ce qu'on fait avec ces tables...).

[motrin]

tous les assureurs mettent dans la même table les voitures et les motos

ce n'est pas pcq les assureurs le font que c'est la meilleure idée.

motrin, je pense que tu n'as jamais fait de programmation orienté objet (java, c++), je me trompe ?

C'est que r'garde le grand je sais ce que je dis. Je fais du java, c++, vb, vb.net, vb6, windev, webdev, Access, PL/SQL, c++.net, ASP.NET,PHP. Je pense que tu n'as jamais travaillé toi dans une bd où tout est mélangé. Par expérience, je te dit que c'est l'enfer et c'est des décision comme cela qui font au cours du cycle de vie du logiciel il y a des changements majeurs que tu es forcé de faire pcq la personne x l'a pensé en cabochon.

je serais vraiment curieux de voir comment tu ferais la relation de la table commune aux tables voiture et moto de façon à ne pas mettre le bordel dans la base de données

tu ne m'as toujours pas démontrer la facon que tu ferais tes relations avec tes tables.

[SamLeChiseuji]

Bonjour,

Je fais du java, c++, vb, vb.net, vb6, windev, webdev, Access, PL/SQL, c++.net, ASP.NET,PHP.

La question était de savoir si tu connaissais la POO, pas de connaître le nombre de langage de programmation que tu connais... On peut très bien faire de la programmation procédurale en c++, vb, windev, etc...


De toute façon, comme je l'ai déjà dis, la question de départ n'est pas du tout là, ça serait plutôt bien d'arrêter de débattre sur ce sujet.

A chaque fois que je vois qu'il y a un nouveau post, je me dis "Chouette, quelqu'un viens de poster une réponse CONSTRUCTIVE qui va me permettre de savoir comment je pourrais ORAGANISER mes bases de données pour avoir les meilleures PERFORMANCES". Mais non, à chaque fois je me retrouve au milieu d'un débat qui n'a absolument rien à voir...

[pellec]

Salut !

A propos des performances :
- Le gain en performance se fait souvent au détriment de la normalisation. En gros on va essayer de regrouper les données dans une même tables de manière à minimiser le nombre de jointures à faire lors des requêtes. Et ça peut entraîner des redondances de données.
- Ajouter des index (aux clés primaires et étrangères).
- Minimiser les clés étrangères et gérer les contraintes d'intégrité avec notre application. ex: au lieu de mettre une clé étrangère, vérifier soi-même dans un événement before_update que la donnée entrée existe bien dans l'autre table.

Mais de manière générale, il ne faut jamais optimiser à priori, mais plutôt à posteriori si notre application est vraiment trop lente.

Et dernière chose, qui n'engage que moi : il vaut mieux faire une organisation béton de sa base de données, quitte à la changer par la suite par souci d'optimisation, plutôt que l'inverse.

Je tire tout ça de la partie "optimisation" du document que j'ai déjà cité plus haut :
http://cyril-gruau.developpez.com/um.../ConceptionBD/

En esperant avoir été un peu plus constructif

[SamLeChiseuji]

Merci pellec pour cette réponse
On est enfin revenu sur le sujet

[random]

ce n'est pas pcq les assureurs le font que c'est la meilleure idée.

non mais les assureurs payent des informaticiens dont certains sont compétents
ces informaticiens procédent à des études rationnelles des données et des performances
il est possible que seul dans ton coin tu aies de meilleures idées; la solitude est souvent la compagne du génie. Mais j'en doute.

[random]

on pourrait mieux t'aider sur les performances si tu nous disais quels sont les volumes prévisibles
si ta table fait 10 000 lignes et est indexée personne ne verra de différence entre les deux solutions

[motrin]

Je ne vois pas c koi le rapport avec la normalisation de la bd et la programmation POO. Je me suis rendu compte à travers cette discussion qu'il y a des pelleteux de nuage.

A chaque fois que je vois qu'il y a un nouveau post, je me dis "Chouette, quelqu'un viens de poster une réponse CONSTRUCTIVE qui va me permettre de savoir comment je pourrais ORAGANISER mes bases de données pour avoir les meilleures PERFORMANCES". Mais non, à chaque fois je me retrouve au milieu d'un débat qui n'a absolument rien à voir...

Je suis désolé pour toi. C dommage...