Quand dois-je avoir recours à une relation individuelle ?

Question

Désolé pour cette question de novice, mais y a-t-il un réel besoin d'utiliser une relation univoque avec les tables de votre base de données ? Vous pouvez implémenter tous les champs nécessaires dans une seule table. Même si les données deviennent très volumineuses, vous pouvez énumérer les noms de colonnes dont vous avez besoin dans le fichier SELECT au lieu d'utiliser l'instruction SELECT * . Quand avez-vous vraiment besoin de cette séparation ?

Answer 1

1 à 0..1

• La relation "1 à 0..1" entre les super-classes et les sous-classes est utilisée dans le cadre de la stratégie "toutes les classes dans des tableaux distincts" pour la mise en œuvre de l'héritage .

• Une relation "1 à 0..1" peut être représentée dans une table unique dont la partie "0..1" est couverte par des champs à valeur NULL. Toutefois, si la relation est la plupart du temps Dans le cas d'une base de données "1 à 0" ne comportant que quelques lignes "1 à 1", la séparation de la partie "0..1" dans une table distincte pourrait permettre de gagner en stockage (et en performance de cache). Certaines bases de données sont plus économes que d'autres en ce qui concerne le stockage des NULL, de sorte que le "seuil" à partir duquel cette stratégie devient viable peut varier considérablement.

1 à 1

• Le vrai "1 pour 1" partitionne verticalement les données, ce qui peut avoir des implications pour la mise en cache. Les bases de données mettent généralement en place des caches au niveau de la page, et non au niveau des champs individuels, de sorte que même si vous ne sélectionnez que quelques champs d'une ligne, c'est généralement toute la page à laquelle appartient cette ligne qui sera mise en cache. Si une ligne est très large et les champs sélectionnés relativement étroits, vous finirez par mettre en cache un grand nombre d'informations dont vous n'avez pas réellement besoin. Dans une telle situation, il peut être utile de partitionner verticalement les données. seulement la partie ou les lignes les plus étroites et les plus fréquemment utilisées sont mises en cache, de sorte qu'un plus grand nombre d'entre elles peuvent tenir dans le cache, ce qui rend le cache effectivement "plus grand".

• Une autre utilisation du partitionnement vertical consiste à modifier le comportement de verrouillage : les bases de données ne peuvent généralement pas verrouiller au niveau des champs individuels, mais seulement les lignes entières. En divisant la ligne, vous autorisez un verrouillage sur une seule de ses moitiés.

• Les déclencheurs sont aussi généralement spécifiques à une table. Bien que vous puissiez théoriquement n'avoir qu'une seule table et faire en sorte que le déclencheur ignore la "mauvaise moitié" de la ligne, certaines bases de données peuvent imposer des limites supplémentaires sur ce qu'un déclencheur peut et ne peut pas faire, ce qui pourrait rendre cette solution impraticable. Par exemple, Oracle ne vous permet pas de modifier la table qui mute - en ayant des tables séparées, seule l'une d'entre elles peut muter, de sorte que vous pouvez toujours modifier l'autre à partir de votre déclencheur.

• Des tables séparées peuvent permettre une sécurité plus granulaire.

Ces considérations ne sont pas pertinentes dans la plupart des cas, et vous devriez donc envisager de fusionner les tableaux "1 à 1" en un seul tableau.

Voir aussi Pourquoi utiliser une relation 1 à 1 dans la conception d'une base de données ?

Answer 2

Si vous placez deux tableaux univoques dans un seul, il est probable que vous aurez un problème de sémantique. Par exemple, si chaque appareil dispose d'une télécommande, il n'est pas très judicieux de placer l'appareil et la télécommande avec leurs nombreuses caractéristiques dans un même tableau. Vous devrez peut-être même passer du temps à déterminer si un certain attribut appartient à l'appareil ou au contrôleur à distance.

Dans certains cas, la moitié de vos colonnes resteront vides pendant un long moment ou ne seront jamais remplies. Par exemple, une voiture peut avoir une remorque avec un certain nombre de caractéristiques, ou n'en avoir aucune. Vous aurez donc de nombreux attributs inutilisés.

Si votre table comporte 20 attributs et que seuls 4 d'entre eux sont utilisés occasionnellement, il est judicieux de la diviser en deux tables pour des raisons de performances.

Dans ce cas, il n'est pas judicieux de tout regrouper dans un seul tableau. En outre, il n'est pas facile de traiter un tableau comportant 45 colonnes !

Answer 3

Si les données d'une table sont liées à l'entité décrite par l'autre table, mais ne lui "appartiennent" pas, il convient de les séparer.

Cela pourrait présenter des avantages à l'avenir, si les données distinctes doivent également être liées à une autre entité.

Answer 4

Le cas le plus judicieux serait celui de deux concepts distincts qui ne seraient jamais liés que de cette manière. Par exemple, une voiture ne peut avoir qu'un seul conducteur, et le conducteur ne peut conduire qu'une seule voiture à la fois - la relation entre les concepts de voiture et de conducteur serait donc de 1 à 1. Je reconnais qu'il s'agit d'un exemple inventé pour démontrer le point.

Une autre raison est que vous souhaitez spécialiser un concept de différentes manières. Si vous disposez d'une table Personne et que vous souhaitez ajouter le concept de différents types de personnes, tels qu'employé, client, actionnaire, chacun d'entre eux nécessitera des ensembles de données différents. Les données similaires se trouvent dans la table Personne, tandis que les informations spécialisées se trouvent dans les tables spécifiques Client, Actionnaire et Employé.

Certains moteurs de base de données ont du mal à ajouter efficacement une nouvelle colonne à une très grande table (beaucoup de lignes) et j'ai vu des tables d'extension utilisées pour contenir la nouvelle colonne, plutôt que d'ajouter la nouvelle colonne à la table d'origine. C'est l'une des utilisations les plus suspectes des tables supplémentaires.

Vous pouvez également décider de répartir les données d'un même concept entre deux tables différentes pour des raisons de performance ou de lisibilité, mais il s'agit là d'un cas assez particulier si vous partez de zéro - ces questions apparaîtront plus tard.

Answer 5

Pas très souvent.

vous pouvez en tirer des avantages si vous devez mettre en place une certaine sécurité - ainsi certains utilisateurs peuvent voir certaines colonnes (table1) mais pas d'autres (table2) .

Bien entendu, certaines bases de données (Oracle) permettent ce type de sécurité dans la même table, mais d'autres ne le permettent pas.