Ok, merci pour la réponse.

Je vais essayer ça et je donne la réponse dès que je trouve.

A bientôt et encore merci.

Je vais creuser ton idée qui ne me semble pas mauvaise.

Mais puisque mon job principal n'est pas la programmation, je ne te promet pas une réponse dans l'immédiat !

bientôt.

Je pense qu'il existe une autre solution que celle de Vince.

stocker toutes ces infos dans UN champ numérique mais sous forme de Bits (avec les instructions Oracle SetBit et GetBit pour les récup après)

chaque bit est à considérer comme un flag qui peut être à ON/OFF
Il suffit de décider par convention ce que signifie le bit 0, le bit 1, le bit 2 etc.

on utilise ce système pour pas mal de données chez nous et c'est très efficace et très très performant et surtout facilement extensible
(genre ah tiens, une nouvelle information à retenir : si la personne a fait la formation xyz, bien actuellement on a 6 formations différentes possibles, donc on utilise les 6 premiers bits (de 0 à 5) et bien ok, on décide que le bit 7 dit maintenant si on a suivi la formation XYZ ou pas, pas besoin de créer une nouvelle colonne.)

J'insiste sur les perfs aussi , surtout si on commence à jouer avec des bitmasks etc (mais pas obligé d'aller si loin)

en résumé disons qu'on décide par convention que
-compétences en math : bit 0
-compétences en français : bit 1
-compétence en chimie bit 2

Monsieur Patate est compétent en math  :
Update MaTable set MonChamp = SetBit(SetBit(SetBit(MonChamp, 0, 1),1,0),2,0)
// Mets le bit 0 à 1 et le bit 1 & 2 à 0

Dernière modification par rincevent (05-06-2009 15:09:25)

BeN1968 a écrit:

Bonjour,

Je viens de vérifier... SetBit n'existe pas en PB6...

Désolé, mais ça m'avait l'air faisable !

Je cherche encore !!

c'est normal...

Rincevent a écrit:

avec les instructions Oracle SetBit et GetBit

par contre je pensais que c'était des fct° Oracle de base mais non , c'est des fonctions à nous. :-)

fonction get bit  :

CREATE OR REPLACE Function VIPER.GETBIT (r_value Binary_Integer, i_pos Pls_Integer)
Return Pls_Integer
Is
Begin
  -- Return Mod(trunc( r_value / (POWER(2,i_pos)) ),2) ;
  If bitand(r_value,POWER(2,i_pos)) > 0 Then
    Return 1;
  Else
    Return 0;
  End If;
End GETBIT;

fonction setbit  :

CREATE OR REPLACE Function VIPER.SETBIT (r_value Pls_Integer, i_pos Pls_Integer, i_state Pls_Integer)
Return Pls_Integer
Is

r_power      Pls_Integer;

Begin
  r_power := POWER(2, i_pos );
  If i_state = 0 Then
    If bitand(r_value, r_power) > 0 Then
      Return r_value - r_power;
    Else
      Return r_value;
    End If;
  Else
    If bitand(r_value, r_power) > 0 Then
      Return r_value;
    Else
      Return r_value + r_power;
    End If;
  End If;
  
  Return Null;
End SETBIT;

un peu Radin Oracle sur les fonctions basiques je trouve ^^

Dernière modification par rincevent (08-06-2009 08:58:01)

Chrnico a écrit:

Dans notre cas, savoir que Mr X à les diplôme A, B ou C c'est bien. Mais peut-être que la date d'obtention du diplôme, un flag signalant qu'une copie a été fournie, le lieu d'optention vont être des informations à stocker dans cette "relation" personne/diplôme. Et comment fait-on tenir tout cela si nous avons utilisé un seul bit au départ pour formaliser une relation personne/diplôme?

En ce qui concerne la date et le lieu d'obtention du diplôme, c'est déjà prévu ! La copie d'un diplôme n'est pas importante dans la gestion, elle le devient lorsque la personne est engagée.  Et lorsque la personne est engagée, je l'encode dans un logiciel spécialisé (écrit en Windev avec une db access) programmé par une société spécialisée et qui fourni ce logiciel à une grosse partie des école (du fondamental aux universités).

Pour revenir à mon problème, quels champs dois-je mettre dans ma table 'diplôme' ?  Un id_diplôme, un intitule_diplôme, et... ???  Là je bloque, car je rappelle qu'une personne peut avoir 2 ou 3 (max) diplôme(s) et qu'on peut 'mélanger' les diplômes (primaire + maternelle ; primaire + immersion néerlandais (nous sommes en Belgique) ; primaire + option religion (pour ceux et celles qui ont fait leurs études dans l'enseignement officiel) ; gym + psychomotricité ; maternelle + psychomot. ; etc...).

Bref, c'est un 'melting pot' de diplômes comme ont dit chez nous !

La solution de Chrnico est la meilleur. Elle permet une plus grande évolution, elle est plus facile à manipuler et tout le monde la comprendra.

Chrnico a écrit:

A noter que la clé primaire de la relation diplome_personne pourrait être une clé composite constituée de per_id et dip_id sans avoir à ajouter un dpp_id. Seulement dans ce cas, les deux identifiants seront propagés dans les tables faisant référence à la relation diplome_personne (ce qui n'est pas faux en soit)

C'est en général la solution que je prend. Cela évite de gérer des cas de doublons de diplomes car ils sont interdit par ta clé primaire. Tu ne gère que les rejets d'insertions.

rincevent a écrit:

Rho lol, dis tout de quite que la mienne elle pue parceque vous la comprenez pas ^^

J'ai l'impression que je t'ai vexé

Ta solution semble très intéressante, et sans doute performante, mais pour affecter 1 ou 2 diplomes à un enseignant dans une appli de gestion, la solution de Chrnico me semblait plus adapté et surtout plus lisible.

Rincevent, tu as dans la tête une méthode tellement complexe que tu ne peux pas la prononcer (référence au vrai Rincevent)

Ta solution est idéal pour stocker un nombre important de flag dans un même champ. Une suite de oui/non dont la signification est déterminée par la position du bit. Si Ben était certain de n'avoir à stocker que l'information "a le diplôme 1, a le diplôme 2, a le diplôme 3, etc.." se serait parfait. Quoi que pas franchement lisible pour ceux qui reprennent derrière puisque la position du bit à une signification fonctionnelle pas facile à déterminer. C'est une convention qui doit être documentée...

Par ailleuirs, faire du relationnelle n'est pas une solution pour débutant comme tu semble le penser. C'est simplement le seul moyen que tu as de représenter une relation entre deux entités. Notre amis ben1968 n'étant pas informaticien, il me semble judicieux de l'orienter vers un système qu'il pourra faire évoluer si ses besoins évolus. A savoir stocké des données dépendantes à la fois de la personne et du diplome....

Dans tous les cas désolé si nos échanges ont pu te vexer. Ce n'était pas intensionnel.

Ce ne serait pas chez STE-Formations que tu as appris PB ?

promotion 2009 ... Je suis en fin de stage ;)

ok ;)

vince.janssens a écrit:

Sur ce, j'ai également suivi une formation PB à Liège il y a de çà près de 12 ans (Je suis un ancien de chez FICS pour ceux qui connaissent) :-)
Le monde il est petit...

A+

Vincent

Mais qui ne te connais pas Vincent, j'ai d'ailleurs travaillé chez FICS en même temps que toi !!!

Je me demande même si nous ne faisions pas la route ensemble (avec Yves, Alain, Fabian...)

Sur ce, je fais une compile de tout les messages que je viens d'avoir à propos de mon problème et je programme pendant mes deux mois de vacances !!