Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour à toutes et à tous,
Je voudrais savoir s'il est possible de concaténer plusieurs datas dans un même champs d'une table.
Je m'explique :
Je travaille dans une école et je gère les CV des enseignants de toute une zone administrative (Belgique). Sur certain CV, des personnes ont deux ou trois (rarement plus) diplômes (ex. : institutrice maternelle ayant fait une passerelle vers les primaires = 2 diplômes).
J'ai divers (+/- 11) 'checkbox' à deux états qui indiquent le diplôme que la personne qui envoie sont CV possède. Dans la table, j'ai un champs 'diplomes' et je voudrais y stocker 'M' comme maternelle et 'P' pour primaire (pour reprendre mon exemple).
Est-ce possible ? Si oui, comment faire ?
Hors ligne
Bonjour, en codant ça en Powerscript oui, directement par manipulation dans la DW, je ne vois pas comment...
Hors ligne
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.
Hors ligne
Bonjour,
Cela ressemble plus à un problème de conception.
Si un champs base de donnée doit contenir plusieurs données, cela indique qu'il faille créer une table supplémentaire (qui contiendra dans ton cas la liste des diplômes que possède chaque employé).
Au niveau datawindow, il s'agira simplement d'une liste de diplôme obtenu qu'on pourrait ajouter en fonction des besoins (ou une fenêtre response appelée à partir de ta dawindow contenant cette liste).
Enfin personnellement c'est comme çà que je procèderai.
A+
Vincent
Hors ligne
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.
Hors ligne
Je pense qu'une petite analyse même rapide serait du meilleurs effet. Renseignes toi sur la troisièmes forme normale de ce bon vieux Merise.
Pour moi, l'information que te donne vince n'est pas une option, c'est la seule façon de gérer correctement ton problème. On peut peut-être t'aider dans la mise en oeuvre si tu ne maîtrises pas ces notions. Mais pitié, penses à ceux qui vont passer derrière toi pour maintenir le programme...
Hors ligne
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)
Hors ligne
Bonjour,
Je viens de vérifier... SetBit n'existe pas en PB6...
Désolé, mais ça m'avait l'air faisable !
Je cherche encore !!
Hors ligne
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)
Hors ligne
L'idée est séduisante mais il me semble que pour faire correspondre la valeur d'un bit et un libellé il va falloir passer par une table (sauf à coder en dur). Utiliser les positions bits est surtout très adapté aux traitements en masse d'informations (info indus par exemple) ou pour le stockage de flag simple.
Pour une appli de gestion ça peut vite devenir un cauchemard ! 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?
Hors ligne
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 !
Hors ligne
En fait il faut créer une "relation" entre ta table diplôme et ta table personne. Dans les faits une relation se traduit par une nouvelle table, contenant les identifiants des deux tables et les informations associées aux deux identifiants.
Dans ton cas, il te faut donc trois tables :
Personne
per_id (clé primaire)
per_nom
per_prenom
etc...
Diplome
dip_id (clé primaire)
dip_libelle
dip_niveau
etc...
diplome_personne
dpp_id (clé primaire)
per_id (clé étrangère sur la table personne)
dip_id (clé étrangère sur la table diplome)
dpp_date_obtention
dpp_justificatif
dpp_lieu
etc...
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)
Hors ligne
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.
Hors ligne
nico a écrit:
La solution de Chrnico est la meilleur. Elle permet une plus grande évolution, elle est plus facile à manipuler et tout le monde la comprendra.
Rho lol, dis tout de quite que la mienne elle pue parceque vous la comprenez pas ^^
Ma solution est plus performante et plus économe en espace alors désolé mais lire que celle de Chrnico est meilleure ça cale un peu... (qu'elle soit plus adapté pour un(e) débutant(e) ça je conteste pas)
Et puis la solution de Chrnico ne mémorise pas plusieurs data dans un même champ, ce qui était la question au départ.
Chrnico a écrit:
L'idée est séduisante mais il me semble que pour faire correspondre la valeur d'un bit et un libellé il va falloir passer par une table (sauf à coder en dur).
=> Comme je le disais dans mon message on décide par convention que tel bit = telle info, chez nous on stocke aussi cette convention dans le commentaier de la colonne dans Oracle
Chrnico a écrit:
Utiliser les positions bits est surtout très adapté aux traitements en masse d'informations (info indus par exemple) ou pour le stockage de flag simple.
=> exactement ce qui était demadné dans la demande initiale donc.
Dernière modification par rincevent (10-06-2009 13:12:17)
Hors ligne
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.
Hors ligne
Dernière modification par rincevent (10-06-2009 14:00:25)
Hors ligne
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.
Hors ligne
Bon, pour éclaircir un peu et 'calmer' les débats, je ne travaille pas dans l'informatique, mais j'ai une 'bonne' connaissance de PB (j'ai suivi 6 mois de formation intensive à PB dans le premier semestre 1998 ; oui, ça remonte et c'est pour ça que je suis 'bloqué' à PB 6.0). J'avoue être un peu moins performant dans le SQL, mais ça va encore pour ce que je veux faire.
Pour recentrer le débat, qu'est-ce qui le plus facile ? Je vais avoir 2 mois de vacances j'ai donc un peu de temps devant moi (quoique, vu que personne ne m'a demandé de faire un tel programme, je n'ai pas de death line, mais si il est terminé pour le 1er septembre, ce serai génial).
Je rappelle également qu'un module de recherche est également prévu. Si je veux avoir toutes les personnes qui ont un diplôme 'maternelle' je dois pouvoir les retrouver même si elles ont un (ou 2) diplôme en plus !!!
Toutes vos idées sont les bienvenues, je ne me suis pas encore lancée dans la programmation de l'une ou l'autre solution présentée ci-avant !
Bonne journée à tous et merci pour votre aide !!
Hors ligne
Ce ne serait pas chez STE-Formations que tu as appris PB ?
Hors ligne
BRWA a écrit:
Ce ne serait pas chez STE-Formations que tu as appris PB ?
Zut, je suis démasqué !!
Je suppose que tu en faisais partie aussi ?
Hors ligne
promotion 2009 ... Je suis en fin de stage ;)
Hors ligne
BRWA a écrit:
promotion 2009 ... Je suis en fin de stage ;)
Remets bien le bonjour à Isa et Michelle !
(J'étais dans la même promo qu'Yves, le mari d'Isa !)
Hors ligne
ok ;)
Hors ligne
Généralement il est d'usage en modélisation de base de donnée: 1 champs = 1 signification, cela rend les choses plus simple à gérer et à maintenir.
D'un autre côté Si on désire garder un historique de celui qui a encodé les diplômes (une espèce d'audit de base de donnée pour surveiller les employés :-) la solution avec la manipulation de bit est un peu légère et perso je pense mal adaptée dans ce genre de contexte (C'est une application base de donnée, pas de la programmation de drivers d'impression, je plaisante...:-)
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
Hors ligne
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 !!
Hors ligne