Quel vision avez-vous de la valeur "poubelle"?

[pinocchio]

Dans un message précédant, j'ai lu ceci :

Envoyé par al1_24

Dans la pratique, on utilise souvent un identifiant "poubelle" (non défini, 9999, ...) dans la table de référence.
L'avantage est qu'on évite les jointures externes, et donc on diminue la charge système.
En plus, on évite de "perdre" des enregistrements si, par inadvertance, on utilise un INNER JOIN à la place du OUTER JOIN (outils de consultation mis à la disposition des utilisateurs...)

1) Je ne connaissais pas cette pratique
2) Je suis outré par cette pratique

Pour moi cette technique semble incohérente pour plusieurs raisons. La première est que cet identifiant peut prendre une valeur future (il suffit de le mette à -1 ou 0 et cela marche). La deuxième est que cela est la porte ouverte pour avoir une BDD poubelle ensuite car chacun utilisera cette valeur un peu n'importe comment. La troisième est que la valeur NULL est une valeur importante à mes yeux, ce n'est pas l'absence de valeur.
Voila à vos votes.

[nako]

Envoyé par pinocchio

1) Je ne connaissais pas cette pratique
2) Je suis outré par cette pratique

1) Je ne connaissais pas cette pratique
2) Je ne suis malheureusement presque plus étonné par ce genre de pratique ...
T'as pas souvent bossé avec des sagouins toi !

[alvain]

Je ne comprends pas la question...
Quelle différence fonctionnelle y a-t-il entre la valeur Null et la valeur 999 ?

[al1_24]

Il faut replacer les choses dans leur environnement peut-être...
Sur le papier, au moment de la conception d'une BDR, la valeur Null et les jointures externes sont la meilleure solution théorique.
Dans la pratique, dans un environnement Décisionnel / Entrepôt de données, où la moindre table de faits comporte quelques Tera-enregistrements (pour ceux qui l'auraient oublié, 1 tera=10**12), la jointure externe est bannie par les DBA, qui ont leur mot à dire sur la formulation des requêtes les plus courantes.

[pinocchio]

Jsutement, mon but c'est d'avoir l'avis de DBA.
Mais ils ne participent pas trop, dommage!!!

[laffreuxthomas]

Tout dépend. Par exemple, pour une table de thèmes :

Code :

1
2
3
4
CREATE TABLE Theme (
  theme_id integer NOT NULL PRIMARY KEY,
  pays_libelle varchar(100) NOT NULL UNIQUE
);

Il est parfaitement possible de laisser l'utilisateur ajouter une ligne "-indéfini-". Ceci lui permet de définir le libellé de la valeur indéfinie. Autrement ce libellé devrait être codé en dur.

[orafrance]

Moi j'ai du mal à voir un cas fonctionnel où on aurait besoin d'un identifiant bidon

Si quelqu'un veut bien m'éclairer avec un exemple concret je me ferais un plaisir de donner mon avis

[Médiat]

Envoyé par orafrance

Moi j'ai du mal à voir un cas fonctionnel où on aurait besoin d'un identifiant bidon
Si quelqu'un veut bien m'éclairer avec un exemple concret je me ferais un plaisir de donner mon avis

Exemple (pas hyper-fonctionnel ) : une table du personnel contient, entre autres, un IdPays et un IdRegion qui représente le lieu d'affectation du salarié, dans certains cas la région n'a pas de sens (le Vatican n'est pas découpé en régions). Jusque là, je ne vois pas l'intérêt de la valeur bidon, et NULL me convient parfaitement. Cette modélisation n'est pas parfaite (cf. Infra), mais on fait du décisionnel avec ce que l'on trouve...
Imaginons qu'à partir de ces données il faille créer une base décisionnelle (comme l'a fait remarquer al1_24 les volumes peuvent êtres énormes), avec une table de fait "Répartition géographique des Effectifs" dont la clé serait idéalement (IdPays, IdRegion), il me semble que la solution de créer une valeur 'N/A' dans le SI décisionnel qui correspondra à la valeur NULL du SI Opérationnel est simple et pratique, et évite les jointures externes.
Une autre solution consisterait à créer une entité LieuGéographique avec un héritage en Pays et Région, c'est d'ailleurs une solution que je préconiserais dans le cas du SI Opérationnel, mais pas pour le système décisionnel (calculer les agrégats par pays est beaucoup plus simple avec la première solution).