Discussion :

[ymoreau]

Bonjour,
J'ai encore une question très vague ! J'ai une base dans laquelle je vais stocker des éléments, et il y aura d'une part les éléments déjà acquis, d'autre part les éléments non acquis mais souhaités à l'avenir. Donc qu'ils soient acquis ou non les éléments devront stocker exactement la même chose, seulement ils ne seront pas utilisés au même moment (je n'aurai jamais besoin de regrouper les éléments acquis et non acquis).

Est-ce que donc il vaut mieux utiliser 2 tables de même structures distinctes pour faire appel à l'une ou l'autre selon le besoin, ou alors tout mettre dans une seule table avec un attribut indiquant à quelle groupe appartient l'élément ?

Et autre question, si jamais j'avais besoin d'ajouter un attribut aux éléments non acquis (et seulement eux), est-ce que cela changerait la donne ou la décision serait la même ? (à savoir laisser le champ NULL pour les éléments acquis dans le cas d'une table commune)

Merci d'avance de vos avis.

[fsmrel]

Bonjour,

Est-ce que donc il vaut mieux utiliser 2 tables de même structures distinctes pour faire appel à l'une ou l'autre selon le besoin, ou alors tout mettre dans une seule table avec un attribut indiquant à quelle groupe appartient l'élément ?
[...]
si jamais j'avais besoin d'ajouter un attribut aux éléments non acquis (et seulement eux), est-ce que cela changerait la donne ou la décision serait la même ? (à savoir laisser le champ NULL pour les éléments acquis dans le cas d'une table commune).

Utilisation de deux tables

Si vous utilisez deux tables (appelons-les par exemple ELEMENT_ACQUIS et ELEMENT_NON_ACQUIS), vous « dépliez » les concepts et sémantiquement on y voit plus clair. Pas besoin de gérer un booléen (appelons-le par exemple STATUT) indiquant le statut d’un élément (acquis/non acquis).

Par ailleurs, au lieu de manipuler une table volumineuse (les SGBD ayant la fâcheuse habitude de fabriquer des enregistrements physiques à l’image des lignes des tables (non respect du principe de l’indépendance logique / physique)), vous manipulez deux tables moins copieuses (donc réduction du temps de la durée des tâches de service (sauvegardes, réorganisations, etc.) qui par ailleurs peuvent être exécutées en parallèle.

De même, toujours au niveau physique, vous réduisez la taille des index, donc le nombre de leurs niveaux (hauteur d’arbre), donc le nombre de lectures/écritures physiques pour accéder aux données.

Par ailleurs vous réduisez les contentions en cas d’accès concurrents de la part des utilisateurs de la base de données. Vous pouvez aussi définir des privilèges pour chaque table.

En outre, vous avez toujours la possibilité de créer une table virtuelle (vue) qui soit l’union des deux tables, à l’usage des utilisateurs qui ne veulent « voir qu’une tête ».

En plus, puisqu’une table doit être dotée d’attributs sans objet pour l’autre, la mise en œuvre correspondante est simple et propre.

Inconvénient : quand un élément change de statut, il ya une opération relativement lourde qui est déclenchée, à savoir créer une ligne dans la table ELEMENT_ACQUIS et supprimer une ligne dans la table NON ACQUIS. Attention à votre système d’identification : si vous voulez que l’ancien élément conserve sa valeur de clé primaire, il y aura risque de doublonnage.

Utilisation d'une seule table

Si vous n’utilisez qu’une table, appelons-la ELEMENT, vous repliez les concepts. Le booléen STATUT devient nécessaire. Au plan physique, on perd les avantages évoqués ci-dessus. Les risques de contention sont plus élevés. Si vous voulez définir des privilèges, vous devrez définir des vues (appelons-les par exemple ELEMENT_ACQUIS et ELEMENT_NON_ACQUIS) et forcer les utilisateurs à les utiliser.

En ce qui concerne les attributs spécifiques aux éléments non acquis : il faut éviter de les définir dans la table ELEMENT car cela la fait grossir inutilement et vous allez polluer la table avec le Bonhomme NULL qui est un ennemi farouche des optimiseurs des SGBDR et arrive à faire patiner l’algèbre relationnelle. Je vous conseille d'isoler ces attributs dans une table à part (appelons-la par exemple ELEMENT_NON_ACQUIS_SPECIFIQUE). En contrepartie, vous devrez gérer par trigger la cohérence du booléen STATUT et la présence de données dans la table ELEMENT_NON_ACQUIS_SPECIFIQUE (à moins de ne pas définir d’attribut STATUT et que la présence de données dans la table ELEMENT_NON_ACQUIS_SPECIFIQUE suffise à caractériser l’alternative (acquis / non acquis).

Etc.

[ymoreau]

Merci pour cette réponse détaillée !
Intuitivement je trouvais les 2 tables séparées plus efficaces, mais je ne sais pas pourquoi j'avais dans l'idée qu'il était déconseillé de "dupliquer" les structures dans une base.

[fsmrel]

j'avais dans l'idée qu'il était déconseillé de "dupliquer" les structures dans une base.

Attention, il n'y a pas d'absolu ès matière...

[CinePhil]

Peut-être faut-il réfléchir un peu plus loin que ces deux seules tables ?
Je suppose qu'elles sont issues d'entité(s) associée(s) à une ou plusieurs autres entités ?

Sans préjuger de ce que représente le concept "Elément", je peux supposer que ces notions "acquis" et "non-acquis" peuvent résulter en fait d'une association par exemple entre une personne et un élément :
Personne -0,n----Acquérir----0,n- Elément

Dès lors, cet extrait de MCD donnera une seule table Elément et une table associative entre Elément et Personne :
Personne (P_Id, P_Nom, ...)
Element (E_Id, E_Nom...)
Acquerir (A_IdElement, A_IdPersonne, ...)

Si vous nous en dites plus sur votre cas concret, peut-être pourrons-nous vous orienter sur un modèle de données plus adéquat que celui vous conduisant à créer deux tables avec les mêmes colonnes, ce que personnellement j'éviterais de faire. Tout dépend de la volumétrie et des accès concurrents, les raisons évoquées par fsmrel pour préférer les deux tables n'étant significatives qu'à partir d'un volume et d'une activité significativement importante à mon avis.

[chaplin]

C'est un peu comme une forme d'héritage, avec une contrainte d'exclusion, mais il n'y a pas d'attributs pour départager l'un et l'autre au niveau des sous-types.

[fsmrel]

C'est un peu comme une forme d'héritage, avec une contrainte d'exclusion, mais il n'y a pas d'attributs pour départager l'un et l'autre au niveau des sous-types.

Si l’on remonte au niveau conceptuel, ça a évidemment un goût d’héritage. Toutefois, l’héritage est caractérisé par la stabilité des entités-types et n’est pas fait pour modéliser des changements d’état.

Mais admettons que l’on passe outre et que l’on décide de modéliser au niveau conceptuel en utilisant l’héritage :

Lors de la dérivation au niveau logique, un AGL comme Power AMC propose plusieurs options pour produire la structure des tables, dont celle qui consiste à tout ventiler dans des tables distinctes.

Mais comme je l'ai déjà précisé, il n'y a pas d'absolu ès matière et YoniBlond a le choix.

[TheLeadingEdge]

l’héritage est caractérisé par la stabilité des entités-types et n’est pas fait pour modéliser des changements d’état.

L'héritage implique un trés fort couplage. Il ne devrait (doit) être utilisé que lorsque le lien entre les entités est immutable. Comme le fait remarquer Fsmrel, ''Acquis'' et ''non acquis'' ne sont pas des éléments mais représentent l'état d'un élément et c'est donc susceptible de changer.

D'après ceci

il y aura d'une part les éléments déjà acquis, d'autre part les éléments non acquis mais souhaités à l'avenir.

ce modèle

ces notions "acquis" et "non-acquis" peuvent résulter en fait d'une association par exemple entre une personne et un élément :
Personne -0,n----Acquérir----0,n- Elément

semble plus proche du besoin exprimé. Il manque juste une 2nde relation ''souhaiter''

si jamais j'avais besoin d'ajouter un attribut aux éléments non acquis[...]

C'est difficile de répondre avec si peu d'informations. Selon ce qu'ils représentent il serait possible soit de les rajouter dans la relation ''souhaiter'', soit de spécialiser ''éléments''. Pour de bon cette fois. Un élément non acquis étant un élément avec des propriétés supplémentaires.

[ymoreau]

Pour préciser mon cas, il y a association avec des personnes mais pour tous les éléments, une personne a une liste d'éléments acquis et une liste d'éléments à acquérir. Chaque élément est propre à une personne, donc je ne pense pas qu'une table liant des clés de personne et des clés d'éléments soit utile (autant placer la clé étrangère de la personne directement dans la table élément non?).

Et je préférerais partir du principe que les tables seront grandes, car en fonction du nombre de personnes le nombre d'éléments augmentera exponentiellement.

Ensuite comme je l'ai dit au début du post, les ensembles acquis/non-acquis ne seront pas utilisées en même temps (comprendre, jamais lus ensemble dans une même requête). Par contre en effet un élément pourra basculer de "non acquis" à "acquis", ce qui avec 2 tables oblige à faire une copie, mais ce cas devrait être largement moins fréquent que la lecture des éléments d'une personne.