Si par table PIVOT
vous voulez dire une table de lien many-to-many
, alors non, cela ne fera que nuire aux performances.
Vous devez conserver parent_id
dans la table enfant.
La table de liens many-to-many
prend un JOIN
supplémentaire et est donc moins efficace.
Comparez les requêtes suivantes:
SELECT *
FROM child_table c
JOIN child_to_parent cp
ON cp.child = c.id
JOIN parent p
ON p.id = cp.parent
WHERE c.property = 'some_property'
et celui-ci:
SELECT *
FROM child_table c
JOIN parent p
ON p.id = c.parent
WHERE c.property = 'some_property'
Ce dernier est un que JOIN
plus court et plus efficace.
La seule exception possible à cette règle est que vous exécutez ces requêtes souvent:
SELECT *
FROM child_table c
JOIN parent_table p
ON p.id = c.parent
WHERE c.id IN (id1, id2, ...)
, i. e. vous connaissez au préalable les lignes id
des lignes enfant.
Cela peut être utile si vous utilisez des touches naturelles pour votre child_table
.
Dans ce cas oui, la table de lien child_to_parent
sera plus efficace, puisque vous pouvez simplement le remplacer par la requête suivante:
SELECT *
FROM child_to_parent cp
JOIN parent_table p
ON p.id = cp.parent
WHERE cp.child IN (id1, id2, ...)
et child_to_parent
sera toujours inférieure ou égale en taille à child_table
, et donc plus efficace.
Cependant, en Oracle
, vous pouvez obtenir le même résultat en créant un index composite sur child_table (id, parent_id)
.
Puisque Oracle
n'indexe pas NULL
, cet index sera exactement comme votre table child_to_parent
, mais sans la table elle-même et la surcharge de maintenance implicite.
Dans d'autres systèmes (qui indexent NULL
), l'index peut être moins efficace qu'une table dédiée, en particulier si vous avez beaucoup de NULL
parents.