Discussion :

[Toldy]

Bonjour,

J'opère en ce moment sur une table dont l'id est composé de plusieurs champs qui peuvent parfois être à null.
Lorsque je faire une requête par SQL Explorer, par exemple, ça marche très bien.
Par contre, en passant par mon application Web, j'ai une erreur Java NullPointerException qui est due à ces id nuls.

Je n'arrive pas a savoir si c'est une propriété des beans (car mon POJO en est un) ou d'Hibernate qui produit ce résultat.

Est-ce que quelqu'un aurait déjà eu ce type de problème ?

Pour le moment j'ai mis seulement un des champs de ma base en id dans mon POJO (qui lui n'est jamais null, mais pas unique non plus...) donc il y a des problèmes au niveau du résultat des requêtes (ce qui paraît normal).
Je dois donc trouver une solution viable.

Trois solutions:
- permettre d'avoir deux id identiques (illogique mais pourquoi pas)
- permettre d'avoir des colonnes à null dans l'id
- ajouter une autre colonne (sachant que la table prend environ 100.000 lignes de plus par mois, une colonne de laquelle on peut se passer n'a rien a faire ici)

Merci d'avance

[fr1man]

Un identifiant au sens clé primaire doit etre unique.
Soit tu peux le garantir avec un clé composée de plusieurs colonnes, soit tu utilises une sequence ou equivalent qui te garantit l'unicité.
Une clé composé de colonnes pouvant etre null est une bien mauvaise idée.

[Toldy]

Une clé composé de colonnes pouvant etre null est une bien mauvaise idée.

En quoi c'est une mauvaise idée ?

[fr1man]

http://www.developpez.net/forums/d78...ee-champ-null/

[Toldy]

Constructif dis-donc ...

Mais le post ne réponds pas à ma question !
Qui est

En quoi c'est une mauvaise idée ?

[fr1man]

Comme c'est expliqué dans le post que je t'ai relayé, les SGBD vont refuser les valeurs null dans les clés primaires.
Un clé est censé etre unique et non null.

Pour moi une donnée à null est une donnée facultative, qui n'a rien à faire dans une clé primaire.

[Toldy]

Je disais que cela ne réponds pas à ma question car en demandant "En quoi c'est un mauvaise idée ?" j'entendais "En quoi ce n'est pas logique".
Ce qui n'est pas expliqué dans le post.

C'est mauvais d'avoir sa définition de NULL non ?
Je te propose une définition plus officielle, pour raison de compatibilité, et d'adaptation (tout ça, tout ça...), ici : http://www.w3schools.com/sql/sql_null_values.asp.

Allons donc avec la définition que je t'ai donné.

Prenons une table imaginaire sur laquelle se baser.
Imaginons que j'ai une table CONTRATS_CLIENT qui à dans sa clé 4 données, (pouvant être nulles) nommées respectivement NOM_CLIENT, INTERMEDIAIRE_AVEC_CLIENT, CODE_TYPE_A, CODE_TYPE_B.

Un même client peut me contacter de deux manières (avec ou sans intermédiaire) il faut donc différencier c'est cas là.
De la même manière, ce client peut réaliser avec moi deux mêmes contrats de types différents.

On a donc 4 contrats différents devant êtres différenciés par leurs id.
La valeur NULL ne serait pas de bonne augure ici ?

Merci d'avance pour ton aide.

[fr1man]

Je ne trouve pas logique de mélanger des règles métier avec la création de ta clé.
Perso je ne le ferais pas comme ça.
Soit mon contrat possède un numéro unique, ce qui très probable.
Soit je gère cette table avec une clé technique, séquence ou autre.

[jeffray03]

Une clé est un identifiant unique et non null, donc par cette definition ne peut pas etre null. Mauvaise idée car cela ne repondrait plus au critere d´identifiant.
Et comme dit ton lien, NULL = missing unknown Data. Donc ne peut etre un identifiant.

[Ithildine]

Généralement, quand ce qui m'apparait comme étant la clef primaire naturelle d'un objet comporte plusieurs champs dont certains peuvent être null (ou encore peuvent être des dates), je préfère utiliser une clef technique (séquence Oracle, ou autre générateur de nombre ou de UUID) et, éventuellement, je définis ensuite une contrainte d'unicité sur les champs que j'avais envie d'utiliser comme clef primaire composée.
Ceci aboutit généralement à la création d'un index unique (aussi efficace que celui d'une clef primaire), me garantit l'unicité de ce n-uplet sur mes entités et m'évite les problèmes de nullité d'un champ de clef primaire.

Dans cette situation, il m'arrive aussi de me demander si je comprends bien le problème fonctionnel, si je n'ai pas raté un truc sur le contrat fonctionnel de ma classe/entité.