Discussion :

[viviboss]

lol

r_type, c'est le type de rendez vous (R0....)
rendez_vous, c'est le rendez_vous en lui même (il peut y en avoir plusieurs sur le même r_type)

Les dates (dans chaque table....) me permet d'avoir cette notion d'historique (le R0 est initié à tel date, et le premier rendez_vous de ce R0 est à telle date....)

La gestion du temps est en fait l'élément principal....

Les commentaires ne sont réellement reliés qu'à UNE table en même temps (ma fainiantise de designer 4 fois la même table.....)

r_type est sur prospect, car le déroulement est le suivant :

Un prospect doit voir ce dérouler 6 étapes : R0,R1,R2,R2_bis,R3,R4.

Chaque étape a son lot de rendez_vous et modifs (le prospect ne peut pas tel jour, alors on repporte....), on peut même dire que les rendez_vous sont dépendant des processus des opérations (en R2, on prend 2 rendez_vous pour remettre 2 types de papiers....)

Je n'ai pas mis le type d'opérations, car celles-ci ne sont pas "figer" : elles peuvent évoluer dans le temps, ou tout simplement on peut en rajouter...idem pour les processus.

Exemple : j'entre en base une nouvelles opération : Banque. Dans cette opération, les processus sont les suivants : un processus papier client, un processus papier banque.

Quand ces 2 processus sont réalisé, l'opération est réalisé. Dans le temps, la somme des 2 dates des processus permet de retrouver la durée de l'opération.

Je sais c'est pas simple, mais après tout c'est une appli de gestion.

Je connais effectivement cette notion de Workflow, mais je pensais que c'était pour des éléments plus "administratifs"....

Par contre, pour le cout du "si un collaborateur sort...", et bien ses affaires sont redistribués, au bon vouloir du Directeur (c'est une Fonction....)

L'historique ne concerne QUE le prospect (d'ou le fait qu'il y ait des dates partout....)

On a en Date :

date_intro : date ou l'action est introduite en base,
date_max : date maximum à ne pas dépasser
date_min : date minimum à ne pas dépasser (notion de délais)
date_fin : date e fin prévu.

Pour l'historique, je pense le faire "à la volé" en programmation.... Pas besoin de table : tant que j'ai mon prospect et les dates de toute mes actions, je met en forme le tout....Et j'enregistre à la limite dans un LOG texte.....

[Mr N.]

r_type, c'est le type de rendez vous (R0....)
rendez_vous, c'est le rendez_vous en lui même (il peut y en avoir plusieurs sur le même r_type)

Les dates (dans chaque table....) me permet d'avoir cette notion d'historique (le R0 est initié à tel date, et le premier rendez_vous de ce R0 est à telle date....)

Ok, moi je voyais les choses comme ça (remplacer les noms par R0, R1, ... R4) :

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
type_rdv
--------
id    nom
...
4    Prise de contact
...
6    Rencontre du Pere Noel
...
 
 
rdv
---
id    type_rdv_id    prospect_id   date
...
456    6             12            24-12-2006
457    6             14            24-12-2006

Ca me semble bizarre de mettre des dates à un "type" de rdv.

[viviboss]

.....OUi tu as raison, mais contrairement à ton smailey, je ne me suis ps gratté la tête pour trouver le nom de ma table !!!!

C'st justement celle là que j'ai redesigné, avant je détaillais chaque "R" dans une table indépendante (table R0, table R1, ....) ce qui ne correspondait pas à la logique applicative : une classe abstraite, de laquelle découle tout mes R.... D'autant plus que maintenant, je peux mêe imaginer d'autres "R" sans toucher à ma base, juste en rajoutant une classe !!!!!

en tout cas, grace à toi je vois les choses d'un autre oeil, donc je te remercie beaucoup beaucoup pour ton aide, je me sens un peu plus "serain" !!!!

Je vais voir cette histoire de Workflow (j'ai déjà "préselectionné" openWFE, et pour mes traitements "middleWare" en XML, je vais voir ce que donne XMLBlaster) et surtout je vais regarder cette histoire de tests unitaire....Ca me parrait très formateur.