Discussion :

[balolo]

Bonjour à tous,

je suis actuellement sur un projet visant à gérer les SAV via un base MySQL interfacée par Open Office ...

A l'époque ou j'avais l'ancienne version permettant de gérer tout çà (en VBA sous excel) le responsable SAV avait réalisé ce schéma résumant le suivi d'un litige (ressemblant sensiblement au suivi d'un sav) ... voici donc ce schéma :

http://astuces.diablo2.free.fr/SuiviLitige.JPG

l'iddée serait de faire les requetes (de recherche, d'ajout et de modification via calc) et de faire l'édition automatique des documents via base (publipostage : requete + etat)

je me lance donc dans mon modèle conceptuel (c'est mon premier en situation réelle depuis mes cours de BTS) ...

Quelqu'un (mon chef) m'a suggérer de ne pas refaire les tables article et client étant donné que l'on peut récupérer les infos depuis notre ERP ... Cette meme personne m'a aussi suggérer de faire carrément une seule et meme table qui regrouperaient les information sur le client, sur l'article, sur le sav, sur l'expédition et la reprise !
sur le premier point éventuellement je lui concède, mais ce sera plus difficile à gérer quand même (notre ERP stocke par exemple l'enseigne et la ville de manière concaténé, de plus le service SAV utilise des alias, ... lyon2 est devenu st bonnet de mures) ...

j'ai quand meme fait un modèle conceptuel de plusieurs tables ... j'aurais aimé quelques conseils sur d'éventuels erreurs ...
peut etre ne devrait-je pas séparer les tables EXPED et FACTURE ou REPRISE ET AVOIR (ou d'autre ...) ?

De plus j'aurais aussi aimé savoir si je ne me suis pas planté dans mes clés étrangère ... : est ce que je doit plutot mettre NUMFAC en clé étrangère dans EXPED ou NUMEXP en cléétrangère dans FACTURE ? (de même pour les autres relations)

la liste des champs n'est pas exhaustive sur tout pour la table SAV, et puis c'est pareil, pour gérer cette histoire d'alias je rajouterai peut etre un champ dans la table client ...

voici donc mon modèle conceptuel (transformé en jpg pour ceux qui n'ont pas open office) :
http://astuces.diablo2.free.fr/modele.JPG

Mais peut etre que je me fourvoie complètement et que mon chef a raison de me suggérer de faire une seule et même table ...
on peut dire que j'ai le c** entre deux chaise, sans vouloir etre vulgaire ...

PS : * avant le champ signifie que c'est une clé primaire alors que # après signifie que c'est une clé étrangère ...

Cordialement

[hed62]

Pour ton histoire de clef, tout dépend du sens de navigation que tu désire faciliter/optimiser. Si tu va souvent naviguer vers B en connaissant A, alors A doit posséder la clef étrangère.

Tout mettre dans une seule table est rarement une bonne solution : cela entraine des pertes , de la redondance. Et donc empèche une maintenance aisée ou les évolutions futures.

En ce qui concerne la reprise depuis l'ERP, je te conseille de créer une vue sur la table PRODUIT de ton ERP (pour masquer les champs dont tu n'as pas besoin.)

[balolo]

merci pour ta réponse !

quand tu dis "vue", tu veux parler d'une requete SQL toute bete ?

pour les clé étrangère, en fait je me demande surtout si il vaut mieux avoir un champ NUMEXP comme clé étrangère dans la table SAV qui serait donc soit rempli soit nul ou plutot NUMSAV toujours rempli dans la table EXPED ...
-> en effet pour savoir rapidement si il y a reprise ou non, si il y a expédition ou non ... la première solution est mieux puisque pas besoin de faire de jointure à chaque coup
-> mais en meme temp est ce que c'est pas embetant que cette clé étrangère soit nulle de temps en temps ?

sinon tu ne vois pas d'erreur grossière dans mon MCD ?

[hed62]

Je veux parler d'une vue ^^ : CREATE VIEW AS SELECT....

-> mais en meme temp est ce que c'est pas embetant que cette clé étrangère soit nulle de temps en temps ?

Non

sinon tu ne vois pas d'erreur grossière dans mon MCD ?

non plus

[balolo]

ah je ne connaissait pas cette instruction ...
par contre j'ai du mal à comprendre les avantage (ou inconvénient) par rapport à un select classique ?

enfin si, je suppose par contre que cela me permettrai de faire des unions si je le désire alors que jusque la mes essais d'union ne marchait pas ...

[hed62]

En fait, "Create Table" va te créer une nouvelle table physique, avec les champs déclarés dans l'instruction.

"Create view" va te créer une table "virtuelle", dans laquelle tu pourras piocher tes infos.

Je ne suis pas sur de la syntaxe, mais :

Code :

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

1
2
 
create view Art as select designation, prix from Article;

Va te permettre de faire après

Code :

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

1
2
Select * from Art

Sans te soucier que Article provient de ton ERP, et que Art est une "fausse" table.

Mais attention, on est loin du sujet de ce forum là, on dévie sur du SQL

[balolo]

oups, ... oui !!

pour la manipulation de la vue, ca j'avais compris en lisant la doc, mais je me demandais si ca serait plus rapide à l'exécution que de faire un select direct ou alors si l'intéret était uniquement sur le plan syntaxique et d'éviter de se connecter à 2 bases différentes en simultané ...

je reposterai certainement par la suite parce que je viens de recompliquer un peu mon schéma je vous redemanderai donc votre avis une fois qu'il sera un peu plus abouti ...

je balise en résolu !