2014-07-10 2 views
0

Je suis en train de concevoir une base de données (dans MS Access 2010, mais je pense que cette question n'a pas d'importance) pour stocker des informations sur les devis et commandes pour une entreprise de menuiserie. C'est mon premier grand projet de base de données, et même si j'ai l'impression d'avoir compris les concepts de la normalisation, j'ai de la difficulté à comprendre comment structurer la citation et la gestion des travaux.DB Schema - Job, Quote, JobStatus

Points clés:

  • Lorsqu'un client fait une demande, un devis ou plusieurs citations sont produites.
  • Les cotations produites peuvent inclure des variations de la même chose. Par exemple, une citation peut être pour 10 fenêtres peintes en blanc, et une autre citation peut être pour les mêmes fenêtres peintes en vert (nous facturons un supplément pour les couleurs non-blanches). Il peut également y avoir des citations séparées, par exemple. un pour les fenêtres sur une maison et un pour certaines portes.
  • Ceci est pour une entreprise de menuiserie, en faisant des fenêtres sur mesure, des portes, etc. - cela signifie que les devis sont produits mais ils ne se réfèrent pas à une table "produits" car tout est unique. La personne qui construit la citation écrira simplement quelque chose comme "Double fenêtre 1200x1000 - Chambre 1" et un prix dans un champ séparé, et cette ligne sera ajoutée à la citation.
  • Chaque devis aura un ensemble de détails qui sont comptés comme des détails primordiaux pour l'ensemble du devis. Il y a environ 120 champs, dont certains sont pour le texte et certains sont booléens qui stockent des informations sur le travail. Ce sont des choses comme "Type de cadre de verre" (texte) et "Job comprend des portes coulissantes" (booléen). Ceux-ci sont importants car ces champs conservent une trace de ce qui a été cité et nos concepteurs s'y référeront plus tard. Ils constitueront également la base d'un document d'approbation que nous enverrons au client pour qu'il signe avant de fabriquer quoi que ce soit. Je pense que cela devrait être mis en place de cette façon, car il est probable que si nous disons 10 fenêtres pour un devis, ils partagent à peu près tous les détails comme la couleur de la peinture et le type de verre. Il y aura également un champ de section/mémo pour les notes spéciales sur les choses qui s'écartent de notre spécification standard etc.
  • Les citations peuvent avoir le statut "Live", "Dead" ou "Progressive to order".
  • Une ou plusieurs citations peuvent progresser en un seul "travail" pour être traitées ensemble et fabriquées en une fois. Par exemple, nous pouvons citer certaines fenêtres et certaines portes séparément, le client décide qu'il veut commander les deux en même temps, donc nous les traitons ensemble. De même, un client peut avoir plusieurs «phases» dans le même ordre, par exemple. ils peuvent avoir 10 fenêtres de nous un mois, et 10 fenêtres de nous 3 mois plus tard lorsqu'une autre partie de leur maison est prête, même si elles peuvent avoir été citées en même temps.
  • Les devis devront souvent être révisés lorsque les clients changeront d'avis sur ce qu'ils veulent.
  • Je souhaite également que chaque "Job" (qui peut comprendre plusieurs guillemets) ait un ensemble de JobDetails qui soit une liste résumée pour l'ensemble de la commande.

Voici ce que j'ai actuellement: Database relationship diagram

Mais je ne suis vraiment pas sûr si je vais au sujet de la meilleure façon que je n'ai aucune expérience avec ce genre de chose.

La table des tâches est également liée à une table des comptes qui contient des clients, etc., mais je ne l'ai pas montrée car elle n'est pas entièrement pertinente pour le problème en question.Je pense que les citations "révisées" devraient en fait créer un nouvel enregistrement, copier des données d'un autre devis et le modifier, afin de créer une piste d'audit, et la même chose avec JobDetails - si le JobDetails sur un travail change et/ou sont différents des JobDetails d'un devis, qui doivent être signalés (le client devra peut-être payer plus cher).

Quelqu'un a des recommandations de la meilleure façon de faire à ce sujet?

Répondre

0

Seraient une conception beaucoup plus propre - vous avez trop de tables liées qui ne ont pas besoin d'être liées si les relations sont correctement définies:

EER


Je suis parti sur les tables de paiement dans votre exemple, elles devraient être incluses comme vous les avez ci-dessus, les relations sont correctes sur celles-ci.
La table JobDetails peut également être fusionnée avec la table de travail réelle à partir de votre description ci-dessus. Elle a une relation un à un. Si vous le souhaitez, vous pouvez toujours la référencer. table seulement et pas les tableaux de citation etc

+0

J'aurais probablement dû être plus clair - je veux avoir une piste de vérification pour les détails de travail. Si le travail a été coté comme étant peint en blanc et qu'un des concepteurs l'a changé pour être peint en vert alors j'ai besoin que cela soit signalé dans les rapports au moment de la facturation au client (ils devront payer plus!) . Les JobDetails doivent également s'appliquer aux travaux et aux devis. – WhatEvil

+0

concernant les détails du travail: "Je veux aussi que chaque" Job "(qui peut être composé de plusieurs guillemets) ait un ensemble de JobDetails qui soit une liste résumée pour l'ensemble de la commande". Vous devez résumer les détails dans votre logiciel/procédure de reporting plutôt que dans une autre table, c'est-à-dire en utilisant une instruction Select. – kbbucks

+0

également en termes de piste d'audit, vous devriez toujours pouvoir gérer cela dans la table QuoteLine en utilisant différents états, vous pouvez alors utiliser un superceded_QuoteLineID pour lier à la ligne QuoteLine avec les détails mis à jour - ceux-ci seront tous liés au travail De toute façon, à travers le JobID pertinent - en termes de suivi de la piste d'audit qui sera à la hauteur de la façon dont vous rendre compte. – kbbucks

Questions connexes