Discussion :

[Proxy]

Bonjour,

Je voudrais ajouter une clé étrangère sur une table, pour l'exemple : table_client.

Cette table contient plusieurs champs :
- client_id
- client_name
- adresse_id

Afin de la lier à une table, ici table_adresse :
- adresse_id
- status
- rue
...

Le problème est que le champ adresse_id n'est pas unique, il est présent plusieurs fois. La clé primaire étant sur le duo : adresse_id, status.

Je voudrais donc créer cette clé étrangère sur la table_client avec comme lien : adresse_id et une constante pour le status = 0. Ceci sans vouloir ajouter un champ toujours égal à 0 dans ma table_client.

NB : J'ai simplifié l'exemple en prennant un cas d'école client/adresse, mais dans mon cas ça touche d'autres tables qui sont utilisées par plusieurs process. Repenser la solution totale pour la table_adresse n'est donc pas possible.

[mnitu]

Votre modèle de données semble en souffrance. Vous pouvez implémenter cette contrainte à l’aide des triggers mais cette solution devient souvent une source de nombreuses erreurs en plus des autres désavantages.

[pachot]

Bonjour,
En 11g on a la possibilité de colonne virtuelle (non stockée).
Et elle peuvent être utilisées comme foreign key:
Dans votre cas:

create table table_client (client_id number,adresse_id number,adresse_status as (0),foreign key(adresse_id,adresse_status)references table_adresse )

Cordialement,
Franck.

[Chtulus]

Bonjour,

Votre question est plutôt bien postée, certes

Mais fournissez au mieux les DDL de vos tables afin de bien comprendre votre situation, vos besoins et votre demande.

NB : J'ai simplifié l'exemple en prennant un cas d'école client/adresse, mais dans mon cas ça touche d'autres tables qui sont utilisées par plusieurs process. Repenser la solution totale pour la table_adresse n'est donc pas possible.

Ce que l'on conçoit bien s'énonce clairement !

De plus un "id" non atomique surtout une adresse c'est
Il y a moyen de faire mieux !

Et dire que repenser une solution, comme dans votre cas, n'est pas possible, c'est juste idiot (Je ne dis pas cela pour vous personnellement mais dans la majorité des cas, rien n'est prévu au départ pour faire de bonnes choses ).
Je le sais bien je travaille avec des Bases irréelles tous les jours

[Proxy]

Bonjour,

Merci pour vos réponses!

Je travaille dans une société dont la base de données est 'historique' et utilisée par de nombreuses équipe... Modifier la structure entrainera de la régression dans trop de points.

Il s'agit d'une table de services et non d'adresse, chaque service a son identifiant mais peut évoluer. On a un status pour donner la version active.

Cela ne change rien au problème posé.

Et oui, les bases réelles sont posées et souvent pas très bien pensées.

Actuellement, on ne fait jamais de clé étrangère sur cette table, on espère juste que les jointures soient bien faites... Ici je dois réaliser une nouvelle table et je voudrais justement pouvoir éviter cette manière de faire pour avoir un minimum de cohérence... Si c'est possible.

pachot :

Merci, mais je ne suis pas sous 11g, existe-t'il une solution similaire en 8-10g?

Si pas, je crois que la solution de mnitu sera la meilleur.

[pachot]

Alors en <11g, pas de colonnes virtuelles. Il faut stocker la valeur même si elle est constante. Stocker un zéro, ça prend seulement 1 octet...

Ne pas oublier d'avoir un index qui a les colonnes de la foreign key au début (constante inclue) pour éviter de bloquer la table fille pendant qu'on change le status d'une adresse. D'ailleurs, même en 11g avec colonnes virtuelles l'index doit stocker la valeur.

Personnellement, je ne voit pas de défaut à cette modélisation.
Isoler les adresses qui ont un status=0 dans une autre table n'est pas une bonne solution si on interroge souvent l'ensemble des adresse quel que soit le status.

Implémenter de l'intégrité référentielle par des triggers n'est pas une bonne idée non plus, car à cause de l'isolation des transactions, il faudra souvent verrouiller toute la table.

[Proxy]

Ok, merci Pachot,

Je vais créer cette colonne supplémentaire sur la nouvelle table. Je voulais éviter d'encombrer celle-ci mais cette solution semble la meilleur.

Merci.