Discussion :

[cotede2]

Bonjour , je vais reposer un post que j'ai mis hier en anglais désolé.

Donc ici je vais parler de concept objet et base de données.
Plusieurs solutions s'offrent à notre équipe de développement . (je travaille avec des américains).

Le site concerne des millions d'utilisateurs.
Les utilisateurs seront de trois types

1. Business
2. Artist
3. Fan ou Autres

Sachant que chaque type a ses caractéristiques et que chaque utilisateur a des champs communs.

Un utilisateur a forcément un username , un password , email , adresse...

Un artist joue d'un instrument , a un genre de musique ....

Un business a un site internet , fax , hours of operation , method payments.....

Un fan a un artiste préféré ......

Donc on voit bien que chaque type d'utilisateur hérite d'une entité commune (abstraite ou non ..) user.

Comment implémenter cela de la meilleure manière tout en prenant en considération que la base de données sera gigantesque ! Que l'on veut optimiser l'espace disque , les temps de requetes ( les jointures attention) et surtout pouvoir facilement modifier le modèle.


J'ai lu cet article

une table par entité? une table unique ?
Mon collègue suggère d'utiliser une unique table d'utilisateurs avec tous les critères possibles avec un champ qui indique le type et de laisser vides les champs inutiles (un artist n'a pas d'hours of operation . Un business ne joue pas d'instrument)...

Il dit que laisser NULL ne prend pas de place alors qu'utiliser différentes tables va forcément prendre plus de place (duplication des ID integer a 32 bits fois A million.... (dans users et business , dans users et artist et eventuellement dans users et fans)) et que les temps de requetes seront plus longs (JOINTURES).

Est ce que laisser NULL prend de la place? Si non alors ça semble plus optimisé au niveau temps de requête et espace disque mais qu'en est-il du modèle? Est ca facilement modifiable si demain nous avons un nouveau type?
Il suffirait d'ajouter des champs dans la table users?

Merci beaucoup pour votre aide.

[TheLeadingEdge]

Bonjour,

Comment implémenter cela de la meilleure manière tout en prenant en considération que la base de données sera gigantesque ! Que l'on veut optimiser l'espace disque , les temps de requetes ( les jointures attention) et surtout pouvoir facilement modifier le modèle.

A propos de la démarche :
C'est 1 MCD que tu veux faire. A ce stade on est dans un monde parfait. Tu ne devrais pas encore t'embarrasser de considérations physiques. Tu dois t'attacher à modéliser de façon idéale les besoins exprimés.
Par la suite, en fonction des contraintes physiques, il est possible de procéder à une dénormalisation contrôlée de ton modèle. Rien n'impose que le MPD soit la traduction exacte de ton MCD.

Mon avis sur le schéma avec 1 seule table :
Avec seule table ''membre'' tu prends 1 risque avec la qualité des données. Les colonnes propres à chaque type devant être ''nullable'' tu vas plus que certainement te retrouver avec des instances de ''businness'' ou de ''artist'' ayant uniquement les colonnes de ''members'' renseignées (règle n°1 : ne jamais faire confiance à l'utilisateur).
Si tu rajoutes 1 nouveau type de ''membre'', il faudra modifier la description de la table et réinitialiser les données des membres existant déjà.
Si tu spécialises, tu n'as rien à faire (enfin si, créer la table dans le schéma quand même, mais ça n'a pas d'impact sur les données déjà présentes).

(duplication des ID integer a 32 bits fois A million....

Tu ne crééra une référence à ''membres'' que si tu créé un ''businness' ou un ''artist'', la volumétrie n'est certainement pas de l'ordre du million. Et puis franchement on n'est plus à l'époque ou on stockait l'année sur 2 caractères parce qu'on avait des disques de 500mo et 1mo de ram.

Pour répondre à 1 passage de ton message initial : Si tu ne fais pas référence à ''Business'' et ''Artist'' dans ''Member'' mais que tu mets uniquement une contrainte référentielle vers ''Member'' dans ''Artist'' et ''Business'', tu n'auras à faire qu'1 seul insert dans ''business'' ou ''artist'' pour transformer ''Member'' en ''Business''. Encore 1 fois le pb ce sont les nulls.

les temps de requetes seront plus longs (JOINTURES).

Niveau perf, quand tu vas rechercher 1 ''artist'' ou 1 ''businness'' tu devras les sélectionner parmi les (millions ) de ''members''. Si tu spécialises, la jointure éliminera d'office les membres qui ne sont pas du bon type.

Il dit que laisser NULL ne prend pas de place

pose la question sur les conséquences dans le forum Bases de données

[cotede2]

merci pour tes réponses mais je n'ai , à vrai dire , rien appris.
Je connais la différence entre le modèle logique et physique , les jointures auront forcément des conditions WHERE.
Reinitialiser les données ne pose pas de problème , si on ajoute un type par an.

[Luc Orient]

...
Il dit que laisser NULL ne prend pas de place ...

Sur le plan théorique ça prend même plus de place puisque qu'on a la place pour la colonne elle-même et en plus la place pour un indicateur de null (1/2 octet par exemple).

Après, sur le plan pratique, je pense qu'on doit pouvoir bénéficier des éventuelles techniques de compresssion du SGBD si ce dernier les gère voire même de celles au niveau du disque. Et c'est vrai que les données dans ces colonnes à null sont de tout à fait élégibles à ce type de compression ...
Mais là on est vraiment à un niveau physique.

Pour moi, le choix de rendre un colonne "nullable" doit toujours être un choix de conception ...

[deltree]

Bonjour,
d'abord d'un point de vue conception, je fait un MCD non objet, en découpant pour normaliser,on obtient 4 entités:
- business
- artist
- fans
- connection

donc les 3 acteurs, et leurs données communes de connexion, extraites suite à une phase de normalisation.
si on applique simplement le MPD on a donc 4 tables, avec l'idConnection dans les 3 premières pour faire l'association.

Dans l'avis de TheLeadingEdge, moi je comprend qu'on privilégie la solution normalisée si elle suffisament performante, et si c'est ça je suis d'accord:

Tout mettre dans une table ne fait pas gagner grand chose (4 octets par User alors que rien que l'id peut faire 8 ou 12 octets minimum c'est 3 fois rien) et en plus cela va faire une grande table dans laquelle tu va souvent sélectionner uniquement une partie des éléments soit artiste, soit business;
tu risque d'avoir beaucoup plus de fans que d'artites, et la consultation des artites va être pénalisée par le nombre de fans par exemple.

Si vraiment il y avait un optimisation à faire pour éviter l'id, je créerait les 3 tables pour ne pas mélanger les fans (beaucoup de personnes à priori) et les business et artistes (beaucoup moins de personnes et de mouvement de création)

"Il dit que laisser NULL ne prend pas de place"
ça dépend de la base et il faut voir avec les DBA: par exemple chez nous sous DB2 on met tout en fixe parce que c'est plus optimal, et donc on prend la même place que ce soit null ou pas.