left join non prévu dans le schema

**erictomcat** · 22/09/2010, 10h51

bonjour,

j'ai 2 tables, la premiere me permet de grouper à la création un groupe de personnes la seconde de gerer par personne des données par date:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
GrpeChqDejList:
  connection: doctrine
  tableName: GrpeChqDejList
  columns:
    grpechqdej_id:
      type: integer
    user_id:
      type: integer
      unique: true
  indexes:
    Unique:
      fields: [grpechqdej_id, user_id]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
    GrpeChqDej:
      class: GrpeChqDej
      local: grpechqdej_id
      foreign: id    
 
ChqDej:
  connection: doctrine
  tableName: cheqdej
  columns:
    user_id: 
      type: integer
    date:
      type: timestamp
    conges:
      type: integer
    maladie:
      type: integer
    professionel:
      type: integer
    nbChq:
      type: integer
  indexes:
    Unique1:
      fields: [user_id, date]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
      onDelete: CASCADE
      onUpdate: CASCADE

je ne désire pas avoir une relation forte entre ces deux tables mais j'ai besoin davoir un affichage par groupe donc en SQL ça donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT G.`user_id`, MAX(c.date )
FROM GrpeChqDejList G 
LEFT OUTER JOIN cheqdej c ON c.user_id=G.user_id 
WHERE G.`grpechqdej_id`=1 
GROUP BY G.`user_id`

que j'ai transcrit en doctrine:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$q = Doctrine_Query::create()
      	    ->select('a.user_id,MAX(c.date)')
      		->from('GrpeChqDejList a')
      		->leftJoin('cheqdej c ON a.user_id = c.userid')
      		->where('a.grpechqdej_id = ?',$id)
      		->execute();

malheureusement j'ai le message d'erreur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Couldn't find class cheqdej

quelle est la bonne syntaxe ?

**bilbonec** · 22/09/2010, 11h42

Tu n'as effectivement pas de classe : cheqdej
Mais une classe : ChqDej.

De manière plus générale, je te conseillerais d'être beaucoup plus vigilant dans tes nommages de classe, table, paramètres, etc.

D'une part, la lecture d'un nom doit être le plus explicite possible. En n'utilisant que des abréviations, j'ai dû prendre le temps de décoder tes noms pour comprendre ce qu'ils représentaient (ce qui est une mauvaise chose).

D'autre part, tu es constamment obligé de venir vérifier la bonne orthographe pour être sûr, lorsque tu utilises un nom autre part dans ton code, de ne pas te tromper dans la manière de l'écrire.

Certes, écrire "ChequeDejeuner" est plus long. Mais :
1. tu comprends beaucoup plus rapidement de quoi il s'agit ;
2. tu évites de te tromper entre cheqdej et ChqDej !

Après, peut-être as-tu aussi une erreur sur la manière dont est écrite la requête elle-même. Mais j'ai toujours du mal à écrire moi-même mes left join

**erictomcat** · 22/09/2010, 12h12

effectivement c'était ça.
je n'avait pas compris qu'il faut mettre la classe et non la table dans le leftJoin

pour le nommage, vais essayer de faire des effort
merci

**Michel Rotta** · 22/09/2010, 12h43

Si le shéma est correctement conçu (je n'ai pas vérifié le tiens) dans le leftjoin de doctrine tu ne mets ni le nom de la classe ni le nom de la table mais le nom de la relation (ou le nom défini par foreignAlias qui est le nom de la relation vu de l'autre côté de la relation.

**erictomcat** · 22/09/2010, 15h18

j'ai pas de relation entre ces 2 tables dans mon schema, pour des raisons pratiques.

Bon par contre en faites ça ne marche toujours pas, si je n'ai pas de message d'erreur il ne me prend pas en compte ma liaison:
mon schéma doctrine:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$q = Doctrine_Query::create()
      	    ->select('a.user_id, DATE(MAX(c.date)) AS maxdate')
      		->from('GrpeChqDejList a')
      		->leftJoin('ChqDej c ON a.user_id = c.userid')
      		->groupBy('a.user_id')
      		->where('a.grpechqdej_id = ?',$id)
      		->execute();

et la requête SQL qui est généré:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT g.id AS g__id, g.user_id AS g__user_id, DATE(MAX(c.date)) AS c__0 FROM GrpeChqDejList g, cheqdej c WHERE (g.grpechqdej_id = ?) GROUP BY g.user_id - (1)

EDIT: j'ai comme un doute, il y a moyen de faire un leftJoin qui n'est pas prévu dans le schéma ??

**erictomcat** · 22/09/2010, 18h25

bon apres une demi journée a fouiné sur internet:
un leftjoin non prévu dans le schema ne fonctionne que si l'on a expressément indiqué les clés primaire de chacune des tables dans le select, c'est d'une logique...
donc voici le résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$q = $this->createQuery('a')
      	    ->select('a.id,c.id, a.user_id, DATE(MAX(c.date)) AS maxdate')
      		->leftJoin('a.ChqDej c ON a.user_id = c.user_id')
      		->groupBy('a.user_id')
      		->where('a.grpechqdej_id = ?',$id)      		
      		->execute();

**Michel Rotta** · 23/09/2010, 14h54

Envoyé par erictomcat

j'ai pas de relation entre ces 2 tables dans mon schema, pour des raisons pratiques.

Il me semble que cela soit justement moins pratique que de mettre simplement les relations.

La méthode doctrine lsftJoint() est conçue pour fonctionner avec des relations déclarées dans le schéma, forcément, si tu ne veux pas les utiliser, elle va fonctionner beaucoup moins bien, je m'étonne même que tu arrives à établir une relation.

Si non, tu as la possibilité "classique" de déclarer deux tables dans la méthode form et d'établir ta liaison à l'aide d'une méthode where() ou andWhere().

Je reste convaincu que, hors exception exceptionnellement exceptionnel, toutes les relations ont intérêt à être définies dans le schéma de la base.

**erictomcat** · 23/09/2010, 15h05

en faites, je gére des groupes de personnes d'un coté pour l'affichage et la mise à jour (GrpeChqDejList) et la gestion de Tickets restaurant par personne (ChqDej);
Les personnes peuvent changer régulièrement de groupe, donc le lien est peu important.

De plus quand j'ai voulu mettre une relation, celle ci étant 1 occurence de GrpeChqDejList => n occurences de ChqDej.
J'ai voulu la mettre dans GrpeChqDejList, hors quand je charge mes fixtures, ça plante car il veut a tout prix une valeur dans ChqDej, ce qui n'est pas logique !!!

je te remet mon schema tel que j'ai tenté de le faire passer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
GrpeChqDejList:
  connection: doctrine
  tableName: GrpeChqDejList
  columns:
    grpechqdej_id:
      type: integer
    user_id:
      type: integer
      unique: true
  indexes:
    Unique:
      fields: [grpechqdej_id, user_id]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
    GrpeChqDej:
      class: GrpeChqDej
      local: grpechqdej_id
      foreign: id
#### ce que j'ai du retirer :
      ChqDej::
        local: user_id
        foreign: user_id
 
 
ChqDej:
  connection: doctrine
  tableName: cheqdej
  columns:
    user_id: 
      type: integer
    date:
      type: timestamp
    conges:
      type: integer
    maladie:
      type: integer
    professionel:
      type: integer
    nbChq:
      type: integer
  indexes:
    Unique1:
      fields: [user_id, date]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
      onDelete: CASCADE
      onUpdate: CASCADE

**Michel Rotta** · 23/09/2010, 16h27

A vue d'oeil, mais non testé.

Je pense que le problème de ta relation viens du fait que user_id dans GrpeChqDejList n'est pas clef primaire.

Si ta liaison partais de la clef primaire id de GrpeChqDejList ce qui me semblerais plus logique, tu ne devrais pas avoir de problèmes.

**erictomcat** · 23/09/2010, 18h32

je pensait qu'il était préférable de laisser doctrine créer des id ?

bon pour info en fait le leftJoin ne fonctionne pas j'avais laissé une trace d'une relation entre les 2 que "j'ecrasait"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
GrpeChqDejList:
  connection: doctrine
  tableName: GrpeChqDejList
  columns:
    grpechqdej_id:
      type: integer
    user_id:
      type: integer
      unique: true
  indexes:
    Unique:
      fields: [grpechqdej_id, user_id]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
    GrpeChqDej:
      class: GrpeChqDej
      local: grpechqdej_id
      foreign: id
     
      
ChqDej:
  connection: doctrine
  tableName: ChqDej
  columns:
    user_id: 
      type: integer
    date:
      type: timestamp
    conges:
      type: integer
    maladie:
      type: integer
    professionel:
      type: integer
    nbChq:
      type: integer
  indexes:
    Unique1:
      fields: [user_id, date]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
      onDelete: CASCADE
      onUpdate: CASCADE 
    CheqDej:
      class: GrpeChqDejList
      local: user_id
      foreign: user_id

le probleme c'est pour garder l'historique d'un gars qui ne fait plus partie d'une liste !!!

PS: je pense devoir passer par $q = new Doctrine_rawSQL() mais pas compris comment ça marchait.

**Michel Rotta** · 23/09/2010, 20h09

Effectivement si tu ne mets pas de clef primaire, doctrine en crée une.

Le problème est que dans ta relation, tu ne mets pas de clefs primaire. Et que je ne pense pas que symfony s'en sort.

Après, je ne comprend pas trop ce que tu veux faire avec tes trois tables (table user inclue). Le oncascade ne sert à rien si la liaison est basée sur une clef primaire autoincrémenté.

Pourrais-tu, avec des mots simple, décrire ce que tu souhaites réaliser ? (très simple les mots, j'ai un vocabulaire plutôt limité

)

**erictomcat** · 23/09/2010, 21h11

on va essayer mais ça va etre dur

bon le principe:
gérer la commande tickets restaurant de tout les utilisateurs via des correspondants qui mettent à jour mensuellement les valeurs.

A la base, la table user qui n'est que la table sfGuardUser, je remet pas son schéma, je pense pas que ce soit utile.
Ensuite je gère des groupes avec un nom de groupe, un responsable, un suppleant.
c'est ma table GrpeChqDej:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
GrpeChqDej:
  connection: doctrine
  name:
     Type: String(50)
  primaryUser:
     Type: Integer
  secondaryUser:
     Type: integer
  relations:
    primaryUser:
      class: sfGuardUser
      local: primaryUser
      foreign: id
    secondaryUser:
      class: sfGuardUser
      local: secondaryUser
      foreign: id

ensuite pour chaque groupe je gere une liste de personne.
c'est la table GrpeChqDejList:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
GrpeChqDejList:
  connection: doctrine
  tableName: GrpeChqDejList
  columns:
    grpechqdej_id:
      type: integer
    user_id:
      type: integer
      unique: true
  indexes:
    Unique:
      fields: [grpechqdej_id, user_id]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
   GrpeChqDej:
      class: GrpeChqDej
      local: grpechqdej_id
      foreign: id

bon la je pourrait peut etre mettre la relation GrpeChqDej dans la premiere table, serait plus logique, mais change pas grand chose à mon problème.

ça me permet tout les mois de n'afficher par responsable que sa liste
et enfin une table ou je gère les demandes par utilisateurs:
la table chqDej:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
ChqDej:
  connection: doctrine
  tableName: cheqdej
  columns:
    user_id: 
      type: integer
    date:
      type: timestamp
    conges:
      type: integer
    maladie:
      type: integer
    professionel:
      type: integer
    nbChq:
      type: integer
  indexes:
    Unique1:
      fields: [user_id, date]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
      onDelete: CASCADE
      onUpdate: CASCADE

et ce que je veut c'est pouvoir afficher lors de l'affichage d'un groupe la dernière date de mise a jour par user. Pour voir si tout le monde est à jour:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT G.`user_id`, MAX(c.date )
FROM GrpeChqDejList G 
LEFT OUTER JOIN cheqdej c ON c.user_id=G.user_id 
WHERE G.`grpechqdej_id`=1 
GROUP BY G.`user_id`

il est difficile de mettre une relation entre les 2 dernieres tables, car une personne ayant eu des cheque dej, peut ne plus être dans une liste et dans l'autre sens ce n'est pas parce que une personne est dans une liste qu'elle prend des cheq dej.

sinon tu ne pense pas que ce soit possible de créer ma requête via $q = new Doctrine_rawSQL() ?

**Michel Rotta** · 24/09/2010, 03h33

Bien, cela commence à s'éclaircir un peu pour moi. Mais il me reste des zones d'ombre. Je vais reformuler.

Tu gères la répartition de chèques restaurants par personnes. Ces CR sont distribué par des responsables qui gères un groupe de personnes.

Une personne peut faire partie de plusieurs groupes. Les "achats (?)" de chèque sont stocké dans une table, chaque personne à une entrée par mois dans cette table si elle a commandé des chèques.

Les questions et remarques :

Est-ce que toutes les personnes qui sont toutes dans la tables sfGuardUser, doivent accéder à l'application ? Avoir un compte de connection et un mot de passe ? Pour faire leurs demande par exemple ? Si non, quel est l'intérêt de mettre les utilisateurs dans la table de validation des connexions ?
Dans la structure que tu proposes, une personnes peut faire partie de plusieurs listes, est-ce normal ? Où alors, elle peut changer de liste d'un mois sur l'autre ? Ou pires, être sur plusieurs listes pour un mois, avec plusieurs personnes qui doivent valider (il n'y a pas de champ de validation).
Le problème que tu as dans la relation est qu'il s'agit d'une relation n-n qui est mal définie, mais j'ai du mal à voir entre quels tables cette relation effectues.
Pourquoi dans la table ChDej trouve-t-on une date de demande, mais pas le mois et l'année d'imputation de la transaction ?
En fait, j'ai l'impression que tu devrait avoir une liaison 1-n entre l'utilisateur et le groupe (un utilisateur ne peut appartenir simultanément qu'à un groupe) et une liaison n-n pour les validations (ChDej) et les groupes, a raison d'une liaison par mois.
Quel est le niveau de responsabilité de la personne qui valide la demande ? Comment conserve-t-on l'historique de la personne qui à pris la décision (le premier, le second, quid d'un changement de responsable, il récupère les m.....e de son prédécesseur ?

Ce qui importe n'est pas là où tu définis la liaison, mais qu'elle soit définie et correctement définie.

La fonction Doctrine_rawSQL() va te permettre de faire à peut près n'importe quoi (avec les deux acceptations de l'expression), il faudrait plutôt la considérer comme un échec à mettre en place une bonne structure plutôt que comme une solution magique.

Dans une application de se type, une bonne analyse de la base de données est primordiale et évite bien des soucis. Focalise toi sur une structure viable (la tienne ne l'est pas encore), ensuite, dessiner l'application sera beaucoup plus naturel.

**erictomcat** · 24/09/2010, 09h29

mouarf, bon vais essayer de te répondre point par point

Envoyé par mimi68

Une personne peut faire partie de plusieurs groupes. Les "achats (?)" de chèque sont stocké dans une table, chaque personne à une entrée par mois dans cette table si elle a commandé des chèques.

une personne peut changer de groupe mais jamais être dans 2 groupes différents

Envoyé par mimi68

[*]Est-ce que toutes les personnes qui sont toutes dans la tables sfGuardUser, doivent accéder à l'application ? Avoir un compte de connection et un mot de passe ? Pour faire leurs demande par exemple ? Si non, quel est l'intérêt de mettre les utilisateurs dans la table de validation des connexions ?

pas forcément pour ce module, mais pour d'autre oui. Comme j'avais besoin de gérer pas mal d'info par utilisateur c'est toi qui m'avait suggérer d'utiliser ce plugin

Envoyé par mimi68

[*]Dans la structure que tu proposes, une personnes peut faire partie de plusieurs listes, est-ce normal ? Où alors, elle peut changer de liste d'un mois sur l'autre ? Ou pires, être sur plusieurs listes pour un mois, avec plusieurs personnes qui doivent valider (il n'y a pas de champ de validation).

surtout pas !!, une personne est forcément a un instant t que dans un seul groupe. d'ailleurs dans ma structure de table le user a un index unique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
GrpeChqDejList:
  connection: doctrine
  tableName: GrpeChqDejList
  columns:
    grpechqdej_id:
      type: integer
    user_id:
      type: integer
      unique: true
  indexes:
    Unique:
      fields: [grpechqdej_id, user_id]
      type: unique
  relations:
    User:
      class: sfGuardUser
      local: user_id
      foreign: id
   GrpeChqDej:
      class: GrpeChqDej
      local: grpechqdej_id
      foreign: id

sauf que j'ai ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unique:
      fields: [grpechqdej_id, user_id]
      type: unique

en trop, vient de m'en apercevoir.

Pas de validation, en faites les responsables de groupe, ou leur suppléants saisissent les données à leur place (ce sont de gros feignants).

Envoyé par mimi68

[*]Le problème que tu as dans la relation est qu'il s'agit d'une relation n-n qui est mal définie, mais j'ai du mal à voir entre quels tables cette relation effectues.

pas de liaison n-n
GrpeChqDej 1=>n GrpeChqDejList 1=>n (ou pas de relation) ChqDej
je peut avoir un enregistrement dans chqdej qui ne fait plus référence à une occurrence dans GrpeChqDejList

Envoyé par mimi68

[*]Pourquoi dans la table ChDej trouve-t-on une date de demande, mais pas le mois et l'année d'imputation de la transaction ?

quand je gére des periode (ici année-mois), je trouve plus facile de gérer un champ date en forçant le jour à 1 plutôt qu'un champ année et un champ mois, comme ça je peut utiliser les fonctions Dates que ce soit dans SQL ou PHP.

Envoyé par mimi68

[*]En fait, j'ai l'impression que tu devrait avoir une liaison 1-n entre l'utilisateur et le groupe (un utilisateur ne peut appartenir simultanément qu'à un groupe) et une liaison n-n pour les validations (ChDej) et les groupes, a raison d'une liaison par mois.

la je comprend pas tout mais je pense t'avoir répondu un peu plus haut.
par contre, effectivement, il n'y a pas validation par les responsables, mais bien juste la saisie pour un ensemble de personnes.

Envoyé par mimi68

[*]Quel est le niveau de responsabilité de la personne qui valide la demande
? Comment conserve-t-on l'historique de la personne qui à pris la décision (le premier, le second, quid d'un changement de responsable, il récupère les m.....e de son prédécesseur ?

peut etre à origine de notre incompréhension mutuelle, il n'y a pas de notion de validations, juste une personne qui saisie à la place d'autre parce les autres sont faignant

PS: bon il y a des trucs qui me dépassent. pour suivre tes conseils dans la table GrpeChqDejList, j'ai mis le champ user_id comme clef primaire.... sauf que si je fait ça il veut pas créer ma relation entre le champ user_id et sfGuardUser !!!

**Michel Rotta** · 24/09/2010, 13h53

Le schema qui me semble le plus proche de tes besoins, tel que je les ais compris.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
 
user:
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
  columns:
    GrpeChqDejList_id: integer
  relations:
    GrpeChqDej:
      local: id
      fogeign: user_id
      foreignAlias: users
 
ChqDej:
  tableName: cheqdej
  columns:
    user_id: 
      type: integer
    date:
      type: timestamp
    conges:
      type: integer
    maladie:
      type: integer
    professionel:
      type: integer
    nbChq:
      type: integer
  indexes:
    Unique1:
      fields: [user_id, date]
      type: unique
  relations:
    User:
      local: user_id
      foreign: id
      foreignAlias: ChqDejs
      onDelete: CASCADE
 
GrpeChqDej:
  name:
    type: String(50)
    notnull: true
  primary_user_id:
    Type: Integer
    notnull: true
  secondary_user_id:
    Type: integer
  relations:
    primaryUser:
      class: user
      local: primary_user_id
      foreign: id
    secondaryUser:
      class: user
      local: secondary_user_id
      foreign: id

Remarques :

La table GrpeChqDejList a disparu, elle ne servait qu'à établir un lien hypothétique avec les user et rajoutait une couche d'incertitude dans la gestion de la base.
Pour bien gérer il aurait fallu avoir un champs supplémentaire dans la table user, le numéro (id) du groupe du user (qui serait donc unique d'office). Ce qui est fait grâce à la table user qui étant par héritage la table sfGuardUser et lui rajoute un champs : GrpeChqDejList_id pour la lisaison et la relation qui va avec. Attention, seul la table user possède cette relation et ce champ, elle possède, de plus tous les champs de sfGuardUser ainsi que leurs relation. Dans ton schéma, tu feras référence à la table user la majeur partie du temps, sauf pour la gestion des droits qui va travailler sur sfGuardUser, et tous va marcher. sisi.
Modification du lien entre la table user et la table ChqDej.
Quelques simplifications et allégements
Modification des liens dans la table GrpeChqDej pour qu'ils pointent sur user

Avec ce schéma :

un user ne peut faire partie que d'un groupe
un user peut avoir au maximum une ligne de commande par mois
un user peut ne pas avoir de ligne de commande

On doit être assez proche de tes demandes.

Ta première requête s'écrit alors :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$q = Doctrine_Query::create()
            ->from('user u')
            ->leftJoin('u.ChqDejs c')
      	    ->select('u.id, MAX(c.date)')
            ->execute();

Comme quoi, un bon schéma simplifie les requêtes.

**erictomcat** · 24/09/2010, 14h36

la table que tu supprime était du au fait que je gère les chqdej pour un site mais que ma table user contient l'ensemble des utilisateurs européens.

pour éviter d'avoir un champ inutile dans 70% des cas, j'avais préféré créer cette table intermédiaire.

je modifie mon schéma et te dit

**Michel Rotta** · 24/09/2010, 15h16

Note que tu peux rajouter un champ pays dans la table étendue user. Ce qui peut servir. Et un champs service, et un téléphone et... bien d'autres informations intéressantes.

Il est vrais que dans ce cas là, le champ de liaison n'aurait d'intérêt que pour un pays, ce qui n'est pas optimal.

On pourait envisager une table de jointure entre la table user et le système de chèque, avec une liaison 1-0<->1-1 faut voir si cela (la solution dans user) surcharge trop le format global de la base.

**erictomcat** · 24/09/2010, 15h23

la table user posséde dja une dizaine de champ supplémentaire donc un de plus...

par contre pour le moment j'ai un bléme, malgré le fait que j'ai supprime la table grpChqDejList de mon schéma, elle réapparait systématique à chaque build (j'ai drop le schéma depuis mySQL pour être sur)

**Michel Rotta** · 24/09/2010, 17h56

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

symfony doctrine:delete-model-files

**erictomcat** · 24/09/2010, 18h35

trop tard, j'ai tout supprimé

mais bon à savoir

bon bein message d'erreur

mon schema:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
user:
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
  actAs: [Timestampable]
  columns:
    matricule:
      type: integer
      unique: true      
    epass:
      type: string(20)
      unique: true
    section_id: { type: integer }
    emailintranet: 
      type: string(255)
      unique: true    
    site_id: { type: integer }
    contrat: { type: string(3) }
    esi:
      type: boolean
      default: 0
    GrpeChqDejList_id: 
      type: integer
    startdate: 
      type: timestamp
    gardenleavedate:
      type: timestamp
    offrolldate:
      type: timestamp
  relations:    
    Section:
      local: section_id
      foreign: id
      onDelete: CASCADE
    Site:
      local: site_id
      foreign: id
    GrpeChqDej:
      local: id
      foreign: user_id
      foreignAlias: users
 
GrpeChqDej:
  tableName: GrpeChqDej
  columns:
    name:
      type: string(50)
      notnull: true
    primary_user_id:
      type: integer
      notnull: true
    secondary_user_id:
      type: integer    
  relations:
    primaryUser:
      class: user
      local: primary_user_id
      foreign: id
    secondaryUser:
      class: user
      local: secondary_user_id
      foreign: id
 
ChqDej:
  tableName: cheqdej
  columns:
    user_id: 
      type: integer
    date:
      type: timestamp
    conges:
      type: integer
    maladie:
      type: integer
    professionel:
      type: integer
    nbChq:
      type: integer
  indexes:
    Unique1:
      fields: [user_id, date]
      type: unique
  relations:
    User:
      class: user
      local: user_id
      foreign: id
      foreignAlias: ChqDejs
      onDelete: CASCADE