Vous n'êtes pas identifié(e).
Bonjour,
J'ai une table partitionnée (héritage + triggers) dont certains champs référencent d'autres tables.
Les clés étrangères doivent elles être positionnées sur les tables filles qui héritent de la table mère ou vaut il mieux positionner les clés étrangères directement sur la table mère?
Merci d'avance pour vos réponses.
Cordialement.
Dernière modification par Kore (19/06/2014 14:20:22)
Hors ligne
Bonjour,
Les clés étrangères ne sont pas héritées : http://docs.postgresql.fr/9.3/ddl-inherit.html "Toutes les contraintes de vérification et toutes les contraintes NOT NULL sur une table parent sont automatiquement héritées par les tables enfants. Les autres types de contraintes (unicité, clé primaire, clé étrangère) ne sont pas hérités.".
Il faut donc les créer à minima sur chacune des tables filles. Avoir également la clé étrangère sur la table mère est préférable.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre réponse.
Le fait de positionner la contrainte sur la table mère et la table fille, est ce que ça ne fait pas redondance de vérification?
Une vérification de la contrainte via la table mère et une nouvelle vérification avec en quelque sorte la "même contrainte" via la table fille.
Hors ligne
Non pas du tout.
Vos données vont soit dans la table mère soit dans la table fille.
Je vous conseille de remplacer les triggers par les règles, si bien sûr vous n'êtes pas amené à faire des inserts massifs.
Dernière modification par Postgres.0 (20/06/2014 14:34:55)
Hors ligne
Définir les clés étrangères sur la table mères permet de s'assurer qu'en cas de bug sur le trigger (pas de redirection dans la bonne table) la contrainte soit quand même respectée. Cela permet également d'avoir un ensemble plus "cohérent", par exemple faire un \d+ sur la table mère donnera également la contrainte, ce qui est appréciable.
Pour ce qui est des règles, elles peuvent être effectivement plus efficaces en cas d'inserts massifs, mais d'expérience le prix pour la maintenance et le débuggage de règles fait que ça reste généralement à éviter.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour vos réponses
Donc si je résume :
- contraintes sur table mère et table fille
- triggers à privilégier pour les cas généraux
- règles pour les grosses insertions
Dernière question qu'entendez vous par une grosse insertion?
Une séquence d'INSERTs qui va insérer un tuple à la fois par instruction SQL
ou
une seule instruction INSERT qui va insérer le résultat d'un select (INSERT INTO matable SELECT * FROM matable2)
ou
les deux?
Désolé si ça vous paraît bizarre comme question mais je préfère être sûr d'avoir bien compris.
Cordialement
Hors ligne
Une grosse insertion est une insertion qui insère énormément de lignes en une seule fois, donc le 2ème exemple.
Le partitionnement se fera soit avec des triggers, soit avec des règles. Si 99% de votre application consiste à importer des données en une seule fois, le plus intéressant est encore de modifier votre traitement pour qu'il insère directement dans la bonne partition, et rester avec des triggers pour le reste de l'application.
Julien.
https://rjuju.github.io/
Hors ligne
SI vous optez pour les triggers, dans ce cas vous n'avez aucun souci à utiliser le COPY dans la table mère.
Si vous optez pour les règles, il faut faire le COPY directement dans la partition.
Hors ligne
Puisque le partitionnement n'est pas dynamique en Postgres, il est important d'avoir une clef étrangère sur la table mère.
Car si les données insérées doivent aller dans une partition qui n'a pas encore été crée, Postgres les envoie directement dans la table mère.
Dernière modification par Postgres.0 (26/06/2014 14:19:22)
Hors ligne
Merci pour toutes ces précisions.
Je prend note de vos réponses.
Cordialement.
Hors ligne
